Business Analyst Point of view - SOA versus BPM

Why is there such confusion between BPM and SOA? Whose on first? Well both of them are on first.

Recently in working with our partners it is very evident that the overlap between the engines can be explained in terms of architectural approach to a process execution need. Neither type of engine can perform all of the functions required to execute a process. This is the dirty secret. This also explains for some of the reasons behind the consolidation in the industry, which just makes the design iteration issue more important.

When talking about a process and its details people rapidly get mixed up between, what is in a box (if it is drawn in MS Visio or any BPM application) and what is the detail within that box/node. So they map the process steps horizontally, but they think about the detail or "how to logic" - vertically.

Well for BPM the box represents the requirement to bring information to a human to do something with. And it is the detail within the box or the execution of a series of steps (vertically - from an architecture perspective) - in connection with other systems to retrieve data that a SOA application executes to bring that information to the screen for the human to decide upon.

In CMMi terms the BPM can be understood as the Level II or III and maybe a little of IV, but most definately the Level IV and V are completed by the SOA or middle tier in the architecture of the systems.

The interesting part about this for the business analyst is that the vertical steps are "jobs". These jobs are common scripts written by the IT architects and ready for use in an "almost" plug and play manner. Each SOA vendor is trying to "verticalize" these "jobs" as offerings for their prospects and clientele. These "jobs" are essentially "integrations" across multiple systems. (I will talk about this more later).

A classic example is a BPM step to search for a customer record to being the process of assisting a client. The script to search for example the Social Security Number (SSN) is used many times for searching multiple applications to assess the proper data to lead the customer service rep to the next correct screen. This is the vertical (logical) search for data from many disparate systems. The average BPM engine needs to go outside to get the information via a SOA application and bring the information to the customer service rep.

But as this relates to 'design iteration' we are still in the same problem set where the business analyst is asked to provide both the horizontal and vertical (logic) without any context to the process.

We think we have an answer to this problem, which is two fold.

1. How do you provide a methodology to capture process information by the business analyst while enabling both the 'horizontal and vertical' documentation for the business people to understand?
2. How do you iterate through the process of documentation and execution to get the systems up faster to increase top line revenue?

Lastly, when we speak of execution in the design phase - we do not speak of it as "no coding necessary". And execution is not a live production system. There is no silver bullet as some would have you believe. The business problem is design iteration.