BPM and SOA's Relationship: It's Complicated

Loraine Lawson

About two weeks ago, I wrote about a blog post called "BPM Screws up SOA," by Steve Jones. I confess: I thought it might annoy a few people -- I've interview a lot of people who work with Business Process Management software. But Jones made some really strong, interesting points and I thought it was worth a discussion.


And, boy howdy -- is it being discussed! I mean, it's not like being Slashdotted or anything, but it seems the very mention of SOA and BPM can raise a lot of dander around here.


Jones himself even posted recently to clarify his position. Despite the inflammatory title of his post, he does not dislike BPM. Nor does he think the two are mutually exclusive. In fact, he says SOA and BPM can go together -- but before you start with the BPM technology, you should make sure you understand the business issues and processes from the perspective of the business. Jones writes:

My argument is that you need a proper understanding of how the business operates and interacts before you embark on technical elements such as BPM (or indeed web services). Its worth noting that getting the understanding does not take very long.

Makes sense, right?


Be sure to read the rest of Jones' comments, which go a long way to explain how he sees BPM's relationship to SOA, and vice versa.


Francis Carden of OpenSpan, which sells Surface Integration technology and desktop application integration software, also contributes to the discussion. Not too long ago, I interviewed Carden about OpenSpan, an intriguing integration solution that Carden believes can help solve that last mile of SOA problem. If you haven't yet, you should read the interview.


Anyway, since I spent many years writing about how CIOs can align with business, I particularly liked this comment by Carden:

We must not forget that SOA in itself is not new and IT has had some shots at this in the past. There are going to be many bumps (delays) on the way so if IT can deliver immediate business benefits whilst planning for the perfect SOA world, then who are we to stand in the way.

It's an interesting discussion that I think goes a long way to clarify what BPM's role should be with SOA.


While the question here has focused on whether BPM makes a better SOA, I've seen a few discussions recently that recast that issue by asking the simply question: Why would businesses ever invest in SOA?


The reason usually given is IT agility. And that's true.


But agility can be pretty slippery. Lots of things have promised IT agility. So, the question is whether that in and of itself is enough of an argument for your CEO or CFO.


IBM offers a different answer, according to this article published in Application Development Trends


One answer, if you are IBM, is that businesses need an SOA to provide the basis for a business process management (BPM) system. That seemed to be the message in a recent Webinar called "Business Process Management Enabled by SOA" by Peter Rhys Jenkins, senior integration solutions architect at IBM.

Shocking, I know. But that seems to support at least part of poster Scott Whitmire's position:

SOA defines how you structure your IT portfolio and BPM defines what goes into that portfolio and how you use it. They don't compete; they don't conflict; they don't cooperate. SOA is one way of implementing the results of BPM. BPM doesn't define the services offered by an SOA, but it might define *requirements* for certain behaviors and properties, which the SOA must then provide. There are ways other than BPM to define these requirements, and there are ways other than SOA to implement them.

And then there's the Ph.D. who points out it's important to specify whether you're referring to the BPM solutions pushed by vendors or BPM as it applies to process engineering. He also has a Six Sigma master black belt and wonders if I know what I'm talking about or whether I am only "make good copy."


Ouch. It's true: I do not have any sort of belt, black, Six Sigma or otherwise. You can see my bio for my background. But what I hope to bring to the table is finding interesting issues, translating the techno-speak or marketing-babble into something approximating English -- for the business leaders out there and perhaps more than a few IT executives -- and perhaps help prompt a good discussion.


I'd like to think I succeeded at least two out three with this post.


One thing came out loud and clear from the discussion: Technology workers are pretty tired of marketing hype cloud what BPM and many other technology terms mean. Also: We need another term to separate BPM technology from the management, or in some cases re-engineering, of business processes.


Unfortunately, that first one is a problem neither the posters nor I are likely to solve any time soon ... or, really, at any time.


But I'll still keep trying.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Jul 4, 2007 12:14 PM Steve Jones Steve Jones  says:
There is a name for what the vendors do its "Business Process Execution" (hence in many ways BPEL), their focus is on executable steps. But in the same way as people don't sell Service Oriented Design, its always Architecture, they feel it makes it sound more important if they say BPM.The trouble with the "BPM running on SOA" vision is that it really assumes two things. Firstly that all services are executable IT things (they aren't) and secondly that everything in the business is process driven (it isn't). This is a typically "software" view of SOA and BPM, and really isn't any different to the BPM + Integration messages of 10 years ago, that approach didn't deliver the benefits and there is little reason to think that the same approach dressed up in XML files will do any better.Hence the reason that a conceptual framework (which IMO is where SOA and Business Service Architecture comes in) is more important. Reply
Jul 6, 2007 9:39 AM Paul Fisher Paul Fisher  says:
I think much of the discussion and Steve's comment don't consider anything beyond the design/development aspects of BPM(S). There are aspects like BAM, shared modeling and business rules management that need to be considered when talking about BPMS. And if you're going to use just the three letter acronym (BPM), then you've got to discuss the management discipline part too. I've also seen some pretty convincing arguments for the BPMS/SOA partnership in terms of service visibility and governance. And it may be shocking to some, but many organizations are having success with BPM without an SOA. So how about an article titled - "SOA Screws Up BPM" - the idea being the opportunities companies are missing out on while waiting for that SOA program to get off the ground and start bearing fruit.BTW - Kiran Garimella does a nice job in his book "The Power of Process" discussing what BPM/BPMS brings to process improvement and Six Sigma and LEAN specifically. Reply
Jul 13, 2007 2:48 PM Don Blair Don Blair  says:
Lorraine, et al. Very interesting discussions. I have just finished up a large SOA project here in the Middle East. Until I read your blog, I did not realize that it was possible to develop SOA without doing BPM. In fact I have been encouraging it and stating the overall need for it. I will read the other references and get myself up to date on the entire argument. Thanks for the discussion. Reply
Jul 14, 2007 7:57 PM Loraine Lawson Loraine Lawson  says:
"And if youre going to use just the three letter acronym (BPM), then youve got to discuss the management discipline part too."Thanks for the reminder of the BPMS acronym. I should've used it, since that's generally what I'm discussing. For a long time, if I remember correctly, that's exactly what the technology was always called - at the time, this was to differentiate it from Business Performance Management. But now, most tech articles just drop the S and use BPM to mean the technology, and since I'm linking to them, I usually use the same terminology. It's created a lot of confusion and consternation among readers, but it's so cumbersome to say "and I mean the technology, not the business approach." And this is an IT blog, so...Anyway, using BPMS should help clear all of that up - I hope. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.