BPM and SOA

At the BCS Business Information Systems SIG last night to hear a talk by Howard Smith of CSC. Meanwhile, I've been listening to an ACM Queue podcast with Mike Vizard and Edwin Khodabakchian (formerly Collaxa, now Oracle). 

I have spoken to Edwin and his (present and former) colleagues in the past. I hadn't met Howard before, but I was already familiar with his work and I am in contact with some of his associates in the BPMI world. 

The following post is something I've been thinking about for a while. I am happy to acknowledge the influence of Howard and Edwin, who both know a lot more about the BPM side than I do. But there are some things I'm saying here that I haven't heard either of them say, so blame me (not them) if you don't understand or agree.

---

What is the relationship between Business Process Management and SOA?

A good place to start is with the idea that SOA gives you the decomposition of functionality into (standardized) services, while BPM gives you the assembly of these services into (flexible) business solutions.

1. We can decouple the specification of the process from the specification of the units of work making up the process. (In my Business Modelling for SOA material, I describe this as separating WHAT from HOW.)
2. We can put the specification of the process into a standard process language. (The preferred choice here is BPEL, for various reasons, although there are some known issues.)
3. We can automate and distribute the assembly of the process. (With appropriate tools, the assembly of the process or the selection of an appropriate process variant can be done either in real-time or dynamically at the point of need.)
4. We can then take power to the edge - delegating process management to the people working at the edge of the organization.
5. Ultimately, not just the process but the process management becomes event-driven. This gives us requisite variety at the process level.
6. Process architects now need to work at a higher level of abstraction. Instead of specifying a standard one-size-fits-all process, they need to produce what we might call a metaprocess - frameworks and patterns that support process management. They need to pay attention to architectural process issues, such as coordination and interoperability risk.

These ideas are probably some way from mainstream adoption; but there seem to be enough early adopters experimenting with some of these ideas to keep the BPM market moving forward.

---

Business Process Innovation

The second part of Howard's talk was about Business Process Innovation. If we imagine that BPM plus SOA gives us a reasonable way of automating the business process, then the next challenge is that of automating business process change. 

Howard's working hypothesis is that business process change is driven by problems. CSC has adopted a Russian problem-solving methodology called TRIZ, and has been working on a process-oriented version of TRIZ called P-TRIZ. 

Most of the audience (including myself) were not familiar with TRIZ, and there was a lively discussion about its strengths and weaknesses. My first impression is that TRIZ would not be suitable for all types of business problem, as it seems to lack adequate constructs for modelling complex dynamic systems. However, it does have some interesting characteristics that may make it particularly amenable to automation. Firstly, there is a systematic approach to problem decomposition. Secondly, there is a complete enumeration of solution strategies, and a useful collection of abstract solution patterns. 

Howard showed us a stand-alone prototype tool that supported a simple version of TRIZ. What would be really interesting (and this is presumably CSC's plan) would be to have this functionality integrated into the BPM tools. Then we would be able to have local process-oriented problem-solving, with process architects able to concentrate on the emergent properties of the whole. 

This looks like a significant contribution to the overall BPM/SOA vision outlined above.