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."
Remember "BPM" is discipline about activities and tasks performed by resources –humans and machines. SOA is an IT architecture about delivery of applications that offers some flexibility and a more efficient way in accessing available services if relevant to the activity.
Also let's remember just what we are trying to achieve “total business agility”. Work through different tasks types creates processes – source information is created by people and is enabled by ensuring the link between them their roles, the task/work type and the right information/data being made available at the right time under the agreed service or commitment definitions and rules are all agreed in the process design. All this should be built through the graphical designer. This is about business logic and has nothing to do with SOA.
The outputs of resources working together create more information and needs for action, which creates a business. It is in this environment that there is a need for flexible working and collaboration to adopt new and more efficient ways to achieve individual or collective goals. So it in this People and Process layer there is the need for “agility”. Core transaction or recording systems do a different job and are not designed nor need to be “agile”. They store and manipulate information, as required and ready for use by the business in whatever form is deemed relevant. Here SOA has advantages as the need arises to use such information in the business process but there are other ways to make remote procedural calls. SOA is a good thing to have if you can afford it (which many will not) but is not and should not be a requirement to start delivering on a BPM program.
And do not forget to test when selecting from the suppliers supporting BPM that what is on the tin is in the tin. Also ensure that it talks business language to deliver exactly as is required to align your people with your process to protect your key assets and to do so the enabling software must be able to change as the business changes.
Business people should beware of the SOA salesmen and be ready to sing their “new” song “I did it my way”.