Friday, May 04, 2007

SOA isn't about technology

I've been having various discussions recently around SOA where a certain mindset is coming over loud and clear. That mindset is that SOA is just a technology thing, its about the specific technical end points, and that above all these end-points are relatively fine grained, from a business perspective, and are there to enable "BPM" to shine through as the one true way to work with the business.

I've said it before and I'll say it again... business process isn't everything. Right now this focus on BPM is driven by one thing and one thing alone, the fact that every single vendor's stack tops out at business process. Now most of these don't even have a decent way of handling services (i.e. one interface = one process = what a load of crap interfaces you have) but that is beside the point. What they are proposing is that the IT/Business model looks like this

Its a simple stack based view of the world, business at the top, techy IT at the bottom and BPM as the medium for communication "at the business level", people who talk about this view tend to talk "bottom up" with "services exposing legacy and BPM orchestrating services". Its pretty amazing how this view just happens to match the product vendors stacks, this means that either
  1. This is the end of IT product development we have fixed it all, we are done
  2. Its bollocks
Now I'm backing option 2 on this list because I've worked with lots of businesses in various sectors and the most successful ones were those who used processes as required but who were primarily focused on goals and objectives with the actual implementation being flexible.

This is where SOA really earns its keep, not as the bit that delivers the solution but as the contextual framework within which that delivery can sit. SOA, and in particular a business service architecture, is all about understanding the various different "blobs" of the enterprise, how and why they interact and then choosing the right delivery approach for that service.
My view of the world has BSA being important, but as a contextual framework. When you get down to implementation you are still going to think about the specifics of the requirements or demands on an area and this means you will still have to speak to the business. The differences is that the BSA means you are talking within a business context where it has been decided that BPM/Technical SOA/GDA/EDA/People/Flying Monkeys/etc is the best way to solve that problem.

One size doesn't fit all, BPM is not the culmination of all IT. The challenge in IT and business remains the same, namely getting a contextual framework within which the problem domain can be understood and then choosing the right way to solve that problem. BSA isn't a hammer, its the plan that helps you decide when you use the hammer or when you use the saw.

BPM as the language of business is, IMO, snakeoil. I've heard many CEOs report on how their business is doing, I've heard sales directors report on sales... and I've never heard any of them step through a process of their business to describe where they are at.

Think first, plan first, then decide the way to go. Starting with BPM is as silly as starting with WSDL.

Technorati Tags: ,,


Anonymous said...


David J. Dougherty said...

I agree. My experience doing a lot of business process modeling in the Federal sector, is that it provides a much needed context to start analysis of the problem and solutions, and that's about it (except for interesting traceability mappings for EA). It's surprisingly difficult to get a group of business owners and IT people to a common (and accurate) understanding of the business process terrain before jumping to solutions. I've been advocating that BPM be a normal precursor to requirements analysis.

Ian Thomas said...

Steve, Bollocks. That's hilarious. I couldn't agree more if you were in my own head. My whole view of the world aligns very definitely with yours in that I see surfacing 'what' an organisation does through the business capabilities that it has (in your parlance the business service architecture) and _then_ deciding how you want to go about realising these. To be honest BPM (and processes in general) are a dangerous distraction at the top level of dialogue since they immediately dive into the detail of 'how' to do things before people have even decided whether it's a good idea but understanding the need for a capability that is supported by such a process. When you're looking at 'how' it's all too easy to feel that something is both important and necessary and thereby waste an absolute fortune creating or improving pointless processes. As a result I wholeheartedly agree with you. Lol.
I've discussed my view on a lot of this stuff on my blog with perhaps the most relevant post being here

Morgan Wadsworth said...

Business support is the first hurdle to SOA. No benefits seen, no money, no SOA. Perhaps SOA first then BPM second provides the most benefits, but the reality is sometimes benefits have to be shown quickly with real world savings. So in some Enterprises showing value using BPM to automate a few costly processes is simply a strategic approach to showing the benefits of business-technology abstraction.