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.

Comments

• Anonymous
  August 06, 2007
  PingBack from http://www.userinexperience.com/2007/08/06/links-for-2007-08-06/

• Anonymous
  August 09, 2007
  Great blog. Something didn't seem right when I read the statement "develop SOA models from the business process diagramming standard that business already uses: the swimlane diagram." so I thought I'd ask for clarification...are you suggesting in the statement that SOA should be derived from business process swimlanes? The reason I'm asking is because I've witnessed architects urging business leads to define their busines processes using a BPM tools which the architects then essentially compile the process definitions, which included swimlanes models, into web services. This approach produced a bunch of redundant, siloed software services that didn't deliver the benefits of SOA; system flexibility, data quality, reusability and ultimately reduced agility to the business. The approach lacked steps such as commonality variability analysis, data modeling and basic object-oriented techniques to design the software service to automate the business proces but not be coupled to the business process definition itself. I don't think that you are suggesting that BPMN-to-SOA is the right approach but I thought I'd ask just in case becuase it wasn't clear to me in the blog.

• Anonymous
  August 10, 2007
  The comment has been removed

• Anonymous
  August 10, 2007
  Yes. Thanks Nick. I just want to clarify that we need strong architects that have solid system design skills that can automate business processes defined by the business. This isn't different. The thing that's different to me in your blog that you underscore is that the business can use BPM tools with the latest innovations and leverage swimlane process design to assert presentation-layer software services designed specifically for the nuances of human-to-system workflow and not assume the nuances of system-to-system workflow/orchestration. GREAT POINT. Regardless, leave the actual software service design decisions to qualified Solution Architects.

• Anonymous
  August 10, 2007
  @Gabriel, I completely agree.  The design of the actual software services cannot be done without qualified Solution Architects. Probably in multiple iterations... Hopefully with competition... Someday, off the shelf... --- Nick