-
blog search
-
most recent posts
post calendar
categories
More big vs small thinking: SOA vs BPM
Thursday, July 26, 2007 by admin
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.”
Posted in BPM
Neil –
A very different perspective on the BPM role within SOA. I am relatively new to the field and the picture I have been getting from the literature is that BPM is sitting at the top of the stack and it is responsible for tying/orchestrating all the infrastructure services through the ESB/middleware. The picture I am getting from you is quite contrary to that view. What I am getting is that we have two stacks side by side with constant interaction. To me, this view complicates any SOA implementation and might be a recipe for failure. It is already very difficult as it is to get the business and IT sides to even communicate effectively across enterprise. What you are suggesting is a marriage/close coupling between two groups that speak different languages and semantics on the same language. At least, the top down approach describes a broker in-between/marriage counselor.
Neil –
A very different perspective on the BPM role within SOA. I am relatively new to the field and the picture I have been getting from the literature is that BPM is sitting at the top of the stack and it is responsible for tying/orchestrating all the infrastructure services through the ESB/middleware. The picture I am getting from you is quite contrary to that view. What I am getting is that we have two stacks side by side with constant interaction. To me, this view complicates any SOA implementation and might be a recipe for failure. It is already very difficult as it is to get the business and IT sides to even communicate effectively across enterprise. What you are suggesting is a marriage/close coupling between two groups that speak different languages and semantics on the same language. At least, the top down approach describes a broker in-between/marriage counselor.