#BPM vs. SOA
- October 18, 2009
- 1 Comments
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.