More big vs small thinking: SOA vs BPM
I was on the way back to the office from a briefing with BPM vendor Pegasystems yesterday, where we'd had an interesting discussion about the relative roles that BPM and SOA can play in business transformation for customers.
We agreed that BPM, done right, is as much of a discipline that organisations can use to transform the way that they do business, as it is a technology (or set of technologies). What's more, we observed that many BPM initiatives revolve around making big changes to the way that organisations deal with customers, partners and suppliers - and creating organisations that are really focused around delivering real service to those other parties.
Let's review that for a second: BPM thinking helps organisations get their houses in order so that they can deliver coherent and quality services (and not just disjointed experiences).
So from a business perspective, it's BPM that delivers service-orientation!
But wait - in IT we're saying that service-orientation comes from something called SOA. And in IT circles, there's a lot of discussion that positions BPM as if it's a layer of technology that sits on top of SOA technology. Kind of like we've just reinvented three-tier application design with BPM instead of business logic, and SOA instead of database access logic.
This "application architecture" lens for BPM and SOA is all wrong. It's another example of
small thinking.
The more profitable way of thinking about the relationship between BPM and SOA is not to think of them as a stack of technologies: it's to think of BPM as being about "how" you do things and service-orientation being about "what" you do. Service definitions are definitions of commitments: they say what you will do, how well you can do it, and (possibly) how much it will cost you to use. Process definitions are definitions of work: they say how commitments will be fulfilled, by whom, and under what conditions.
So, BPM and SOA are interlinked - but not because one adds value to the other or because one sits on top of the other: both ideas are two sides of the same "business and IT transformation" coin.
If you do insist on thinking of the world in terms of stacks of technology tools or stacks of models or assets, think of SOA and BPM as alternating layers of concepts and practices. Services define "what" you will do at a given level; processes define "how" services will be delivered. Processes rely on foundation services to get some work done; those services in turn rely on processes of some kind.
I'm sure not everyone will agree with this, but I do hope there's one thing we can all agree on - as
Sinatra once sang: "this, I tell you brother: you can't have one without the other."
Labels: architecture, BPM, Pegasystems, SOA
