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.

Waterfall / Agile / Where are the Practical Tools?

In the continuing dialogue of design iteration - why is it that in software do we talk about the methodology without the tools to implement them? Yes people and organizations need structure and controls around what is built. But methoolody controls are not tools which enable creativity or efficiency.

The next logical step is the desire to conform to a design iteration process methodology and over lay it on the team to produce faster iterations. A design iteration process methodology such as, "Agile" or CMMi or ITIL or UML/BPMN methodologies are essentially the same. Process driven, data capture rules with a limited number of shapes or project steps that add "structure".

What are the weaknesses in these methodologies? They are highly subjective to project steps with command and control requirements that have little getting the creative work done. Business analysts and IT architects share a need, even more so a desire to do well, to do the right thing. It is in their interests to work together for the common good, yet we put artificial barriers between them, such as different design tools, communication jargon, project deliverables which mandate primarily individual effort or steps and not team efforts. These methodologies provide very little tools to improve team effort in process or use case design.

We at Zynium have taken the best of the BPM structure for process design and placed it within an inexpensive yet widely used and understood application. To date the largest "problem" with Visio has been the "lack" of structure. Well it now no longer lacks structure, and on top of that it can integrate to reduce the cycle time for implementation of BPM / SOA or other software solutions. All while producing methodolgies in the document de jeur above.