Binding SOA to BPM instead of BPM to SOA
SOA has more traction these days than BPM does. SOA tools are more mature, but they are also wildly technical. If you want to model a process in an EAI or ESB tool, don't expect to share that model with the business. BPMN is a visual language invented by people who like flowcharts.
Clue #1: the business hates flow charts.
There is value in connecting BPM to SOA, but it is entirely possible to do one without the other. BPM can be performed for reasons that have nothing to do with IT automation. You can focus on improving the processes in the assembly of a manufactured product, or make the manual steps in a paper-based order processing system efficient. However, to truly unleash the power of BPM, you need to get past the biggest hurdle to it's effectiveness: the expensive IT project.
Many Business Process Re-engineering efforts die on the vine because the first step is to create a model for a new business process, and the second step is to change the IT applications that support the existing process. Step 2 becomes expensive and time consuming. The business looks at the return on investment for fixing the process, and the annual cost of making the change to IT, and is unlikely to see any real value in making the change at all.
Connecting BPM to SOA makes BPM work. We can deliver a process change FAR less expensively if it means creating a new composite than if a process change was to drive an altogether new IT system. SOA without the justification of business change is a chaotic and expensive animal that should be killed. In many companies, it has been killed as an expensive waste of time.
The only value we can get out of SOA, in the long run, is if we make the business more agile by removing the obstacle of expensive IT development. We don't need pure SOA. We need BPM+SOA.
Unfortunately, most EAI-based tools are written the other way around. We (tool vendors) expect our customers to build the services first, and then attach them to business processes in a great big flow chart. Head's up. Doesn't really work that way. In that model, the process diagram is the last thing you build. It needs to be first. Without the diagram first, you can "describe" the conceptual services you need, and even build the base infrastructure, but you cannot build the enterprise services without starting from the business process and working toward the service. Seamlessly.
In this paradigm, BPMN is a problem. EAI tools support BPMN as a flow chart (see clue #1 above).
If we will see the BPM+SOA concept take off, it won't be because we decided to teach a million businessmen to read BPMN flow chart diagrams. BPM+SOA will take off when we learn to develop SOA models from the business process diagramming standard that business already uses: the swimlane diagram.
Let me repeat for clarity: we should attach SOA to the Swimlane Diagram, not business process to the BPMN flowchart.
There are already tools on the market that take this approach and many more are appearing. This is the direction that many software vendors, including my own, have been slow to understand.
Cracking this nut will require that we start where the business is, enable a higher level of immediate quality and consumability where the business is, and THEN tie in IT where the services are. Starting where the business is requires a new tool. Building the services will use the existing tools. We are half way there...
... but only half way there.
----
Update for clarity: Yes, I know that BPMN allows you to model a swim-lane diagram. Swimlanes are a problem in the EAI space, however, because we didn't put people into the process from the start. In many tools that started from the EAI space, the swimlane is the afterthought and human collaboration semantics are not well managed. This includes things like worklist, notification, team assignment, handoff, ad-hoc routing, and other elements that are typical of workflow tools that do not show up in EAI tools.