I was covering the BPM space for a while before I moved on to manage the SOA stack here at TIBCO. The repeat question I get asked from both sides of the fence is: what is the difference between BPM and SOA? It’s an interesting question with a myriad responses and I choose to start my series of blog posts here on this community, on BPM, on this particular topic.
BPM and SOA are two sides of the same coin, as one of my colleagues pointed out to me, in my early days at TIBCO. Another more concrete response – if 80% of your process is people centric and 20% systems centric, you are looking at BPM vs the other way for SOA. I’ve heard this one too – it’s all about the user, a more business centric user trying to define a process at the business layer needs BPM vs a technology-deep user defining a process at the systemsy layer, who needs SOA. I like this last one best: BPM is about extracting high level turnkey business processes and managing them as though they were assets in your organization, while SOA is about rewiring the IT plumbing in your infrastructure for efficiency and reuse; You need those business process assets to leverage your IT plumbing and you want your IT plumbing to always align with business process requirements.
While all these responses hold truth in them, the more I’ve worked in both spaces and closely followed them, I realize that the lines are blurry which is why people ask this repeat question. And when you think about it, a user wants to talk about finding a solution to the problem he has on hand, rather than be bombarded with three letter acronyms such as BPM and SOA. Vendors such as TIBCO are in a unique position where we have eons of experience in both areas that can leverage across product offerings so we cater to exactly this: provide the solution rather than a piece of technology that should be very carefully mapped to the problem.
Another point that is imperative: for the most successful SOA implementations, BPM and awareness of business processes is critical. Only then can you quantify and measure metrics against the business as well as design for the business, rather than just tweak and churn against technology for efficiency. If you read Paul Brown’s book on: Succeeding with SOA (highly recommend), he touches on this all through, where he talks about realizing business value through architectural design.
And the counter, at every point that a business process leverages the underlying infrastructure, a good design will allow it to reach out to an SOA implementation so there is always a loose coupling between BPM and SOA; rather than to hard coded systems interfaces to your business process. This loose coupling between BPM and SOA will allow one layer to change independent of the other. When you re-provision your IT infrastructure, you don't want to bring down your business processes, do you?
It’s important for BPM and SOA offerings to work well together – the BPM offering should be able to call out to the SOA services and orchestrations at design time with a few clicks of the mouse and work seamlessly at run time. And an SOA process should be able to call out to BPM centric processes without extensive work or rewiring. The best designs are from experience in both areas. My take, stick to your expertise be it SOA or BPM but learn extensively on the other area and attend conferences in both areas so you know what's happeninig on the other side of the fence before you sit down to design your architecture.
The takeaway is that BPM and SOA are interdependent and for good reasons, the best implementations leverage the strengths of both while keeping them decoupled.
In my next blog post, let’s look at what end to end business process management is all about before we dive off into the world of process modeling. Business process modeling is my favorite area where I’m hoping to explore with this audience, efficient process design using Business Studio. You can take a quick peak at Business Studio by visiting our developer center: Business Studio Developer Center
