What IT service management can learn from DevOps

There is a battle raging in management circles about the best way to approach the business of IT, with two major schools of thought vying for dominance: IT Service Management (ITSM) and DevOps.

ITSM favours a formal, planned process for organising IT, while DevOps emphasises a more fluid, dynamic style, free from the shackles of bureaucracy. They are, if you ask the most strident advocates of either approach, the antithesis of each other.

So who is right? And what even are these approaches, anyway?

What is ITSM?

Information Technology Service Management began life inside IBM in 1972, the fruit of eight years of research into Information Systems Management Architecture (ISMA) which culminated in the publishing of A Management System for the Information Business in 1980.

These ideas were further built upon in 1986 in the United Kingdom by the Central Computer and Telecommunications Agency (CCTA) - a government body given the unenviable task of improving IT quality and efficiency. CCTA by this stage had already developed the Structured Systems Analysis and Design Method (SSADM) for software development, and the PRojects IN Controlled Environments (PRINCE) approach to project management.

A team led by Peter Skinner and John S. Stewart worked with several consulting companies, including IBM, to develop the somewhat cumbersomely named Government IT Infrastructure Management Method, or GITTMM. IBM supplied the CCTA team with a set of IT service management checklists derived from their work on the aforementioned ISMA, and the team expanded on these concepts to define known good (‘best’) practice. The guiding principle was, according to Stewart, simple:

“A standardised approach could be tailored by individual organisations as a basis for their own, repeatable processes.”

GITTMM was later renamed to IT Infrastructure Library (ITIL) for two main reasons: firstly, because it wasn’t a method, and secondly, having the word ‘government’ in the name would have discouraged adoption of the ideas outside of government departments.

ITIL essentially defines what process an IT organisation should follow for everything from how to deploy a new application to how to define security policy to how to track software licenses to how to handle support calls. And over three decades after the need for such an idea was first recognised, ITIL is today more or less ubiquitous. If judged by Stewart’s conception of the Library’s central principle, the project would have to be considered a resounding success.

And yet the original problem it set out to solve – that IT projects were not living up to expectations of high quality or low cost - doesn’t appear to have been solved.

After nearly 30 years of ITIL in practice, we still read of routine and large-scale IT failures, such as the Queensland Health payroll debacle, Victoria’s failed CenITex experiment, and a series of outages - some over a week long - at institutions as proud as the Royal Bank of Scotland.

The pages of iTnews are continually filled with arguments as to why.

Networking consultant Greg Ferro is an outspoken critic of ITIL.

“The fundamental ITIL premise is that technology work can be segmented like machines or work functions in a factory where each task can be assigned to a machine with fixed human resources applied to the task and funding applied to the machine,” he says. “This simply doesn't work when the factory machines and processes undergo transformational change every three to five years.”

“ITIL is not about delivery or excellence. In my experience, ITIL and PRINCE2 prevent excellence through a focus on deliverables and cost management.”

He is adamant that ITIL has had its day and it’s time to move on.

“Over the last decade I have worked for tens of companies that use ITIL/ITSM models and all of them are were miserable and unhappy workplaces,” he says. “When I have worked in companies that don't use ITIL , I found they were a great places to work while real business value was being created and delivered.

“It's about happiness. ITIL equals misery and unhappiness. Who wants that?"

Read on as we explain the opposing school of thought...