Getting IT "Just Right"

3 Jul

The more I read on Steve Jones blog the more I find to like about what he has to say.  One of his recent posts discusses the futility of trying to cover every eventuality by producing a paper trail long enough to circle the earth and the moon one million times.  I’m really interested in this whole area of ‘just enough’ consideration as I think that one of the keys to business agility is to make more appropriate decisions about solutions that match the reality of the business capability that requires them.

In one of my previous posts I’ve discussed the phenomenon (you’ll have to dig for it as the post wasn’t specifically about that) of ‘enterprise IT’ as often delivered by IT departments – and in particular enterprise architecture efforts -as basically being inappropriate for everyone rather than right for anyone; the basic premise was that:

  • Small, nimble parts of an organisation have to contend with huge lumbering infrastructures enforced upon them at more cost than they can afford and more importantly that make everything move much more slowly than they can live with.  In particular – as Steve points out – IT departments generally want to consider every possible usage that could ever be made of a solution by every other part of the business and therefore deliver a solution that is way beyond appropriate “just in case” or alternatively force the new functionality into an existing ‘box’ even if its cost or capability isn’t wholly appropriate.  This includes the sorts of inappropriate questioning and high beaureacracy that Steve talks about, which is a result of trying to make everyone fit the same profile; and
  • Larger business capabilities get an environment that may approximate to their needs but they also end up subsidising other areas of the business because they pay for infrastructure and software that then gets used by everyone.  This leads to all kinds of bun fights and ill feeling about who funds upgrades or extensions forced by capacity etc, particularly as IT departments are generally not able to deliver true shared services due to a lack of service enablement capability (i.e. service management, usage billing etc.).  At the same time whilst larger units may get appropriate IT from the context of scale or function they still chafe against the beaureacracy and tardiness of change that their supporting IT delivers.

In general the issue is threefold; basically IT people are a) looking to cover themselves against failure because they take such a beating from their business colleagues about value for money and so they try to imagine every potential future use case to protect themselves against accusations of ill-preparedness, b) they can only afford to manage a limited solution portfolio cost effectively and so try to squeeze every business need into this limited space – essentially the focus is on making life easier for the IT department by standardising rather than on delivering the right ‘size’ of solution with the right characteristics at the right time and c) there has traditionally been a lack of abstractions that allow IT to understand what a ‘right sized’ solution looks like for each business capability that they deal with.  All of these things have traditionally resulted in the ‘shadow IT’ so bemoaned by enterprise architects as end users take the issue into their own hands and bypass the IT department completely.

Now the reason that this area interests me is because service-orientation deals with the third issue and thereby enables us to think differently about the first two – i.e. it provides a set of abstractions that allow us to reason about the business capabilities that we need within the organisation, the levels of service we need from them and the costs we can afford to bear in their provision.  Essentially SOA breaks the organisation down into a set of collaborating service providers (i.e. capabilities) and thereby delivers an optimal problem solving layer not previously available.  Whereas in the past the problem solving layer has been the technology in the form of application portfolios – linked, if we’re lucky to some loose notion of business processes – the focus can now move to the ‘what’ in place of these ‘hows’.  This is a significant change as it allows us to see the wood for the trees by moving away from standardisation on applications and technology and into standardisation of capabilities.  This delivers a much clearer statement of the context in which IT needs to be delivered if it is to realise capabilities in a way most appropriate to the environment in which they operate – i.e. a capability that needs to be operated at low cost and which changes a lot is unlikely to be a good candidate for squeezing into the ERP implementation that we have; as a result we will need to find a way of providing service to this capability that much more closely matches their needs. 

So what does all this have to do with Steve’s post about people covering their arses?  Essentially I believe that this helps us in three main ways:

  1. We can much more rapidly agree what needs to be delivered because we can have conversations with our business partners centred around what needs to be done rather than suffer the traditional impedance mismatch between business and IT.  This makes agreements – in the form of contracts, service levels and costs – much easier to formally document and removes a whole layer of arse covering from the process aimed at caveating everything to cope with the essential lack of understanding between the partners involved;
  2. As IT people we can much more easily understand the needs of the business areas with whom we deal and rapidly see what level of provision is appropriate based on the characteristics of the capability i.e. does it differentiate? what scale does it operate at? how often does it change?  how much can we afford to pay for it? is it highly regulated? etc.  These characteristics give us a clear field of operation when considering the degree to which we need to cater for Albanian watch sellers (lol) and to therefore source IT that aligns more realistically with the needs of the consuming business capability.  This again removes the need for endless speculation about what might happen in 5 years time as the commitment of the IT organisation is either to deliver a service within the constraints identified or to decide that they can’t do it and help outsource the IT (or even the entire business capability) to an external provider; and
  3. Separating the delivery of the IT required by different capabilities (at least logically) enables much more rapid change since we can reduce the dependencies between different business capabilities.  We do this by concentrating on service dependencies and shared capability rather than by forcing shared use of technology.  Where we do share technology – infrastructure, applications and platforms – we maximise the virtualisation of this provision so that we’re really offering shared technical capability on a multi-tenancy basis rather than trying to squeeze everyone together and thereby coupling them and reducing their ability to change independently.  This will require IT departments to either deliver real service delivery platforms – which include the capabilities needed to enable both themselves and their business partners to deliver what they do as a managed, billable service – or partner with external utility computing providers who can offer them this capability as a service.  Enabling much more rapid change by implementing a more flexible IT model would further reduce the need for arse covering as a) we would have a better relationship with our business partners due to improved service provision and b) changes can be accommodated much more rapidly and therefore the need to plan for all eventualities to save time ‘in the future, maybe’ would be much reduced.

All of these things drive towards putting much more pressure on the business to describe what they do and equally importantly on IT to make what they do far more transparent and to be more pragmatic in the way in which they do things.  Essentially as focus falls increasingly on getting the right IT at the right time and at the right cost IT departments can’t afford not to become far more flexible and less dogmatic, since the rise of SaaS and external service provision will increasingly give people easy alternatives to the monopoly we’ve enjoyed over the last 30 years.


3 Responses to “Getting IT "Just Right"”


  1. Differentiation vs Integration (Addendums) « IT Blagger 3.0 - June 22, 2010

    […] both in terms of technology support and change processes – on capabilities within the business (something I talked about a while ago).  Essentially the need to standardise for operational IT efficiency tries to override the […]

  2. Differentiation vs Integration (Addenda) « IT Blagger 3.0 - June 22, 2010

    […] both in terms of technology support and change processes – on capabilities within the business (something I talked about a while ago).  Essentially the need to standardise for operational IT efficiency tries to override the often […]

  3. Will CIOs Fail on Cloud? « IT Blagger 3.0 - July 4, 2011

    […] based on technology ‘standardisation’. Many of the technology standards they adopt are often inappropriate for large areas of the business, however, where business capabilities have business models different to those that drove the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: