Peter Woodhull starts his new article "Best and Worst Practices in BPM and SOA", by saying:
As businesses continue to turn to BPM and SOA for increased efficiency and effectiveness of their business processes, many are still missing the mark. There are various approaches that can either make or break an engagement.
Peter discusses some of the best and worst practices in a BPM and SOA implementation. According to him, the following represents worst practices:
Buying software first. According to Peter, the worst mistake is to start a BPM/SOA initiative by evaluating and purchasing software first. The issue is that very few organizations actually know upfront what type of software they need. Adjusting solution to match off-the-shelf software is equivalent to letting someone else run your business.
... most initiatives that start with a product purchase are owned by the IT group and result in bottom-up advocacy and implementation strategy. This causes a disconnect from the strategic goals of the business, because the tendency is to be more focused on the technology than the process or business need.
Discounting organizational change effort. Because most people are change-averse, they don't like change even if it makes their job easier.
If users are properly engaged and provided the opportunity to review, comment upon, validate and help make decisions about the new processes and systems being put into place then they will internalize these changes and accept them.
Trying to "boil the ocean". It is rarely possible to implement a BPM/SOA solution as one massive upgrade or roll out.
BPM and SOA efforts are both inherently evolutionary in that they are best implemented in small, constrained, and frequent capability releases that grow upon each other. Capabilities should be rolled out iteratively in a controlled manner. Processes and services should be independently managed and implemented such that they provide immediate value to their user communities.
Best practices, described by Peter include the following:
It all begins at discovery. Peter considers throwing a technology solution together before there is a clear understanding of the problem as a number one reason for failure.
Accurately defining the processes being managed and documenting the service contracts (WSDL files and data schemas) should be the first and most significant aspect of any implementation initiative. Once an accurate and clearly documented Process Specification (i.e. business requirements) has been validated, signed and approved by your client or partner organization, then and only then should a team begin development and prototyping.
Approach BPM and SOA together as a composite solution. Many people consider BPM and SOA as two independent undertaking, often implemented by different organizations and with different priorities.
BPM and SOA are ,,, strategies and techniques that are utilized to solve some fairly common and ubiquitous problems within business. They also ... [are] well supported by technology platforms. BPM suites are very effective integration tools, especially if there is a need to integrate both humans and computer systems into a consolidated solution. Web services and SOA technologies are great mechanisms to provide code reuse and interoperability between both computer systems/platforms and organizations.
Start with a mission-critical process. As every new approach, SOA BPM needs to be proved in order to obtain management support.
Start with a single mission-critical business process that will recognize identifiable and quantifiable value. Ideally, an organization should select a process that is directly customer focused and does not have an obvious solution... This will result in the implementation being owned by the business group(s) within the organization and not become the responsibility of the Information Technology team.
Peter ends his article by underscoring the complexity and power of SOA and BPM implemented together. He also encourages taking a business, not a technology driven approach to them. Following dos and don’ts as described in his article does not guarantee success, but can decrease the chances of failure.