I got a nice note yesterday from Paul Fisher, an IT exec at the FDA, on my BPM 2.0 manifesto. He was struck, in particular, by the line that said:
“[BPM's] top-down design contrasts starkly with current SOA initiatives, which are bottom-up and IT-driven, and where the services exposed for composition are determined by IT’s notion of enterprise architecture, not by process-centric analysis.”
He goes on to say,
That’s exactly what is going on here, and I’m trying to argue with people who are trying to build services simply to be able to say look ma, SOA!
You can see the rest of his comment to the BPM 2.0 post here, but I’m trying to restart the discussion around BPM as a top-down approach to SOA. Top-down as in goal-directed, the goal being optimization of business performance by improving a particular business process. It’s the process owners on the business side that should decide which services get rolled out first, and BPM provides a methodology for doing that. It’s the process, the service orchestration, that determines which services get built.
In contrast, it seems that a lot of SOA efforts today put too much emphasis on the A. I can already see enterprise architects’ heads exploding: Business-directed implementation is not architecture, it’s spaghetti, yadda yadda. Instead, we need to first build a comprehensive services layer, integrate it with our stack, etc.
But it doesn’t make sense to fully build out the infrastructure when the standards keep changing and the middleware doubles in richness every 6 months. BPMS offers an alternative practical approach that is more grounded in quickly deployable solutions with built-in performance metrics, including ROI. That iterative approach is more likely to lead to an accepted enterprise service architecture than trying to fill out all the colored squares in the EA diagram up front and declaring, OK we’re SOA now!
Phil Gilbert makes a similar point:
SOA is a great step and is the foundation that insures [easier integration]… But business process management is NOT SOA! It’s not part of the “SOA stack.” Business process management is about the business…
In order to succeed, BPM has to convince IT that it provides a better path to SOA and implementation success, and has to convince the business side that there’s more to BPM than just modeling.
While I think BPM and SOA are reinforcing concepts I do agree that they are different. Your point about needing to get started and work iteratively is also well taken.
I see business rules getting used both to provide decisioning in business processes and to develop decision services (these being the same if you are using BPM and SOA together). Do you think business rules provide a possible “tie” between the two approaches for some?
Interesting point, James. You’d know better than I, but it seems that business rules could be a useful reference point for business-IT alignment and a way through the impasse. I mean, you don’t have IT saying let’s codify all the decision logic in our key apps as business rules and when we’re done we’ll ask the business which ones they need. Isn’t it much more common for the business to say these are the rules we need implemented first in a BRMS, and then IT goes and does it? Assuming that model works, the business should say, OK let’s do services the same way.
Bruce – been lurking on your blog for a little while, thinking I must get around to starting one of these but have just been too snowed under with other things.
One of the other things I have in the works is an extensive analysis and suggested methodology for just that – BPM-SOA from a top down pov. No doubt you will enjoy it. Hopefully I will get it out somehow next week (but as it is a sponsored piece, I will have to wait for the sponsor to think about how they want to use it). Keep up the good work
Derek Miers
PS – hope to see you at BPM Think Tank in 6 weeks or so
Over the years working on business processes for multiple companies (first at a major manufacturing company for many years and later as a consultant) I came to realization, that company?s business processes are driven and direct derivative of the business model. Second, the business model by itself is dependent on the market it servers and is getting dynamic and constantly undergoing changes and modifications (evolving) Thus, we do not have a ?reference point? for the start of the BPM development. I agree with you that BPM is ?top-down and business driven? approach. But the BPM is much more complex as a result of the world-wide connected business eco-system, the dynamic nature of the market (and getting faster every year), the unpredictability of the market affects on the business model (causality affect). The next point to mention is that the processes are also required to imbed ?dynamic flexibility? to have the additional capabilities to rapidly re-align to a new business model. All this requires a more advance approach and tools that can execute the approach.
I have done some work and got very interesting results. I believe the most difficult in the BPM is to achieve the ideas of business agility. Even more complexity is coming as a result of world-wide integration of the business eco-system and distributed multi-national nature of many companies. But the idea of Business Process Management is very important for the future of all companies. In reality, there is very little monitoring and control over the Business Processes at the current state of affairs. However, the future will require rigorous monitoring and control over the BP. There where the BPM 3.0 (not a mistake) will come into play. I would like to see the continuous evolution of the methodology and the tools.
Bruce, it is indeed more common for the business to start the process – typically by saying they need a certain decision automated in a way that allows them to manage it effectively. When such a decision has lots of rules, complex rules, rules that change a lot or rules that can only really be understood by someone with specific non-IT expertise, a BRMS is often how the business or someone in IT will suggest it be implemented.
What we do notice is that IT is often the group that comes back and says “wow, we have lots of decisions like this, maybe we should do this on a broader basis” and drives an enterprise policy hub or enterprise decisioning backbone choice. Once that choice is made we do see some “bottom-up” use of business rules.
I wrote a post on how rules empower collaboration here.