Kiran Garimella's BPM Blog« AquaLogicBPM Overkill | Main | SOA versus Web 2.0 »
March 22, 2006SOA versus BPM
A question that I've been answering frequently recently is, "What is the relationship between BPM and SOA?". Of course, there is no single answer to this question because no two people can agree on an exact definition of either BPM or SOA.
But fundamentally, I believe that BPM and SOA are two sides of the same coin. From a business perspective, both are about providing more flexibility and control to the business, increasing agility and time to market, and allowing different business units within the enterprise to work together. From IT perspective, both are about building and orchestrating composite applications, enabling re-use of existing services and systems, and using open standards.
The difference, fundamentally, is the direction at which SOA and BPM approach the problem. BPM starts with a business process and develops a solution from top down. SOA starts of an existing catalog of services and builds up. As a result, BPM projects tends to be tactical and SOA projects tends to be strategic.
A BPM project will typically start with a process that needs to be implemented or optimized. After modeling and simulation, integration will be put in place to meet the particular needs of that process and the process deployed as a composite application that orchestrates all of the needed pieces. In other words, integration will be done on an "as needed" basis where only the functions needed for that process will be integrated. A SOA project, in contrast, will take a more forward looking approach. The services developed in a SOA project are designed for long term re-use and may not have an immediate short term need. Integration to back end systems will be designed not based on the needs of a specific project, but for long-term re-usability.
There are exceptions, of course. There certainly are companies with long-term strategic visions for BPM, with a well organized catalog of re-usable business processes that are leveraged across the enterprise. (I am seeing this scerario much more frequently as BPM matures.) Similarly, many companies use a short-term tactical project as a way to test the waters of SOA and order to get a more concrete return of their investment in SOA. But the more strategic a BPM project, the more it will be intertwined with a company's SOA strategy.
Posted by davidogren at 11:53 AM in
BPM
| 
Digg This | 
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/126
I see BPM as a capability under the greater SOA umbrella.
Top down (BPM) tends to drive the priorities of what business systems to expose as services, and to what level of granularity. For that reason I would think the preference is to tackle the problem from the BPM perspective. Thoughts?
Posted by: John Clingan at March 25, 2006 02:40 PM
Hiya John, long time no see.
I don't necessarily see this as a right or wrong question. As a BPM vendor, I certainly see a lot of benefits to the top-down BPM approach. But that's not to preclude the need for holistic strategic SOA initiatives. A bottoms-up approach of strategic SOA have a lot of benefits as well.
Posted by: David Ogren at March 26, 2006 10:34 PM
Post a comment
