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.