lustratus LiteBytes

I enjoyed reading Lorraine Lawson’s excellent article on whether BPM or SOA should come first.

Her conclusion was ‘maybe’ – in other words, if you are looking to provide a solution to human-oriented process flow issues, then BPM is best first, while if you want to share business services for new business needs, then SOA is best – but you will probably need both.

I have to add something to this discussion, however. BPM is a term used and misused frequently in the marketplace. Once upon a time, there was Workflow – this was used to refer to a solution area addressing the needs to primarily address human processes, often starting out from paper exchanges between departments / people. So, for example, sending an email with attachment to the next person in a work chain rather than passing on paper is an elementary automation. Actually having some code that knows that when you want approval of a purchase order, copies need to be sent to both the supervisor and audit department takes this a step further. Enabling problem reports to be entered on work queues which are determined based on geographical location might be yet another step.

Workflow products and solutions have been around for years. Then, as part of the EAI (enterprise application integration) shift, the idea came about that once different pieces of code can be easily (or at least with less difficulty is more accurate!) integrated, it becomes possible to dynamically link different IT components representing steps in a business process – ie BPM. In this flavour, BPM referred to short lifespan operations, where linkage was in the second or subsecond range, whereas in workflow solutions the process might extend for days or weeks. Then people started using the term BPM to refer to both forms of process integration.

So, back to the base question. Well, if what you want to do is to take a well-understood human-oriented process and automate it, then workflow / BPM is what you need, and there is no obvious reason why SOA would be a pre-requisite. However, if you are looking for process integration and automation as portrayed by dynamic flowcharts and decision trees that relate process substeps to IT components, then in order to achieve this you have to understand each component or chain of components and how they relate to specific business operations. This is something most companies do not have at their fingertips. On top of this, in order to relate changing a process flow to altering the underlying IT implementation, you have to be able to make the different IT components link together. Working all this out and providing a mechanism to relate back to the BPM modeling tool means that a lot of the work to develop an SOA and its services has to be done anyway.

After all, an SOA service is directly related to a piece of business functionality, and you have to break things up like this to use BPM in its wider sense. Therefore it makes sense to do SOA first. Otherwise your drive towards a BPM strategy will founder on the inability to execute at the IT operations level.

And before I finish, I just have to comment on the idea that ‘reuse is a useless financial justification for SOA’. This is a line David keeps trying to push, but the fact is that reuse still remains one of the most common factors in SOA justification. Reducing redundancy provides a clear and measurable way to avoid cost, as companies like Wachovia have shown. I do not disagree there are other factors that can be brought into the business case, but reuse remains one of the clearest to identify in monetary terms.

Steve