ITIL and the end of IT

Originally posted on 2/12/2008

There’s a lot that’s been written on the problem of “aligning IT with the business”, and it’s a problem I’ve been thinking about quite a bit lately (see Who needs IT?). A Google search a few minutes ago returned over 2.5M hits for “information technology business alignment”, so it’s clearly something that is top of mind for folks both in and out of IT.

One of the more concerted attempts to improve the alignment between IT and the wider organization is the Information Technology Infrastructure Library (ITIL). ITIL is a complex subject that, like CMM, inspires passionate sentiments for and against – a quick look at the discussion postings on Wikipedia gives a good idea of the tenor of debates that can go on over ITIL.

Without delving into a detailed summary of ITIL, here’s one way to think about what it is:

1. Make a list of all the activities that a well-run, world-class IT department must do to be effective, efficient, and successful.
2. Ask IT professionals from lots of other organizations across all industries to do the same.
3. Take all the lists, reconcile and merge them, and then organize the resulting activities into process groups.
4. Document the inputs, outputs, controls, and owners of each process group.

What would result is a large-scale framework for an idealized IT organization, i.e., the processes that such an organization would need in theory to be successful, regardless of size, structure, location, or industry.

This is pretty much, at its most basic level, what ITIL is: a set of guidelines or suggestions for each of the processes that should be a part of an IT organization. But because ITIL is only a framework, it is not concerned to prescribe how these processes should be implemented, nor is it meant to be implemented whole cloth – it is up to each organization to determine which parts of ITIL make sense to adopt and then to decide how to do so.

One of the core tenets of ITIL, more fundamental than all the processes that make it up, is the view that an IT department is at its heart a service provider – all of its technology and engineering work is not first and foremost about the software, hardware, data, and so on that are generated, but rather about services provided to customers, whether internal (“the business”) or external (“the customer”).

ITIL helps an IT organization become a service provider by encouraging it, more implicitly than explicitly, to view itself as a stand-alone entity that has the rest of its organization (“the business”) as a customer. Looked at from this perspective, ITIL succeeds because it pushes an IT organization to operate as an IT consulting firm must: if it had to peddle its wares on the street (rather than being a “sure thing” shared service), what would it take to stay in business?

There’s an interesting paradox in the way ITIL works, however: it effects better alignment between IT and the larger organization not by more closely integrating the two, but by pushing them farther apart. ITIL takes the typical IT organization, which is often only half-heartedly or partially integrated with the rest of the company (see Figure 1), and severs it completely, externalizing IT (at least conceptually) so that it will see itself as competing to provide services to a customer rather than as a shared service cost center with a guaranteed existence (see Figure 2). 

FIGURE 1 

FIGURE 2 

Whatever you do or don’t think about how ITIL articulates the processes and activities that should make up a successful IT organization, there’s little doubt (to my mind at least) that encouraging an IT organization to view itself as an external service provider will improve its chances at being successful in meeting the needs of the larger organization it’s a part of. Despite this, I have doubts whether externalizing IT (and ITIL is just one way of achieving externalization) is a desirable long-term solution to the challenges of “aligning IT and the business”.

Instead, I wonder whether what’s really needed – in the long term – isn’t a centripetal dynamic to drive the activities of an IT organization closer to the activities of the larger organization rather than farther away. 

Really, at the most basic level, IT activities are business activities (product development, customer service, operations, marketing), so another way to “align IT with the business” could be to do away with a dedicated IT department altogether. In its place, you would just have IT folks working alongside their non-IT counterparts to deliver services to customers. They might be focused on web analytics while their counterparts are concerned with response rate to a collateral mailing, but both are involved in marketing activities; or they might be conceptualizing and building a website instead of developing a product offering, but both are involved in product development. And so on.

In some sense, the most recent version of ITIL (v3) is already moving in this direction by embedding the processes needed by a successful IT organization within the life cycle of a service:

1. Service Strategy – Determine what service to offer
2. Service Design – Determine what the service will look like
3. Service Transition – Release the service into production
4. Service Operation – Support the service in production
5. Service Improvement – Improve the delivery of the service

Leaving aside the ITIL-specific terminology, these are basically the steps any organization should take (IT or otherwise) when deciding to provide a service to customers. And so ITIL v3 can be seen as a way to encourage IT to function the way the rest of the organization already does, although it still, for the most part, exerts an externalizing influence on IT. I’ve just been coming more and more to think that the true solution to the problem of “aligning IT with the business” is to end IT, which presents another, potentially more difficult problem in its place: what exactly would (could, should) an organization with a fully-integrated IT function look like?