"SOA is an architectural style the recognizes services (functionality representing process steps) as components."Jack Van HoofEmphasis 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: SOA, BPM, Service Architecture
14 comments:
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.
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.
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.
:)
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!
Hi Steve,
Nice article. Because of the length, I posted a reaction
on your article on my own blog.
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.
Comments in my blog post
http://blogs.ittoolbox.com/eai/business/archives/bpm-and-soa-18156
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.
Chris
--------------------------
http://www.bizsharp.com
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.
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 :)
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
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.
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
Post a Comment