An Opposing View: BPM and SOA Just Don't Mix

Loraine Lawson

I'm always coming across something that links SOA and business process management. I've shared many of these items with you, including discussions on how BPM can help solve SOA problems and whether you should start with BPM or SOA.

 

But to be perfectly honest with you, I never really questioned the premise: SOA and BPM are two technologies that go great together. I mean, just perform a search on the two. Almost everything you turn up, particularly with recent publication dates, pushes an alliance of SOA and BPM as solving all sorts of problems.

 

Note that I said, "Almost everything." The fascinating exception is blogger Steve Jones, the head of SOA and SaaS for Capgemini's global outsourcing business, member of the OASIS SOA Reference Model group, and author of a number of technology books, including Enterprise SOA Adoption Strategies.

 

I actually stumbled on Jones via a blog called "JOPX on SharePoint 2007 (MOSS and WSS V3 ), Office and SOA." Don't worry: JOPX isn't a language you haven't heard of. It's the blog name of author Joris Poelmans, a technical consultant at a Belgian IT Services company who does .NET development and work with SharePoint, Content Management Server and Project Server - at least according to his profile and blog posts. Apparently, Jones' contention that "BPM Screws up SOA" resonated with Poelmans.

 

Jones isn't particularly subtle with his opinions and you learn pretty quickly he's not a big fan of business process management anyway. And he has some very strong feelings about the whole "which should come first: BPM or SOA" debate:

BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective.

 

SOA makes great BPM, BPM makes crappy SOA.

He also believes starting with BPM just leads you to confuse a service with a step, and that's just wrong, he argues.

 

It's tempting to marginalize Jones' arguments, given how many analysts and vendors are shouting about the synergy between BPM and SOA. And the counter argument is that those too heavily vested in SOA don't really understand what BPM has to offer. But given his work with SOA and his role with standards groups, I think his blog deserves consideration.

 

Even if you disagree with his position on BPM, his blog is a great resource for moving beyond the "strategic overview" of SOA to understanding the actual architecture involved. Plus, he's not afraid to challenge the "conventional" views pushed by vendors.



