In a breakout session at Lombardi’s Driven 2006, I was paired with a gentleman from BearingPoint to discuss BPM vs. SOA in our session.  My central thesis at the time was that the value-proposition of SOA was primarily directed at IT – while the value proposition of BPM was focused on business drivers (including ROI) – and as a result, SOA projects were much more likely to be successful if driven by requirements from BPM projects.  After all, work tied to ROI is more likely to get funded and get finished than work that… isn’t.

Recently I commented on Keith Swenson’s post, and then saw this ebizQ article by Glenn Smith, of Appian: “SOA needs BPM”.  Glenn articulates a series of excellent points to support the premise that SOA really needs BPM:

BPM can succeed, albeit more expensively, without SOA, but without BPM SOA is only an internal technology initiative which does not directly address any business problem.

I couldn’t agree more – SOA is grease for the wheel, but it is not the wheel. And then Glenn describes SOA as it was initially defined: as an architecture, not a product.  Again, it is nice to hear someone else saying what we all know to be true despite millions in marketing spend by stack vendors:

SOA is an architectural style for developing distributed systems. It is not a specific technology, but can be applied to many technologies. It encourages loose coupling of components and enables flexibility. Individual services can be modified with no impact on the consumers of those services. Services support reuse, and can help preserve and extend the value stored in legacy systems by making their capabilities more widely available.

He then goes on to explain why BPM benefits from the use of SOA, and why the traditional tensions between this camp aren’t particularly problematic because the very nature of the loose coupling of a Service Oriented Architecture (SOA) allows for the teams to operate largely independently and interact through well-defined service interfaces.

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.

Keith is consistently writing the clearest thoughts on the subject of “Process Reification” vs. “Model Preservation”.

In this particular article on the subject, Keith focuses on a very common misconception in the BPM community (even by some well known names in the field):

I have met so many people that think that BPM is just a scripting language for SOA services.  These people will argue at length that “BPM is a part of SOA because SOA is useful without BPM, while BPM is useless without SOA”

(Notably, he also references a good article by JP Morganthal which sounds controversial – keeping your SOA and BPM initiatives separate, but which actually makes some very good points about why SOA and BPM initiatives are motivated by different organizational and business imperatives).

But BPM is not just a scripting language for your SOA services.  To quote from Keith’s blog: “SOA is a tool we use, while BPM is what we do.”   I think this is a really important dichotomy to understand, and explains precisely why so many companies that purport to be in “BPM” still don’t really get it yet.

So you attended a technology conference one year and heard all about Service Oriented Architecture (SOA), and how your organization needs to devise an implementation plan now. Then the following year, Business Process Management (BPM) is all the buzz. Do I need both? Where do the lines cross? The fact is that these two topics are not mutually exclusive and each can stand on its own merit.

There’s no ‘B’usiness in SOA. Service architecture is much more about how technologists (or your IT department) choose to design, manage, and implement services within the enterprise. Yes, a well defined, well implemented SOA can reap benefits of reduced cost of ownership, rapid development, and stability which of course adds value to the Business; but SOA does not help Business managers understand and improve upon the processes that drive the enterprise. For that, we need BPM.

You see, where SOA is about technology, BPM is about discipline, improvement, and value. Sure, you’ll often find some very sophisticated technology in a BPM implementation, but that’s intended to hide the implementation details and shed light on the discipline of process management and improvement.

In practice, any major (or even minor) business process is going to rely on data and services within your enterprise. BPM allows us to quickly model these integration points and move on with the business of process enlightenment and improvement. As your process begins to come to life, those integration points will either serve as a road block to delivery, or a no-toll bridge to salvation. BPM does not replace SOA, to the contrary, BPM is even more valuable (and necessary) with a well implemented SOA. You can have well implemented services in your enterprise, but with no discipline to apply the use of those services, you’re no better off.

With a disciplined BPM implementation and an SOA delivering well defined and managed integration capabilities, your Enterprise will be full throttle delivering value to your customers and return to your investors.