The most successful innovations change the way people think, and how they behave. That’s been true throughout human history. We can see this from the way scientists describe pre-historic periods: iron, bronze age and so on. They are named for the revolutionary tools that shaped the achievements of the age. On that basis, we are most certainly in the IT age.
All the terms are umbrella terms covering a range of related innovations – different iron tools, range of bronze alloys and, of course, the whole range of IT sub-species that technology has spawned since the 1960s. Among those is IT Service Management, and the primary tool for that was, and still is, ITIL. In this blog I want to look at how, despite its age and the changing environment around it, ITIL still has value today. But while considering the iron and bronze ages, let’s notice one thing: just because we aren’t living in the iron age any more, doesn’t mean we aren’t still using iron tools. That is an important concept that will underpin our positioning of ITIL.
Once upon a time…
ITIL emerged on the scene in 1989, and became well known and well used by the mid 1990s, becoming very popular because it filled a need. That need was for the ability to support IT services, and to do so in a way that helped the business do their jobs. The IT focus was on what cool new stuff could be built. Systems Analysts and Programmers designed and built the cool new stuff, tested that they could make a version run on their development environment and then threw it across to their lower caste colleagues in Operations to keep it going in the live environment. Those words I used may seem harsh in current times, but they were carefully chosen. When I passed my ADP (Automatic Data Processing) test in the UK government in 1987 or so, I was told I had scored in the top quartile, high enough to be a System Analyst or programmer; successful candidates with lower marks were put into Operations. This was the climate that ITIL was born into, with a self-determined remit to make Operations roles properly respected. After all, it is in Operations that the most damage can be done to a business, failing to introduce new ideas denies advantages and progress, but failed day-to-day support makes things worse, and very quickly too.
What did ITIL do for us?
At its simplest, ITIL formalised and documented what the best organisations were doing in terms of Service Operations. The first version of ITIL wasn’t built on original thinking, but on writing down what had been seen to work, as a basis for others to build approaches that would work for them, improving their Operations procedures. In that way it offered some real help to IT organisations through:
- Setting out ‘good ideas’ (they got to be called ‘best practice but that can be a confusing term): a place to start from instead of trying to invent everything
- Making IT Operations teams feel (more) valued and respected. There were now books written about the work they did, that had to be taking them seriously
- Raising the profile of Operations roles, attracting good people into this area and reducing the tendency for ‘good people to be promoted out of Operations’.
ITIL was the trigger for much of this, not because it was an especially clever approach, or innovative or advocating new approaches. It was the single major trigger because it was the only set of guidance addressing the area. In short it was the only game in town, a good product delivering value without any competition.
Doing it the ITIL way
As ITIL developed through the nineties and naughties, its scope grew and its take up grew massively. Going worldwide it generated a massive support industry in terms of training, qualifications, software and consulting that dwarfed the core product – the books: developing considerable momentum that still exists today. Much of the real benefit of ITIL has been that broad set of independent products connected by the underpinning terminology and concepts set out in the ITIL books.
Once that informal structure grew around ITIL it effectively locked the community into using the basic ITIL terms. For nearly 30 years ITSM professionals have been attending ITIL courses and coming away with the basis of a common language for discussing their industry. That common language has delivered the foundation upon which an industry and – more importantly – a profession has evolved. Such a pervasive underpinning structure is not going to disappear quickly.
New kids on the ITSM block
ITIL was the first set of guidance in this space, but that’s not true anymore. We have a range of frameworks, overlapping, complementing and effectively competing with ITIL. With all these newer approaches, maybe it’s surprising that ITIL has survived at all, let alone that it still seems healthy and evolving. In fact, just as we still use iron tools in the IT age, so ITIL still has value in this age of Devops, Business Relationship Management and customer focus. As iron usage evolved into steel tools , seeing iron and steel as integral parts of later technologies, so the core ideas of ITIL are still there in the new approaches we see around us in our ITSM industry. Go on a Devops Foundation course and you will be taught ITIL basics, look at COBIT and you will see process terms that are familiar to us from ITIL.
Primarily, that is because it is just common sense, the basic concepts that ITIL made us so aware of all those years back are sufficiently simple and fundamental that it’s hard to argue against them. And so any alternative, effectively, has to agree with them. What would be the alternative? How about Change management as an example? To disagree with the ITIL basic concept means we should just let folks get on with changing things without asking anyone, whenever they feel like it. Hard to see that as an improvement isn’t it?
Still the place to start
Of course, ITIL is showing signs of age, and we wait to see how rejuvenated it might be by the 2018 update. Some mainstays of ITIL are being openly questioned – such as the need for an SLA for every service. And cloud, multi-sourcing and other 21st century norms will mean an ongoing need to question things. But questioning guidance is what we should have been doing all the time. And that, in itself, is a great lesson: we all have the responsibility to make sure that guidance works, for us, in our unique situation, before we start to implement it. On that basis, ITIL’s visible ageing is an advantage in pushing us to think that little bit more.
What we can be sure is that the ideas that have survived 30 years are founded in good common sense, and if they have stayed relevant this long, then it can be safely assumed they will stay relevant a bit longer yet. The building blocks that ITIL supplies form a solid foundation for a wide range of approaches, and that solid foundation is a real asset to any organisation.
So – today – if you want to understand the basics of running services to support a business, ITIL is still the obvious thing to learn first. ITIL remains a good place to start, but it also remains a bad place to finish. As with all frameworks and sets of guidance, they should get us thinking, we need to adapt them to our situation. ITIL still helps us do that.