Add Comment      Leave a comment on this blog post
Jun 21, 2007 3:07 AM Scott Whitmire Scott Whitmire  says:
This is similar to the debate between creation and evolution. At the higher levels, they look like competing theories, but at the bottom, one looks like a means to carry out the other. So it is with SOA and BPM. 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 requirments, and there are ways other than SOA to implement them. The two concepts are orthogonal. Reply
Jun 22, 2007 12:02 PM Miko Matsumura Miko Matsumura  says:
I think im closer to steve jones--we worked together to publish some antipatterns and this was the one we called "percolating process" (i think).I think BPM informs some of the choices you can make about decomposition of business services, but certainly shouldnt drive the service design.That said, good methodology allows for some flexibility and you can always refactor.I think good SOA creates good BPM but definitely agree that the reverse doesnt work well. Reply
Jun 25, 2007 8:57 AM Francis Carden Francis Carden  says:
In isolation, the author has a valid point. However, in reality, a true SOA world is such a long term strategy (5-10 years ++) for most youd be making a mistake ignoring the real business benefits of a SOA and BPM mix. Id even go as far to say, you be going backwards trying to drive any more wedges between IT and business.The ROI, competitive advantages and agile business benefits of a SOA / BPM mix are huge and must not be ignored. I am seeing today much more understanding between IT and business. Both have a lot more respect for each other with both sides realizing the others pains (IT want to sort the problem once and for all and business have big pains that need cannot wait 5 years). I am not fooling myself yet that IT and Business are married and maybe not even quite yet engaged to be married but at least they are courting each other more at last!We must not forget that SOA in itself is not new and IT have 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. BPM and SOA mix its a good thing if IT can provide more wins to business.Francis Reply
Jun 27, 2007 4:17 AM Patrick Preston, PhD Patrick Preston, PhD  says:
I think that first and foremost one must distinguish what we are actually talking about. What version of BPM do you mean? Loraine, one of the major problems with you comments is based around the concept of Business Process Management. The business side (the people that pay for nearly everything) understand BPM as the management of their processes and how those processes, activities and tasks roll up to their business entities and how these make money or run their 'engine'.From the IT side, EA and the technologists seem to see BPM as the process control systems and mechanisms to make more rapid changes to the applications and services that support those entities (see the business side). The concept of creating or implementing either of these things, SOA or BPM, in a vacuum is the major point of failure. When reengineering your processes, which must be done to implement a BP Management layer and new controls, you must be aware of your enterprise architecture and the proposed direction that is intended for your technology.The processes and activity layer (the business) can talk to the intermediate applications (the business service layer). The integration layer interfaces with both the business and architecture (op resources) layers. The development of the new processes or mapping through the layers must be done in concert. The presentation of the change and integration of changes with existing BPR efforts is the key to making BPM work within any environment including SOA. No single product or suite of products actually synergizes the translation and communication between the layers without hands-on integration. This service bus mentality that is supposedly just 'plug-n-play' is preposterous. Just look at how many of these projects fail. They have the same failure rates as projects using this same technology when it was called something else.I personally get very frustrated by all of the BS that gets thrown about by vendors promising things that aren't even close to a reality. This is very normal though and we, those people that actually make these BPM to SOA solutions happen, need to maintain context and our composure. Most of the documentation that you see talks about methodologies, frameworks and what you should do; but have little to nothing in the way of how to actually do it. Please continue this trend because then people will continue to need people and companies like me and the company that I work for.I also don't mean to poke a stick your spokes Lorraine, but where is comment coming from? Is this from experience? Is this your field of expertise or are you just able to latch onto the gist of the ideas out there and make 'good copy'? Mine is from a background in computer engineering, technology management, SS master black belt, and a PhD in informatics with a focus on Process Engineering to support the business.Good luck and remember it isn't always what you know; sometimes it's what you can implement! Reply
Jun 28, 2007 12:10 PM Bernie Hill, Ph.D., PMP Bernie Hill, Ph.D., PMP  says:
BPM and SOA?It's analogous to the merger of Kmart and Sears.There is no synergy. Reply
Jun 30, 2007 6:07 AM Steve Jones Steve Jones  says:
Well its my blog so I thought I'd respond :)Firstly its fair to say that I differ in my views from what most vendors are currently selling, in that I talk about SOA as a thing for business change, not simply a technology thing. But things like my own methodology, which we contributed to OASIS, IBM's Component Business Model and Microsoft's "Motion" (and a few others) are all very similar in being based around a concept of "Business Service" or "Business Component".The second point to make is that I'm talking here about the process and step based approach to BPM that most of IT takes. Having worked with business people and business process re-engineering people its fair to say that they "get" the business SOA view, as they've been thinking about businesses in that sort of way for years. I've even worked with a few companies to re-organise their IT around those business lines.Vendors are indeed pushing BPM as the ultimate thing at the moment, because its the most expensive product in their kit-bag. This form of BPM is not the goal-oriented, co-ordination model that I've seen when working on BPR or business projects, its a purely logical series of steps of a single process that does a single task. The difference between this and COBOL is just that the new BPM tools have a prettier GUI to work with. The processes often suffer from fragility, especially as they consider the process to be actually important when it isn't (Sales is a great area for this, the process is just a measurement thing, if a sales person beats their target by 200% will anyone care he didn't follow the tracking process?).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.I've delivered quite a few successful BPM projects, and helped recover some very unsuccessful ones. By understanding the business at a more abstract level you are able to better understand where process based implementation will work, where it will need to interact with non-process pieces and what the boundaries are.BPM as sold by vendors is just one implementation technology option when implementing services. Sometimes its a good option, sometimes its a bad option, but its impossible to make that decision if you start with BPM.Business Architecture (of which I think that Business SOA is about the best way at the moment) makes great business processes. Starting with a series of steps is like designing in COBOL. So yes BPM and SOA work together, but before you start buying the technology understand what you are delivering. Reply
Jul 2, 2007 2:36 AM Francis Carden Francis Carden  says:
Steve, I concur with that so I think we are saying the same things. Industry can make it confusing to see the wood for the trees (or the SOA for the BPM)..An argument for another day (or over a beer) but absolutely one should care of a target is beaten by someone by 200% even if the tracking process was not followed - at least we should care if it's not just a one off..... It may be to an opportunity of 400%. It may lead to un-obtainable commitments for resources (people or products)... It may even be 200% over target on high risk accounts and so much more... so.... lets park that one for a beer :) Good thread... Francis Reply
Jul 13, 2007 6:01 AM Juan V�zquez Juan V�zquez  says:
How is it that a guy who must defend the 'wires & little wires' field pretends claiming that his business -"wires"- it's the cusotmer's business? BPM is Business Processes. But customer's. And, if there's no business, there won't be "wires". Reply
Apr 25, 2008 11:18 AM mirc mirc  says:
Thanks. Reply

Post a comment

 

 

 

 


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

 

null
null

 

Subscribe to our Newsletters

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