Does BPM mess up SOA?
I have always thought of SOA & BPM as two complimentary solution approaches. There are numerous articles that talk about interplay and synergy between SOA & BPM, and this has become so obvious that any new article on this topic doesn’t even draw my attention. However I recently stumbled upon a blog post titled ‘Why BPM screws up SOA’ by Steve Jones that really caught my attention. I completely disagree with Steve ...
This is a rather long post. I apologize I couldn’t keep this short, as given the highly debatable subject I think I need go deep into this matter and put forward my views in detail
Steve has made following points in his blog
1. “Processes are not the ultimate thing in business” – in fact there is a separate blog on this topic
2. “if you start with BPM, which is about coordinating steps, then suddenly every service looks like a step”
3. “If you are doing BPM and then just saying "step = service" then you are doing VISUAL Cobol and replacing function calls with service”
4. “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”
5. “SOA makes great BPM, BPM makes crappy SOA”
With due respect, I completely disagree with Steve’s views. IMHO SOA & BPM are different, yet very complimentary. SOA is a technology approach towards standardizing & streamlining IT systems; while BPM is an approach towards standardizing & streamlining the business processes and operations. The objective of SOA is to make the IT systems agile and promote reuse of IT assets, whereas the goal of BPM is to make business processes agile and promote reuse of business operations & processes across the enterprise.
“Its an old truism that KPIs drive behavior …. , it is therefore, when modeling the architecture, more important to consider these KPIs and the underlying business goals than to worry about the audit process that will allow elements to be measured. This is a great example of where the business value and importance is assessed via the KPIs and Goals, but is measured by the implementation of a process.
…..
In fact I'd say that for most Services the concept of "Goals" will be more useful than the concept of "Process".
Now here Steve is totally contradicting his own views that “BPM driven SOA tends to make bad SOA …”, on the contrary when you set out for BPM you first define the objectives and goals for the process. You seek clear answers for questions such as – ‘what this process is all about’, ‘what is it is trying to achieve’, ‘what business value does it generate’, ‘does it really make critical business value to consider for process management’. You define business goals for the process (e.g. enhance responsiveness, improve strike rate, reduce cost, etc) and derive process and activity level KPIs (which are then defined in the business process model for the purpose of business performance monitoring). So going by Steve’s assertion that any SOA initiative should be goal and KPI driven, then here is the way - go on BPM path.
To the second point above where Steve’s view is ‘BPM is all about coordinating steps’ – to me it sounds a hardcore technical guy’s pov of BPM. First of all, BPM is not just about automating business process. The real goal of BPM should be to build systems that facilitate continuous business process optimization; put in place infrastructure that enables monitoring business process performance to identify any bottlenecks that hinder in achieving the business goals (target KPIs for the process). Refer to my other blog post ‘BPM – Moving beyond modeling to complete process management’ where I have discussed importance of setting business performance improvement targets as success factor for any BPM (and SOA) initiative. A BPM or SOA project that’s completed within time and budget but does not add to organizations’ top line or bottom line is complete waste. It’s BPM that ensure unremitting focus on business value.
However, even if we look at BPM just for automating business processes (and ignore the larger benefits), BPM is not about ‘coordinating steps’ (I assume by ‘steps’ Steve is referring to statements & function calls in typical computer language) BPM is about orchestrating Business activity. When you do BPM you don’t set out to externalize program flow rather the objective is to externalize the flow of business signification activities (fulfilled by multiple heterogeneous internal systems or partners’ systems). This is like difference between high level business process model v/s program flowchart. BPM is not an attempt to translate flowchart into executable artifacts, rather it’s attempt to define business process models and translate that into executable artifacts that coordinates execution of various business significant activities.
To the 4th point – “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” – There is very clear difference between procedural and process view. Again the analogy of business process model v/s program flowchart would be helpful here. It would be very procedural if you attempt to translate a program flowchart into BPM model. BPM is not a code generator. And saying that it has poor separation of concern and driving things from technology perspective is completely false. In fact BPM significantly promotes separation of concerns by externalization of process flow (not program flow) logic from the code.
And to the last point - “SOA makes great BPM, BPM makes crappy SOA”. I think the reverse is the reality. SOA without BPM runs the risk of loosing sight of business value, doing SOA with BPM focus ensures that IT delivers to business goals rather than end up creating elegantly architected system that doesn’t have any business impact.
Comments
Dhiren, you make very interesting points. I think I agree with most of your assessment. I do think, however, that how well or badly applying BPM to SOA (or the other way around) succeeds depends on how well the process is designed and how well the process flow is "externalized."
Too, without BPM (and, of course, the plethora of products that help the paradigm), the risk is that a majority of the business logic will end up in one layer above - the consumer or the client of the service. And that contradicts the separation of concerns.
The other observation I made when looking at both the blogs (yours and Steve's)is that there is a low emphasis on the Service aspect of the whole thing. SOA is all about services. Without having a layer to manage the orchestration of these services, the capability to effectively consume them diminishes.
Posted by: Ajit Sagar | June 5, 2008 08:03 PM
What surprises me is that despite good number of years of BPM and SOA stuff around, the world is still debating on it. Unfortunately, different schools of thought have different meaning of both (BPM and SOA) so its important for the debate to understand the boundaries of the individual schools of thought. I think it is less of something being right or wrong and more of value that each school of thought provides.
Having said that, I too feel that my school of thought will align to what your response is. As I see, value of BPM is two fold. One (and most important probably) that it allows us to extract process design from the applications (where it typically is embedded through program flow) and treat the process design like a business meta data. Second (which is dependent on the first) is that it will enable end-to-end management of the business process in integrated manner. I think second one is straight forward. But let me spend couple of lines on first one that I believe is critical concept. BPM provides business process meta-data in terms of flow, rules and integrated process wireframe. What it means that we can configure and manage the configuration change of business elements specific to process qualities (flow, rules, decision path etc) without needing to get inside any business application (read technical work). That I believe is the biggest value from BPM.
Coming to SOA now. I see SOA as a value system. I find SOA comparison with BPM and EAI very odd because both don't belong in the same plane. SOA as a value system, I can apply to any layer of the architecture, be it infrastructure, data, application, integration or be it business process. So there is no reason why BPM will kill SOA or SOA will kill BPM. In fact, SOA value system in integration layer (read middleware and ESB) provides a great service delivery platform to BPM to be able to connect process wire-frames to actual execution of services hosted in applications. Added to that, while doing BPM, the process design itself can be done based on SOA value system that bring composite process development phenomenon to life. So I would say, SOA to BPM comparison will be just an intellectual exercise and is not worth. What we need to do instead is to analyze how we can have SOA value system take to BPM in order to get full potential of the BPM
Posted by: Rakesh Mishra | June 10, 2008 09:12 AM