ITIL basics

Peter Strempel

One of my strengths is IT service management (ITSM), including experience with IT strategic planning and operational management based on the ITIL methodology.

ITIL comprises a complex area of domain knowledge, and I will limit my discussion to basics that might be of most use to anyone not already familiar with the methods and practices. That isn’t to say I cannot help out with existing and advanced implementations.

On this page I will –

What is ITIL?

Bringing order and manageability to the chaos that used to be IT services in the 1990s and 2000s was the vision of what was then the IT Infrastructure Library (ITIL) of best practices.

ben Gossner on petter Strempel's ITIL skills

The name has stuck, even if it is probably more appropriate to think of it today as the ITIL framework for IT Service Management.  Since the 1990s, this methodology has undergone many transformations, and is today a proprietary, for-profit joint venture between the British government and transnational outsourcing corporation, Capita, operating as Axelos.

This business has attempted to position ITIL as a de-facto standard for ITSM, which it is not.  ISO 20,000 represents that prescriptive standard world-wide, and while there are similarities between ITIL and the ISO standard, ITIL is merely a guide to professional practice.  The decision between adopting one or the other is about any need to comply with strict standards as opposed to focus on improving organisational practices in a way that is not mandatory.

Axelos’s latest re-vamp of ITIL to version 4 occurred in February 2019.  This first major change to the set of methods and practices since 2011 appears largely cosmetic, with three exceptions: ITIL now seeks to embed enterprise architecture, business process analysis, and agile methods, but without enough guidance in its publications to create a thorough ITIL competence in those areas.

The cosmetic changes aside, the core of ITIL remains unchanged even if some of the wording has changed, and some models are no longer visualised the same way.  That core is the idea that IT exists to serve an organisation’s functions as a service.  Hence the goal is to transform it from a cost-centre into an asset via ITSM.

Service catalogues, portfolios & SLAs

The goal of ITSM is to transition to a process where IT components are bundled into services, and listed in service catalogues. Sometimes the catalogues are large enough to be split into several layers–such as software, hardware, and support–making up a service portfolio of catalogues.

These catalogues are then used by clients to choose the services they want, at transparent costs, and with guarantees of delivery conditions, service performance, penalties, and support expectations written into service level agreements (SLAs). See Figure 1 below for a visual representation of the interactions necessary to make ITSM work as it should with ITIL methods.

ITSM architecture
FIGURE 1: arriving at ITSM service level agreements requires an entire architecture of interactions, processes, and services.

The diagram shows that underlying any agreement are existing service offering in software and/or hardware, consolidated into service catalogues, which can include re-packaged third party vendor services too.  When clients require a service, the negotiation process should begin, as a matter of best practice, with enough of an audit of client needs by the supplier to offer value-added suggestions about best alignment of services to intended outcomes, and, where possible, cost savings over original expectations.

ITSM must be continuously focused on business justifications, underpinned by value streams (meaning each component is focused on delivering value to the client), for the existence of each item in a service catalogue.  In larger organisations, or IT-specific enterprises, that might lead to the concentration of a service catalogue, or multiples of them, into one or more distinct service portfolios catering to a particular type of requirement from end to end.

An ultimate goal of ITSM might be to create service portfolios recognised as valuable enough to be treated as profit centres in their own right, as distinct from IT being regarded solely as an unavoidable cost of doing business.

Amazon, Google, and Microsoft are examples of organisations whose own use of IT led to the development of service catalogues on offer directly to customers, like infrastructure as a service (IaaS) and software as a service (SaaS). A spectacular public sector example was the decision by NASA to release its entire 2017-2018 software catalogue free of charge to the public.

Smaller organisations can also develop capabilities valuable enough to others to offer as commercial services.  For example, a bicycle repair shop with only five employees might invest enough time and effort, as part of its main lines of business, into developing a content management system listing hard-to-find parts, as well as buyer and seller networks.  Over time that system might integrate other kinds of niche information into a custom build of an open source software application (perhaps in WordPress or Drupal), making that custom build an attractive IT resource to lease or buy for other businesses pursuing similarly niche parts, vendors, and related information.

