Bottom Up or Top Down (ahem)

2 08 2007

In a related discussion to my previous post Nick Malik and Joe discuss approaches to delivering SOA within the organisation.  I am wholly onside with Nick’s notion that the key advantage of SOA is the ability to federate decisions about implementation out to the individual service providers and that the role of enterprise planners is to facilitate connections across these providers in a light touch manner.  As a result I believe that the identification of the capabilities required by an organisation – along with their responsibilities and metrics – belongs with enterprise planners but that anything from this point on  is federated out to service providers (whether internal or external).  Essentially I feel that the best way to manage service orientation in a sustainable way is to concentrate on metricisation and monetisation and leave the rest to the ‘market’ (whether internal or external); essentially let self interest flourish within the bounds set by the organisational context as long as it delivers cost-effective services but punish it by outsourcing where it doesn’t.

As I understand Nick’s description of his view of middle out I believe that it is similar to the combination of top down and bottom up that I’m describing here.  I think that this is on the money as neither top down nor bottom up are sufficient on their own; you need top down to deliver the systematic view of the enterprise required to support adaptability and effective sourcing but at the same time need to empower people at the edges (i.e. the bottom) to deliver on their commitments rapidly and in a way that meets their needs.  As a result I believe that the best approach is a combination of governance and anarchy – govern the commitments assigned to the atomic parts of the business but delegate all further implementation concerns to the owners of these atomic units (and this obviously cascades downwards given the fractal nature of services).  In this context there may be many duplicated services implemented but this is OK; where there needs to be duplication to support independent operation or because individual services are not economically viable for implementation by a third party there can be, whilst for services that can economically be shared joint ventures or enterprising third parties will emerge to profitably fill these spaces in a way that is sustainable (i.e. the services can be profitably sold and thus sustained rather than just being an overhead and a source of drag on each provider – which is where the link back to my previous post pops in).  This approach contrasts with some of the more naive approaches to service-orientation I have seen where people obsess about forcing business units into the use of shared services that are not actually economically viable and which – at the same time – prevent them from adapting independently in response to market changes.  Essentially services become an onerous tax imposed by IT rather than a real enabler for change and value creation.

Decide what you need and then depend on the endless ingenuity of your colleagues, partners, customers and suppliers to deliver a response without trying to control how they deliver.  You’ll unleash a whole lot more innovation, much more rapidly – and that will be to everyone’s benefit.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank





SOA and Market Forces

2 08 2007

Just a quick comment on a post by Joe Mckendrick while I’ve been on holiday.  Essentially Joe discusses the need to demonstrate the value of IT – and hence SOA – through ensuring that people are charged correctly for their consumption.  As I’ve discussed many times I totally agree with this with one exception; basically I feel that organisations need to get a more coherent view of their business capabilities and then charge for the delivery of those capabilities.  At the end of the day IT has no value to an organisation beyond its contribution to the delivery of discernable business value.  As a result the requirement from my perspective is to use metrics and charging to surface two different but related issues for both the enterprise and the owners of individual capabilities:

1) Is the business capability offered to the enterprise at a competitive price; and 2) Does the cost of the IT needed to run my capability enable me to be competitive. 

I believe strongly that current one-size-fits-all approaches to enterprise architecture will rapidly be exposed as one-size-fits-nobody as capability owners understand the costs of IT provision and the enterprise gets better metrics with which to squeeze them. 

As a result, apportioning the costs of IT to each capability owner and then allowing them to cross charge for the total service that they offer seems to me a more visible and sustainable way of demonstrating value.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank