Just wended my way through the blogosphere from Joe McKendrick’s discussion of EDA and SOA to a transcript of a conversation on EBizQ about the relationship between BPM and SOA. I’m still struggling to come to terms with the issues that people have in this space given that I believe that service-orientation is all about structure – i.e. what gets done – whilst processes are all about implementation – i.e. how things get done – but a few things stood out in the conversation that I really disagreed with.
Firstly there was a general consensus that SOA was a technical ‘thing’ whilst BPM was a business ‘thing’. A representative comment here would be this statement from JT Taylor:
“And the reason is, is because SOA, first off, as I’ve think we’ve agreed is a very technical approach to delivering a collection of services.”
Any regular reader of this blog will know that I wholly refute this kind of argument – at the end of the day SOA – or service orientation as I prefer to call it – is a conceptual model that allows us to attack complexity and increase adaptability through componentisation. I strongly believe that this conceptual model has equal applicability in a business context – lowering transaction costs will open the door to greater specialisation but such opportunities will rely on an ability to componentise the business in order to understand what services make up a total offering to customers. In this context service-orientation – as a discipline – has much to offer.
The other major thrust that I took issue with was the assumption that you start with business processes and then try and find services from these. Another representative set of comments from JT Taylor (who was supported by the other participants, I must stress – his comments were just the most quotable in this context):
“I guess my opinion is that the business processes should govern the organization behavior and systems should support that. So I would actually start from the process angle first and then take the SOA approach as an implementation approach.”
I’ve discussed before why I think that this is a poor model but basically I believe that we need to first separate what gets done before we start to get into the detail of how to do it. As a result I believe that the appropriate place to start is with higher level abstractions – call them business capabilities, business services or whatever – which capture metadata and information about the structural properties of an organisation and their required outcomes – before you start looking at how you implement them.
More broadly, however, I believe that the relationship between SOA and BPM is essentially fractal based on the ‘what’ and ‘how’ dimensions I’ve discussed. Essentially the questions are:
- What do organisations offer their consumers? um services.
- But what implements those services? um. business processes.
- And what do business processes consume? um services.
- And.. um where was I again?
Again to stress the point: services describe what the organisation does and to what level (in terms of metrics and commitments) whilst business processes describe how each individual service is implemented and the commitments met (and the model is fractal). That’s why I believe that the notion of starting with BPM (which is a technology-oriented view of business processes, btw) is upside down – what’s the service you’re implementing again….?
:: 
:: 
:: 
:: 
:: 
:: 
:: 
:: 
:: 
:: 
:: 
