questionmark1What are the key issues in thinking through the perennial ‘centralize vs. decentralize IT’ question?

This post was triggered by a question I received from a CIO over the holidays (yes, CIOs and management consultants don’t take holidays!)  He was trying to deal with a number of departments which insisted on having their own IT departments, with no accountability or responsibility to anything other than themselves.  (such departments are often referred to as “Shadow IT.”)  Sometimes these departments were interested in systems that were standalone and had little external impact, but more often these systems were interfaced, and the data and processes do impact other systems outside the department.

There are a number of issues behind this, but the key variable is business-IT maturity.  At low maturity, IT tends to be highly decentralized.  This may appear to provide a responsive and ‘customer intimate’ IT capability, but the reality is it does so at a huge cost to the enterprise as a result of redundant systems, unleveraged spend and resources, and the costs of supporting a heterogeneous IT infrastructure that typically results from highly decentralized IT.

Also, as competitive pressures and the need for improved coordination and business agility cause the discrete departments to move towards increased collaboration and more effective cross-departmental processes, they inevitably find the need for a more easily shared and consolidated IT infrastructure and common capabilities.  So, as IT drives up the maturity curve, it almost always needs to centralize – to get control of IT resources, capabilities and assets, and begin to rationalize and standardize them into a more efficient and sharable platform.  Further up the business-IT maturity curve, it may be both possible and optimal to decentralize certain IT capabilities.

The bottom line is that IT (like finance!) must be centrally controlled – no exceptions. This is not just leading practice, it is the only acceptable practice, whether you are looking from the perspective of security/privacy/business continuity, or from an audit or cost effectiveness perspective.  However, central control of IT does not necessarily imply that all IT resources and capabilities have to be centralized.  To clarify this, it is useful to distinguish between those IT capabilities that:

  1. Should be common and shared across the enterprise, i.e., have a value proposition of Operational Excellence (e.g., data center operations, networks, desktop support). These are typically highly centralized under IT.
  2. Are specific to a given business unit, i.e., have a value proposition of Customer Intimacy (e.g., opportunity discovery, very locally specific and rapidly changing local systems such as web sites). These are typically decentralized (more so in higher maturity environments, less so in low maturity).
  3. Are future/innovation oriented, i.e., have a value proposition of Innovation/Product Leadership (e.g., Enterprise Architecture, IT R&D). These are typically networked across the enterprise, with IT taking ownership of “Centers of Expertise”.  Again, this is more the case in higher maturity, less so in lower maturity environments.
  4. Are governing/aligning, including IT investment/prioritization/value realization, IT funding model, Enterprise Architecture, and decisions as to what capabilities are common and shared vs. business unit specific. These are most effective when they are business owned, and are implemented from the top of the enterprise.

Of special note here is item #4.  The business-IT governance and Enterprise Architecture mechanisms are typically either missing or weak (ineffective) in lower business-IT maturity organizations, which is why low maturity organizations must first focus on centralizing IT.  As governance strengthens and become more coherent, and as Enterprise Architecture strengthens and gets “teeth”, decentralization of items #2 and #3 becomes possible and, perhaps, desireable.

How does this thesis match your own experiences?  Have you seen situations that would argue against this thesis?  How might you apply this thesis to your own situation?  What can you do as an IT professional to help drive business-IT maturity in 2009?