Thinking again about the question, it seemed a bit 'dumb'. Surely STP is about pushing a transaction from one end of a process to another without human interaction and purely through automation, right? A workflow like this should be performed by an Enterprise Service Bus (ESB) or something similar that can choreograph/orchestrate web service requests. Well maybe or maybe not, since yesterday I boldly stated:
My belief up 'til [now] has been that the top-down BPM types of tools are good for 'STP' where there are breakouts of the process requiring human exception processing. I think that they may also be sensibly applied to business processes that can not be implemented as pure STP as a big-bang reengineering, instead having STP as an end goal that is approached through refinement and iteration of a live business process over time.What I am implying here is that STP of a current business process requires huge updates to the way the process and infrastructure works. Using a BPMS that can orchestrate many of the tasks that have to be performed in the meantime (both human and automated) makes a lot of sense. Building on this foundation provides a manageable approach to incorporating all of the integration requirements and human elements of the process over time.
The original question was triggered by Bruce Silver who has added a commentary on BEA's take on BPM-SOA. Although very much focused on BEA, reasonably so as they have been talking about this problem directly, Bruce points out that:
In AquaLogic BPM 5.7, coming up fairly soon, there will be a bit tighter linkage between BPM and the AquaLogic service registry, but a lot of this you can already do today. And probably you can do it with almost any BPMS that can consume web services with just about any SOA registry and ESB. When you can and when you can’t, what makes BPM, ESBs, and registries either hard or easy to glue together — those are stories that neither BPM nor SOA vendors are yet telling.
This could be the answer I am looking for. Maybe any BPMS that supports web service consumption can play well with SOA. And therefore, perhaps straight-through processing is something that a good BPMS can perform. It could be that some vendors have an advantage through providing an Enterprise Service Bus (ESB), but it could be something else implicit in their BPMS that makes a difference. Maybe the BPMS can not only call out to the ESB for certain tasks, but also be used as a service by an ESB orchestrated process to manage (sub-)business processes. Lots of 'ifs, buts and maybes', so if someone knows the answer, please put me out of my misery. Alternatively, if the question is just dumb, feel free to let me know.
I am starting to believe that STP is an end goal that still requires exception processing through human interaction - there are few business processes that can be handled with ZERO human interaction or intelligence. And this fits a top-down BPMS. Perhaps producing a STP process built on this toolset through iterative improvement over time, as I suggest above, will not be the absolutely most (hardware) efficient approach, compared to say building the whole thing from scratch in an ESB. But it may be the most practical in reality.
1 comment:
Whether an STP process would be defined by SOA or BPM would depend on the scope of the process. Business services defined by SOA are intended to be optimized as atoms of reuse, while BPM thinks of a single business process as fulfilling some kind of end-to-end business transaction. It could be composed by orchestrating business services from the service registry. If the organization then wanted to expose that process as a whole for consumption by others, it could deploy it as a web service and advertise it in the SOA registry. This last bit in the SOA-BPM roundtrip is something no BPMS vendors are talking about yet.
Post a Comment