One of the most critical aspects of negotiating SLAs, yet often overlooked in a blinkered ITIL practitioner’s process-oriented focus is client expectation-setting, which simply can’t be done by trying to emulate an ITIL model.  It requires genuine understanding of client requirements, and empathy for the client’s circumstances, and a sophisticated understanding of the scope and limits of every service component being considered.

Not that failure should ever be considered, but the biggest strength in any service disruption or failure is people: the personal relationships that are created and developed; the sympatico of outstanding service support people; and the demonstrated willingness of support contacts at all levels not to rest until problems are fixed as a matter of urgency.

Figure 1 above presents a simple architecture.  In reality there could be many more layers (swimlanes), with much more detail for every layer.  However, even this simplification implies that some ITIL basics must already be in place and operating smoothly.  These are described in the section on the ITSM lifecycle below.

I have been lucky enough to be a principal in designing an ITIL ITSM system from the ground up in a transnational travel services company, giving me invaluable insights into how existing IT services can be transformed for ITSM best practices, and how to improve on initial efforts.

The ITSM lifecycle

The best practice goal of most organisations pursuing ITIL methods is to have mastered ITSM to the point where its lifecycle is a stable, normal mode of operation.

ITIL lifecycle
FIGURE 2: the ITIL version of a continuous improvement cycle for ITSM.

Although ITIL v4 no longer uses a lifecycle framework, like so many contemporary management tools, ITIL’s basic structure is nevertheless formed around the Shewhart-Deming continuous improvement cycle, and can be effectively visualised that way.  See figure 2 to the left.

To undertake planning for a completely fresh service strategy and design is rare, but I’ve been fortunate to have been involved such an undertaking for the IT division of a transnational travel services corporation.

The effort in such circumstances is very specific to individual circumstances.  Coming in to help out with existing strategy and design is slightly easier because some parameters have already been set.

The trick to getting things right lies in the service transition and operation phases, illustrated in Figure 3 below.

Transition and operation management

ITIL transition and operation
FIGURE 3: my representation of ITIL service transition and operation processes.

The diagram compresses some of the steps and processes in the proprietary ITIL methodology, and shows that central to effective implementation and normalisation of service management is the ability to keep track of all configuration items and their individual configurations.  That means tracking assets like phones, computers, and peripheral devices like printers or routers and modems.  At the same time, there must also be a system to track all different ways these hardware assets are configured with software, by version, customisation, and combinations.  Typically, this is stored in a configuration management database (CMDB).  For smaller organisations, this doesn’t need to be any more complex than a spreadsheet.

Service management also requires knowledge management, meaning all the information acquired in establishing service management, resolving events, incidents, and problems, and any other experiences connected to continuous improvement, are documented and made available in a knowledge repository.  That could be the CMDB, a separate database, a teamwork software system, or just a shared directory on a file server or cloud resource.

The downside?

Unfortunately, the logics of the ITIL methods are now driven chiefly by the profit motive embedded in a lucrative training and certification business, which relies on frequent change for the sake of being able to charge for ‘updated’ training and certifications.

Some critics also charge that ITIL has become bureaucratised, elevating strict adherence to process above common sense, and promoting unnecessary IT management costs.

This can all be true if practitioners are too heavily reliant on only ITIL as an intellectual and professional resource.  It can limit their perspectives and narrow their problem-solving capabilities.  Those potential limits are not addressed by adding more concepts to ITIL–like agile, business process management, enterprise architecture, or knowledge management–if there isn’t sufficient depth to the description and training for those practices.  It seems likely that over time these shortcomings can be addressed by re-conceiving of ITIL as only one competency in a chain of competencies required by an IT professional–which is not necessarily the same as an ITIL practitioner.

Because I am multi-skilled across a comprehensive range of professional disciplines, and to an expert depth of experience, I can apply ITSM within its wider strategic environments, and to a greater level of detail than practitioners whose sole qualification is ITIL certification.  Most importantly, this means less bureaucracy and cost because I avoid the slavish adherence to textbook models that is demanded in ITIL training and certifications. Instead, I customise the necessary methods and processes to elegantly complement your existing strategy, goals, and operational environment.

Talk to me today about how I might be able to help out with your ITIL processes and ITSM operations.

Separate pages offer more detail on my skills and experience with:

RELATED: Read my case study on the 2016 online census project to understand how some discipline with ITSM might have helped prevent an operational disaster.