Friday, June 15, 2007

Why BPM screws up SOA

I've often argued that Services are containers for implementation and that processes are not the ultimate thing in business, and a key part of this is the idea that Service != operation. This last piece appears to be one of the most beguiling myths about BPM and SOA and its surfaced yet again:
"SOA is an architectural style the recognizes services (functionality representing process steps) as components."
Jack Van Hoof
Emphasis mine. But I'm willing to give Jack the benefit of the doubt as there are two ways of reading that. The less charitable reading is the one that was jumped on someone talking about CRM (quell surprise)
"Let me start by defining that a service is a specific business process step that can be composed and reused in different business processes."
Kjell-Sverre Jerijærvi

Now this really does leave no room for maneuver, and it is completely and utterly wrong. This is one of the big challenges of BPM and SOA in that if you start with BPM, which is about co-ordinating steps, then suddenly every service looks like a step. I've seen this problem on several occasions now, and heard it repeated by many others so it looks to be pretty endemic in BPM driven solutions.

To be 100% crystal clear. If you are doing BPM and then just saying "step = service" then you are doing VISUAL Cobol and replacing function calls with service. The fact that you are using WS-* or XML does not make these elements services. As the SOA-RM says "A service is a mechanism to enable access to one or more capabilities", so it is possible for it to be a single capability, but that is certainly not the only, or indeed the most likely, number of capabilities in a service.

BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective.

SOA makes great BPM, BPM makes crappy SOA.

Technorati Tags: , ,


Jack van Hoof said...

Hi Steve,

Ik think there are more powerfull constructs then BPM to model business processes.

At the business level processes are defined as repeatable and predictable reactions on predefined events. There may be flows recognized... or not.

Procedural algoritm-like BPM is one way to link these processes to technology. But there are other ways to do so. Think of declarative definitions of actions linked to events. Especially in agile, complex or less formal situations you might prefer this latest approach.

The clue is that you may view SOA from two different perspectives: the two worlds of SOA, each with their own characteristics, where the technology perspective has multiple possible solutions to the business perspective.

Steve Jones said...

The point I was making was about the idea that service = function step, which is what any process based view of the world tends to feel comfortable with. The same applies when looking at single events as being the critical element.

Fundamentally an approach based on singularities is going to struggle because it removes structure and makes granularity very hard.

Kjell-Sverre Jerijærvi said...

To make it easier for people that are far above CRM in enlightenment, but might not know WCF, I have now tried to make it bleeding obvious that the term "service" for simplicity is used to talk about specific business steps without having to write that over and over again.

I have also moved this repeated "service" term definition to the first paragraph: "the idiom service here is an [OperationContract] in WCF terms".

But you certainly got to say once more your piece about BPM and service != function step.

Steve Jones said...


On Operation though the challenge is that Operation (again a singluar) is pretty much still a single step. Now clearly in WCF you don't have to build it that way, but what I have seen is that people when starting from the process side tend to produce single step artefacts (the BPM tools pretty much mandate this for the actual process for instance).

Its one of those strange things, ask someone to define a service for something and it will have lots of operations, give the same person a BPM tool and its single steps all over the place!

Jack van Hoof said...
This comment has been removed by the author.
Anonymous said...

Hi Steve,

Nice article. Because of the length, I posted a reaction
on your article on my own blog.

Anonymous said...

I agree that a service is not a step of process. On the otherhand, it also depends on the level of granularity the steps are being defined. If the steps are defined at 'capability' level, i.e. the 'WHAT' rather than the 'HOW', then that's equate to the service. An example, an order fulfillment process involves part picking, then manufacturing, then delivery. While each is a high level step in the process, it can be mapped to a service.

Anonymous said...

Comments in my blog post

Anonymous said...

I agree with Zen. Weather service=function is not a valid question without the definition of granularity. If it is a business 'function' which adding value to the process, I'd call it a service.


Anonymous said...

Hi Steve, SOA is all about orchestrating multiple services if you call services are containers for implementation. Another word is SOA is for composing multiple application to provide one single granular Business Service. It is easy to mistakenly view SOA the same as services are containers for implementation (WebService). That is why the statement "BPM screws up SOA" is mistakenly driven. Hope that clarify.

Steve Jones said...

SOA isn't all about orchestrating multiple services. Its about thinking about systems in a service-oriented way. This means that the thought is service first, orchestration is second (or even later) as it is about implementation.

BPM is a potential implementation approach for capabilities in a service. That makes good BPM and starts from good SOA. Starting from a perspective of orchestration and BPM leads to crappy SOA so I'll stick with my headline :)

Siddharth said...

A service can be functional or technical. A functional service can internally use a set of technical services to expose some business functionality. A BPM is an orchestration mechanism which represents a business process by wiring together functional services

Unknown said...

Siddharth said...
A service can be functional or technical. A functional service can internally use a set of technical services to expose some business functionality. A BPM is an orchestration mechanism which represents a business process by wiring together functional services

I think this guy just defined the bone structure.

Sujatha Dantuluri said...

I am not sure why we should tie two different things. SOA as already pointed is architectural aspect whereas BPM suits only when there is some workflow or orchestration required.

To be specific SOA should help define the services required to business and BPM is beyond orchestration. It is continous monitoring and should aid the improvement of business. It is specifically useful where human workflow is involved.

Now coming to the orchestration of system only workflows, BPM apart from rollback or compensation logic provides advantage like monitoring

To conclude both serve their purposes you should not think we are doing SOA so we should have BPM neither should you think we need BPM so we should have SOA