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: SOA,BPM, Service Architecture