Mr. Uwe Roedinger makes the argument on Aris' BPM Blog that you have to decide which "middleware infrastructure will be the ruling one."
Essentially Mr. Roedinger makes a few arguments that I take issue with:
Characterizing a BPMS as "middleware" reflects the notion that a BPMS is just a scripting tool for SOA services... It isn't.? There are middleware components in most BPMS solutions, but they are typically designed to tie into other middleware components that are intended solely for that purpose, not replace them. BPMS is more than just scripting SOA.
Arguing that you can't make pragmatic compromises about hand-offs between systems - for example, at some point handing off (via an event or webservice) control of a process from one software package to another. Of course ideally you continue to monitor the progress of that process through the other software package, but for expediency or pragmatism, it may be necessary to short-circuit the unification of all things process.? Of course the purist point of view isn't surprising coming from a modeling and enterprise architecture background as IDS/Aris does.? And of course ideally you abstract your processes into a higher level process controlled by a higher level process engine - but you can achieve nirvana over time, it doesn't have to come starting with the first architecture design session, as Mr. Roedinger seems to imply.
Mr. Roedinger argues you must have transparency, and that to get this transparency you must have one process ruler. This sounds good, but our practical experience in the field tells us otherwise.? We have worked with legacy systems that aren't integrated, but which provide a lot of transactional transparency through back-end reporting that is keyed off of common identities (a loan number, for example).? Additionally, we've introduced BPM solutions that address a portion of the overall process, and exposed incremental transparency for the process (in addition to the transactional data) for the portions we control, and then advised on portions outside our control to get the data we need for reporting (transparency).? After all, as long as the right data ends up in a datastore, we can use this data to expose what's going on inside the machine that is the process.
Mr. Roedinger also implies that a process, implemented by BPMS A, can be reduced to a webservice call from the "ruling process". I'll assume he means an asynchronous call, because the processes we deal with aren't so trivial as to execute in a few seconds and be wrapped by a simple webservice call.? So, from an abstraction point of view he makes a good point, but in reality, an asynch webservice call is just two webservices calls separated by some time.? At this point, we've devolved to the "hand off an event through the middleware" scenario that he described - with the notable difference that one process represents the "parent".
To that end, in several instances we've implemented a "shadow" process - which monitors the process being performed in other applications, to create unified process metrics, and initially simply to monitor, with the controls coming in only after one has had time to analyze the data.? I believe this sort of solution is closest to what Mr. Roedinger describes as the "right" approach - but again I'll stress the incremental nature of such a roll-out strategy.
Finally, Mr. Roedinger makes use of an example where the customer was choosing between SAP's BPM and IBM's Websphere BPM:
My conclusion is, and the experiences from different customers prove this, that the decision for the leading process engine is one of the first that has to be made in an automation project. Kind of a best practice decision has been made by a big German customer, where SAP and IBM technology were set as standard. The SAP internal processes will be automated with SAP XI, the overall processes by IBM WebSphere. And, very important from IDS point of view, all of the processes are modeled with ARIS and used as input for the different implementation tools ;-)
This isn't really a decision - the BPM that SAP offers simply isn't general purpose enough to drive the processes outside of SAP.? Moreover, I'm not sure IBM's offering is strong enough to manage processes inside SAP without deconstructing them.? If you start with a truly general purpose BPMS, and SAP - this decision is a no-brainer.? The BPMS can be used to implement processes that aren't addressed by SAP.? Or the BPMS can be used to leverage SAP in processes that extend its usefulness, including monitoring or being notified of changes within SAP, or even effecting those changes via SAP.? Who rules isn't the key question to me - its where can I extract the most ROI?? And I think the key thing IDS is after is that Aris be the ruling "process modeling" software.? Which, if IBM and SAP are your BPMS choices, is probably not a bad idea.
We would encourage people to be flexible and pragmatic in their application of BPM, and don't dramatically change your project just to accomplish a "ruling process" strategy.? Keep your ultimate strategy in mind, but get your project done with a laser focus on the business objectives.