Deployment management

ITIL®4 Practice Guide

AXELOS.com

11th
January
2020

AXELOS Copyright
View Only – Not for Redistribution
© 2020
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Contents
About this document 3
General information 4
Value Streams and Processes 11
Organizations and people 17
Information and technology 23
Partners and suppliers 25
Important reminder 27
Acknowledgments 28

AXELOS Copyright
View Only – Not for Redistribution
© 2020
2
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
About this document
This document provides practical guidance for the deployment management practice. It is split
into five main sections, covering:

● general information about the practice

● the practice’s processes and activities and their roles in the service value chain
● the organizations and people involved in the practice
● the information and technology supporting the practice
● considerations for partners and suppliers for the practice.

1.1 ITIL® 4 QUALIFICATION SCHEME

Selected content of this document is examinable as a part of the following syllabus:

● ITIL Specialist: Create, deliver and support

● ITIL Specialist: High Velocity IT
Please refer to the syllabus documents for details.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
3
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
General information
2.1 PURPOSE AND DESCRIPTION

Key message

The purpose of the deployment management practice is to move new or changed hardware,
software, documentation, processes, or any other component to live environments. It may also
be involved in deploying components to other environments for testing or staging.

The deployment management practice is responsible for moving a service or service component
into a designated environment. This practice enables the deployment or removal of service
components from or to different environments, including development, integration, live,
production, test, or staging environments.

The practice is usually applied to digital and physical IT components, including software,
hardware, documentation, licences, and data, within the agreed scope of environments controlled
by the organization.

2.2 TERMS AND CONCEPTS

2.2.1 Environments
The deployment management practice enables the move of products, services, and service
components between the environments.

Definition: Environment

A subset of the IT infrastructure that is used for a particular purpose.

A service component’s lifecycle may vary depending on its type and the sourcing approach. The
number and purpose of controlled environments within the organization may also vary. Table 2.1
provides a list of example environments for an organization that develops software.

Table 2.1 List of example environments for an organization that develops software

Environment Purpose

Development/Integration Developing and integrating software

Test Testing service components

Staging Testing releases including products, services and other configuration

items

Live/Production Delivering IT services to service consumers

AXELOS Copyright
View Only – Not for Redistribution
© 2020
4
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
For products and components sourced outside the organization, development environments can be
out of the organization’s control. For products and services delivered to service consumers outside
of the organization, control over the live environment can be limited. Other variations are
possible.

2.2.2 Continuous integration, continuous delivery, and continuous

deployment (CI/CD)
The key concepts for deployment in Agile and DevOps are:

● Continuous integration Integrating, building, and testing code within the software development
environment.
● Continuous delivery Continuous delivery means that built software can be released to
production at any time. Frequent deployments are possible, but deployment decisions are taken
case by case, usually because organizations prefer a slower rate of deployment.
● Continuous deployment Changes go through the pipeline and are automatically put into the
production environment, enabling multiple production deployments per day. Continuous
deployment relies on continuous delivery.

These approaches are supported by the software development and management, service validation
and testing, deployment management, infrastructure and platform management, and release
management practices. These practices involve specific skills, processes, procedures, automation
tools, and agreements with third parties. They enable the continuous pipeline for integration,
delivery, and deployment. This would also affect the design of other practices, such as service
configuration management, monitoring and event management, incident management, and others.

2.3 SCOPE
The scope of the deployment management practice includes:

● the effective move of products, services, and service components between controlled
environments, such as the development, live, test, and staging environments.
● the effective removal of products, services, and service components from designated
environments.

These additions, modifications, and removals can be part of authorized changes/releases triggered
by:

● new/changed service requirements

● new features/releases
● technical and operational changes
● third-party change requirements
● service retirements and removals
● support/troubleshooting
● service requests.

Several activities and areas of responsibility are not included in the deployment management
practice, although hey are still closely related to deployment. These are listed in Table 2.2, along
with references to the practices in which they can be found. It is important to remember that ITIL
practices are merely collections of tools to use in the context of value streams; they should be
combined as necessary, depending on the situation.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
5
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Table 2.2 Deployment-related activities described in other practice guides

Activity Practice guide

Authorizing changes/releases Change enablement

Making services and components in the live Release management

environment available to users

Developing software Software development and management

Developing and building infrastructure Infrastructure and platform management

components

Preparing and maintaining target environments

for deployments

Providing IT assets to be deployed IT asset management

Maintaining authorized repositories of service

components

Testing and validating services and service Service validation and testing
components

Naming, versioning, and controlling the service Service configuration management

components

2.4 PRACTICE SUCCESS FACTORS

Definition: Practice success factor

A complex functional component of a practice that is required for the practice to fulfil its
purpose.

A PSF is more than a task or activity, as it includes components of all four dimensions of service
management. The nature of the activities and resources of PSFs within a practice may differ, but
together they ensure that the practice is effective.

The deployment management practice includes the following PSFs:

● establishing and maintaining effective approaches to the deployment of services and service
components across the organization
● ensuring the effective deployment of services and service components in the context of the
organization’s value streams.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
6
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
2.4.1 Establishing and maintaining effective approaches to the
deployment of services and service components across the organization
The deployment management practice includes defining and agreeing a model or several models to
use when deploying products, services, and components. These models may use one deployment
approach or combine deployment approaches, depending on their specific services and
requirements and the sizes, types, and impacts of the service components that are being
deployed.

Models can be defined for deploying services or service components of similar types. Such
deployment models could be defined based on several factors, including:

● automation considerations
● costs/resource limitations
● expected frequency of the deployments
● rate of customer requirements change
● rate of technology change
● risks of components flaws
● source of the components
● user adoption behaviours and preferences
● visibility of the technology change to service consumers

Based on these and other relevant considerations, organizations define a set of models for the
deployment of different service components. These models may describe different solutions in all
four dimensions of service management. Table 2.3 outlines some example models.

Table 2.3 Example models for the deployment of different service components.

Deployment model Organizations and Information and Value streams and Partners and
applicability people technology processes suppliers

Hardware A service provider A range of tools can be An installation order can Third-party
components of should arrange a used to automate the be triggered by new or shipping,
services provided to delivery team for the procurement, changed value streams delivery, and
external service transportation and invoicing, user that include clear installation
consumers installation of the communication, and authorizations to procure service
components scheduling of the and install new hardware providers can
installation of be employed,
hardware as agreed
between the
Hardware According to the Vendor catalogues may Vendor activities, such as parties
components of delivery and be used for ordering invoicing and shipping,
services obtained installation clause in the components, as should be accounted for
from a vendor the vendor contract, well as to store and during the value stream
the responsibilities provide up-to-date design; interfaces
for obtaining installation manuals. A between parties need to
hardware and configuration be founded in the
ensuring its correct management tool contracts

AXELOS Copyright
View Only – Not for Redistribution
© 2020
7
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
installation should be should be populated
clearly defined with documentation
supplied with the
hardware, including
records and
documents, such as
warranty certificates,
maintenance
schedules, and so on

Software components The service provider An automated Service providers can Partners can be
of services provided can have staff deployment toolset is implement additional engaged in
to external service perform roadshows to utilized to make controls before a deployment,
consumers service consumers to software available for component is deployed, such as
promote new use or ordering such as quality assurance, additional
software components security, or commercial; itbespoke testing
and facilitate change is crucial to account for of the software
awareness such controls in partially- made available
or fully-automated by the vendor
deployment pipelines prior to its
deployment to
the consumer
environment.

Software components DevOps teams are The continual Service provider Third parties
of services developed likely to perform the integration and organizations have to can action
in house deployment of continual deployment establish organizational some steps of
software pipeline toolset can be controls over the course the deployment
used to deploy of deployment, ensuring model; for
software to a that controls are not example,
controlled environment excessive manual
environment
configuration
activities

Deployment models also define the flow of deployment through controlled environments,
responsibilities of the involved parties, triggers for deployment, and interactions with other
practices’ activities in the context of value streams.

These models may be flexible enough to adapt to changing circumstances, such as the scale,
urgency, or complexity of the deployment.

Deployment models, and the deployment management practice in general, should be a subject to
continual improvement with an aim to eliminate waste and increase effectiveness and efficiency.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
8
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
2.4.2 Ensuring the effective deployment of services and service
components in the context of the organization’s value streams
Ensuring effective deployment requires orchestrating resources in all four dimensions of service
management.

The effectiveness and efficiency of the deployment is significantly dependent on, and can be
considerably impacted by, the availability of the relevant resources, skills, technology, tools and
infrastructure. The effective use of technology and automation in deployment can improve the
consistency, agility, and efficiency of the practice.

For changes/releases to be successful, it is crucial that the changed/released service’s or service

component’s integrity is maintained throughout the move process. Any unauthorized change
through manual, process, or technology errors can negatively impact the objectives and outcomes
of the changes and releases, often significantly impacting the organization.

The success of service moves depends on the effective and efficient management of changes and
releases, which in turn depends on timely deployments that align with requirements and
objectives. Alignment of the deployment to the change and release requirements, as well as key
aspects such as schedule and cost, must be managed effectively.

2.5 KEY METRICS

The effectiveness and performance of the ITIL practices should be assessed within the context of
the value streams to which each practice contributes. As with the performance of any tool, the
practice’s performance can only be assessed within the context of its application. However, tools
can differ greatly in design and quality, and these differences define a tool’s potential or
capability to be effective when used according to its purpose. Further guidance on metrics, key
performance indicators (KPIs), and other techniques that can help with this can be found in the
measurement and reporting practice guide.

Key metrics for deployment management practice are mapped to its PSFs. They can be used as
KPIs in the context of value streams to assess the contribution of deployment management to the
effectiveness and efficiency of those value streams. Some examples of key metrics are given in
Table 2.4.

Table 2.4 Examples of metrics for the practice success factors

Practice success factors Key metrics

Establishing and maintaining ● Level of stakeholders’ satisfaction with the rate of change of
effective approaches to the products and services supported by deployments
deployment of services and
● Rate of adoption of the agreed approach to deployment
across the organization
service components across the
● Level of key partners’ and service consumers’ alignment with
organization deployment approaches
● Number of audit findings and external compliance issues
caused by deployments

AXELOS Copyright
View Only – Not for Redistribution
© 2020
9
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Ensuring effective deployment ● Level of stakeholders’ satisfaction with lead time to deploy
of services and service ● Percentage of successful deployments/number of
deployment errors/failures
components in the context of
● Number/percentage of incidents related to deployments
the organization’s value
● Timeliness/adherence to deployments schedule
streams
● Deployment backlog throughput
● Level of stakeholders’ satisfaction with quality of
deployments

The correct aggregation of metrics into complex indicators will make it easier to use the data for
the ongoing management of value streams, and for the periodic assessment and continual
improvement of the deployment management practice. There is no single best solution. Metrics
will be based on the overall service strategy and priorities of an organization, as well as on the
goals of the value streams to which the practice contributes.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
10
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Value Streams and Processes
3.1 VALUE STREAM CONTRIBUTION
Like any other ITIL management practice, the deployment management practice contributes to
multiple value streams. It is important to remember that a value stream is never formed from a
single practice. The deployment management practice combines with other practices to provide
high-quality services to consumers. The main value chain activities to which the practice
contributes are:

● Obtain and build

● Design and transition
The contribution of the deployment management practice to the service value chain is shown in
Figure 3.1.

Figure 3.1 Heat map of the contribution of the deployment management practice to
value chain activities

AXELOS Copyright
View Only – Not for Redistribution
© 2020
11
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
3.2 PROCESSES
Each practice may include one or more processes and activities that may be necessary to fulfil the
purpose of that practice.

Definition: Process
A set of interrelated or interacting activities that transform inputs into outputs. A process takes
one or more defined outputs and turns them into defined outputs. Processes define the
sequence of actions and their dependancies.

Deployment management activities form two processes:

● deployment
● deployment models development and review.

3.2.1 Deployment process

This process includes the activities listed in Table 3.1 and transforms the inputs into outputs.

Table 3.1 Inputs, activities, and outputs of the deployment process

Key inputs Activities Key outputs

Deployment requirements and Deployment planning Deployed service

expectations components/releases
Verification of the service
Environment details components Deployment records

Service component/release Verification of the target Deployment communications

components environments
Feedback and inputs to change
Hardware and software Deployment execution enablement, release management,
components from the service validation and testing, project
Deployment verification
authorized repositories of ITAM management, etc.
and definitive media library
Updates to onboarding procedures,
Acceptance criteria customer knowledge base, service
desk data

AXELOS Copyright
View Only – Not for Redistribution
© 2020
12
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020

Figure 3.2 shows a workflow diagram of the process.

In an Agile or DevOps environment that has adopted a CI/CD framework, many of these activities
will be performed in an automated fashion, without manual intervention.

Table 3.3 provides examples of the process activities.

Table 3.3 Activities of the deployment process

Activity Manual deployment to a datacenter Automated deployment of a

software component

Deployment After a trigger from deployment (often Deployments in automated

planning procurement or the change request initiator), pipelines are triggered by
the service provider will schedule the committing all of the necessary
shipping, delivering, verification, storing, and pieces of code to a branch of the
installation of hardware components. This development version control system
schedule will align with the priorities of that will contain software features
other work units for the affected teams and that are prepared for deployment.
other resources.

Verification of Upon receiving delivered components, the The code in the appointed branch is
the service service provider checks the completeness of deployed onto a suitable test
components the inventory, including the documentation, environment, tested, and any issues
and conducts basic quality checks before are fixed directly in the branch.
accepting the delivery. The ‘deploy, test, fix, redeploy,
retest’ cycle continues until a pre-
set quality threshold of automated
tests is met.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
13
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Verification of The item is delivered to the installation For an Infrastructure as a Code
the target location, where it is installed with an aim of solutions, the configuration of a
environments causing minimal disruption to the service virtual environment in which the
users. The installation location should have software should be run also follows
sufficient power, back-up power, air- an automated pipeline and is
conditioning, and fire protection deployed to the virtual resources
arrangements. It may be necessary to include alongside the software code.
target environment checks in the deployment
plan.

Deployment The service provider or an external supplier Deployment to an environment is

execution staff installs and activates the equipment automated, but can include
according to the installation instructions, additional human interaction steps
which may include intermediate checks. before the actual deployment to
account for business, security, or
other non-automated types of
verification.

Deployment After the item has been installed, a series of The version control system sends
verification tests is performed to confirm the equipment notifications to the change
is functioning. requestor, such as a product owner,
when the deployment is complete.
The staff performing the installation notifies
those who triggered the deployment of the
deployment results.

3.2.2 Deployment models development and review process

This process focuses on the continual improvement of the deployment management practice,
deployment models, and deployment procedures. It is either performed regularly or triggered by
deployment failures which highlight inefficiencies and other improvement opportunities. Regular
reviews may occur every three months or more frequently, depending on the effectiveness of the
existing models and procedures.

This process includes the activities listed in Table 3.4 and transforms the inputs into outputs:

Table 3.4 Inputs, activities, and outputs of the deployment models development and
review process

Key inputs Activities Key outputs

● Current deployment models and ● Deployment model ● Updated deployment

planning models and procedures
procedures
● Deployment records
● Deployment model ● Deployment models and
implementation procedures update
● Deployment failure reports
● Deployment model testing communications
● Policies and regulatory requirements
● Release information
● Change requests

AXELOS Copyright
View Only – Not for Redistribution
© 2020
14
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
● Configuration information ● Deployments review and ● Improvement initiatives
● IT asset information deployment records ● Deployment review
● SLAs with consumers and analysis reports
suppliers/partners ● Deployment model ● Updated knowledge
● Capacity and performance improvement initiation management articles
information ● Deployment model update ● Lessons learnt
● Continuity policies and plans and communication
● Security policies and plans

Figure 3.3 shows a workflow diagram of the process.

Figure 3.3 Workflow of the deployment models development and review process

AXELOS Copyright
View Only – Not for Redistribution
© 2020
15
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Table 3.5 provides examples of the process activities.

Table 3.5 Activities of the deployment models development and review process

Activity Description

Deployment model When a product follows a similar low-risk, high-success-rate deployment

planning pattern and there are means to eliminate waste and reduce deployment
lead times, the deployment manager may choose to define a new
deployment model. The deployment model should reduce the human
involvement and control over the deployment.

Deployment model The deployment manager arranges for appropriate pipeline tools to be
implementation configured to support the new model, such as access settings, code support,
or branching procedures. Alternatively, if automated deployment tools are
not applicable, the deployment manager establishes and communicates
adequate guidelines to the teams and parties involved.

Deployment model The deployment manager tests the new deployment model to ensure proper
testing edge-case handling and workflow. Where testing is impossible, the
deployment manager oversees the first of the model’s live runs.

Deployments review The deployment manager, together with service owners and other relevant
and deployment stakeholders, performs a review of selected deployments or deployment
failure records failures. They identify opportunities for the optimization of deployment
analysis models and deployment procedures.

Deployment model The deployment manager registers the improvement initiatives to be

improvement initiation processed with the involvement of the continual improvement practice, or
initiates a change request, if the deployment models and procedures are
included within the scope of change enablement.

Deployment model If the deployment model is successfully updated, it is communicated to the

update and relevant stakeholders. This is usually done by the deployment manager
communication and/or the service or resource owner.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
16
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Organizations and people
4.1 ROLES, COMPETENCES, AND RESPONSIBILITIES
The practice guides do not describe the practice management roles, such as practice owner,
practice lead, or practice coach. They focus instead on specialist roles that are specific to each
practice. The structure and naming of each role may differ from organization to organization, so
any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember,
roles are not job titles. One person can take on multiple roles and one role can be assigned to
multiple people.

Roles are described in the context of processes and activities. Each role is characterized with a
competency profile based on the model shown in Table 4.1.

Table 4.1 Competency codes and profiles

Competency Competency profile (activities and skills)
code
L Leader Decision-making, delegating, overseeing other activities, providing incentives and
motivation, and evaluating outcomes

А Administrator Assigning and prioritizing tasks, record-keeping, ongoing reporting, and initiating
basic improvements

C Coordinator/communicator Coordinating multiple parties, maintaining communication between

stakeholders, and running awareness campaigns

М Methods and techniques expert Designing and implementing work techniques, documenting
procedures, consulting on processes, work analysis, and continual improvement

Т Technical expert Providing technical (IT) expertise and conducting expertise-based assignments

Two practice-specific roles may be found in organizations: deployment manager and deployment
practitioner. These roles are often introduced in organizations where the number of deployments
is high. In other organizations, these roles might be combined with, or assigned to, other roles
carrying related responsibilities in development, operations, IT asset teams, and so on.

4.1.1 Deployment manager role

A deployment manager role calls for a strong knowledge of the organization’s business, products
and services, technology, platforms, frameworks, and processes. The role requires strong planning
and project management skills and the ability and authority to coordinate teamwork. The
competency profile for this role is LACM. This role is usually responsible for the planning,
management, and coordination of deployment management as a practice as well as the
deployment of individual releases, including:

● planning deployments

AXELOS Copyright
View Only – Not for Redistribution
© 2020
17
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
● ensuring the alignment of deployment plans with change/release plans, requirements, and
objectives
● planning, coordinating, and ensuring the availability of the resources needed for the effective
completion of deployments
● effectively managing overlaps or conflicts among multiple deployments
● implementing and maintaining effective control and governance to ensure the integrity of
components throughout the deployment practice
● managing and/or ensuring effective interfaces between and coordination with other practices
and stakeholders
● managing and optimizing deployment resources to ensure optimum levels of availability,
capability, and capacity to manage deployments
● monitoring, reporting, analysing, and improving deployment performance against defined KPIs.
In more complex organizations, some of the deployment management responsibilities may be
delegated to the role of deployment coordinators, team leaders, or any other similar additional
roles.

4.1.2 Deployment practitioner role

A deployment practitioner role calls for strong technical skills and effective teamwork. The
competency profile for this role is TAC. This role is usually responsible for effective deployments
to the target environments in alignment with applicable requirements, objectives, and targets,
including:

● acquiring, maintaining, and continually improving the skills and capabilities required for
technical aspects of deployments
● contributing and assisting in deployment planning
● ensuring the integrity of components throughout the deployment practice
● managing and coordinating deployment documentation, records, and communications, including
for training purposes
● coordinating with other practices and stakeholders and facilitating interfaces between groups
● verifying and providing feedback on deployments to stakeholders
● contributing to monitoring, reporting, analysing, and improving deployment performance against
defined KPIs.

In some organizational contexts, the deployment practitioner role can be divided into multiple
categories and levels based on the types and requirements of the deployments and platforms, the
complexity of organization’s products and services, and so on.

4.1.3 Roles involved in the deployment management activities

Examples of other roles which can be involved in the deployment management activities are
listed in Table 4.1, together with the associated competency profiles and specific skills.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
18
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Table 4.2 Examples of roles with responsibility for deployment management activities

Activity Responsible Competency Specific skills

roles profile

Deployment process

Deployment Service ACMT Understanding the deployment’s impact on the

planning owner service levels, user experiences, and environments

Product Good communication and cross-team coordination

owner skills

Good knowledge of deployment models

Development
team Understanding of technical service design,
member supporting infrastructure and platforms,
development tools

Technical
specialist

Service desk
agent

Engagement
manager

Delivery
manager
Users

Verification of Technical T Good knowledge of services and components

the service specialist
components Deployment
manager

Development
team
member

Service
owner

Product
owner

AXELOS Copyright
View Only – Not for Redistribution
© 2020
19
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020

Verification of Technical TC Good knowledge of environments and infrastructure

the target specialist
environments Deployment
manager

Development
team
member

Systems
administrator

Infrastructure
team
member

Service
owner

Product
owner

Deployment Technical TM Understanding of technical service design, supporting

execution specialist infrastructure and platforms, development tools
Deployment
manager

Good knowledge of deployment models

Development
team
member

Systems
administrator

Infrastructure
team
member

Deployment Technical TC Understanding of technical design of services and

verification specialist components
Deployment
manager

AXELOS Copyright
View Only – Not for Redistribution
© 2020
20
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Good knowledge of service performance, service
Development
levels, and user experience
team
member

Systems
administrator

Infrastructure
team
member
Service
owner

Product
owner

User

Deployment models development and review process

Deployment Deployment CAT Understanding of the service design, resource

model planning manager configuration, and business impact

Service Good knowledge of existing deployment activities

owner

Product
owner

Deployment Deployment TCL Knowledge of deployment pipeline tools

model manager
Knowledge of the continual improvement and change
implementation
Service enablement practices
owner

Product
owner
Good knowledge of testing practices across
Deployment Deployment TCL
model testing manager the workflows

Good knowledge of requirements and

Service
owner commitments, service levels

Product Knowledge of deployment models and methods;

owner analytical skills

AXELOS Copyright
View Only – Not for Redistribution
© 2020
21
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Deployment Deployment TCL Understanding of the service design, resource
review and manager configuration, and business impacts
deployment Good knowledge of deployment models
Service
records analysis
owner Good knowledge of requirements and
commitments, service levels
Product
owner Knowledge of deployment models and
Supplier methods; analytical skills

Deployment Deployment TMC Understanding of the service design, resource

model manager configuration, business impacts, and service levels
improvement Good knowledge of deployment models,
Service
initiation diagnostic tools, and methods
owner

Product Knowledge of the continual improvement and change

owner enablement practices

Deployment Deployment CA Knowledge of communication procedures and tools

model update manager
and
Service
communication
owner

Product
owner

Service desk
agent

4.2 ORGANIZATIONAL STRUCTURES AND TEAMS

Designated deployment management teams are unusual, except in very large organizations with
significant volumes and complexity of deployment. This role is often handled by the
technical/operations teams.

In a DevOps environment, deployment is often automated through the continual deployment

practice/framework with use of deployment pipelines. However, the role of deployment manager
is often still relevant; the deployment manager would own the overall practice and aspects around
deployment. This role could be independently established or combined with other relevant and
suitable roles, such as release manager.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
22
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Information and technology
5.1 INFORMATION EXCHANGE
The effectiveness of the deployment management practice is dependent on the quality of the
information used. This information includes, but is not limited to, information about:

● authorized repositories of service components and assets, such as IT asset databases and DML
● assets and configurations
● change and release plans
● deployment communications
● deployment documentation and records
● deployment plans
● deployment metrics and reports
● entry, exit, and acceptance criteria for each stage of deployment
● feedback from deployment
● issues and errors identified during deployment
● platforms and environments within deployment’s scope
● products and services and their architecture and design
● requirements and expectations about changes and releases
● stakeholder needs, expectations, and contact details.

This information may take various forms. The key inputs and outputs of the practice are listed in
Section 3.

5.2 AUTOMATION AND TOOLING

In most cases, the deployment management practice can significantly benefit from automation.
Deployments in Agile and DevOps environments are predominantly automation- and technology-
oriented.

Where automation is possible and effective for deployment, it may involve the solutions outlined
in Table 5.1.

Table 5.1 Automation solutions for deployment-management activities

Process activity Means of automation Key functionality Impact on the

effectiveness of
the practice

In traditional, non-CI-CD environments

Planning the Planning tools Activity planning, Improved

deployment visibility,
scheduling, and
control, and
tracking
governance over
deployments

AXELOS Copyright
View Only – Not for Redistribution
© 2020
23
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Verification of the service Service component/release Ability to compare the Improvement in
components verification using components on various accuracy and efficiency
tools/technology parameters of verification leading
to improved success
Verification of the target Platform verification using Ability to check the target rate, reduced reworks,
environment tools/technology platform(s) against set of quality and overall
parameters and attributes efficiency of
deployments

Deployment execution Deployment/retirement Ability to deploy the Improvement in overall

using tools/technology designated service effectiveness,
components/releases to efficiency, and
target environment(s) in a consistency of
scheduled and controlled deployments
manner

Deployment verification Verification of deployments Ability to verify the Improved verification

using tools/technology deployment and deployed of deployments
service components against
defined acceptance criteria

In CI/CD environments

Automated deployments to Integrated CI/CD tool chainsSchedule/trigger-based, Effective integration of

dev, test, test, staging, and automated deployment of the release/transition
production the required components to stages for seamless
target environments at build, integration,
each stage. testing, and
deployment.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
24
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Partners and suppliers
6.1 SOURCING CONSIDERATIONS FOR DEPLOYMENT PRACTICE
Very few services are delivered using only an organization’s own resources. Most, if not all, depend
on other services, often provided by third parties outside the organization (see section 2.4 of ITIL
Foundation: ITIL 4 Edition for a model of a service relationship). Relationships and dependencies
introduced by supporting services are described in the ITIL practices for service design,
architecture management, and supplier management.

It is important to understand how the organization depends on third-party components and how it
aims to establish effective and efficient collaboration with its key suppliers and partners around
many activities, including those of the deployment management practice.

In an environment with multiple suppliers, it is important to understand the scope and boundaries
of each organization’s deployment activities, and how these will interact. Most organizations have a
process for deployment, which is often supported by standard tools and detailed procedures to ensure
that software is deployed consistently. It is common to have different processes for different
environments.

Many areas of the deployment management practice might be enabled by effective sourcing, which
could be in terms of people, capabilities, tools, processes, and services.

Deployment management and its PSFs can be enabled and enhanced through selective and judicial
sourcing in many forms, including those outlined in Table 6.1.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
25
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Table 6.1 Sourcing in the deployment management practice

Sourcing area Details

People Where deployment management activities are manual, resources

could be sourced from a partner. Key considerations include the
schedule of deployments, availability of internal resources, cost,
and so on.

Technical/Non- Sourcing specific skills, including technical (about specific systems,

technical skills technologies, platforms) and non-technical (planning, governing, and
and capabilities execution capabilities), are useful or even required in many
deployment management activities. Key considerations include the
variety and complexity of technical/service environments, dynamic
technology environments, lack of
appropriate internal resources, and so on.
Outsourced In certain contexts, it may be necessary or useful to source the
deployment
entire deployment management practice from a partner.
management

Tools and Several areas of the deployment management practice can be

technologies enhanced through the adoption of tools and technologies. Except in
for minor cases, these technologies, tools, and tool-chains are sourced
deployment from specific product/service
providers.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
26
 AXELOS Copyright Deployment management
View Only – Not for
Redistribution
© 2020
Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an
organization might consider when establishing and nurturing their own practices. The practice
guides are catalogues of topics that organizations might think about, not a list of answers. When
using the content of the practice guides, organizations should always follow the ITIL guiding
principles:

● focus on value
● start where you are
● progress iteratively with feedback
● collaborate and promote visibility
● think and work holistically
● keep it simple and practical
● optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of ITIL
Foundation: ITIL 4 Edition.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
27
ITIL®4 Practice Guide AXELOS Copyright
View Only – Not for
Redistribution
© 2020
Acknowledgments
AXELOS Ltd is grateful to everyone who has contributed to the development of this guidance.
These practice guides incorporate an unprecedented level of enthusiasm and feedback from across
the ITIL community. In particular, AXELOS would like to thank the following:

8.1 AUTHORS
Vinod Kumar Agrasala, Roman Jouravlev, Konstantin Naryzhny.

8.2 REVIEWERS
Jon Hall, Anton Lykov, Samantha Robertson, Oleg Skrynnik.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
28
Infrastructure and platform
management
ITIL® 4 Practice Guide
AXELOS.com

28th
February
2020

AXELOS Copyright View Only – Not for Redistribution © 2020

2 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Contents
1 About this document 3
2 General information 4
3 Value streams and processes 14
4 Organizations and people 21
5 Information and technology 26
6 Partners and suppliers 29
7 Important reminder 31
8 Acknowledgments 32

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 3
for Redistribution © 2020 management

1 About this document

This document provides practical guidance for the infrastructure and platform management
practice. It is split into five main sections, covering:
● general information about the practice
● the practice’s processes and activities and their roles in the service value chain
● the organizations and people involved in the practice
● the information and technology supporting the practice
● considerations for partners and suppliers for the practice.

1.1 ITIL® 4 QUALIFICATION SCHEME

Selected content from this document is examinable as a part of the following syllabus:
● ITIL Specialist High-velocity IT
Please refer to the respective syllabus document for details.

AXELOS Copyright View Only – Not for Redistribution © 2020

4 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

2 General information
2.1 PURPOSE AND DESCRIPTION

Key message

The purpose of the infrastructure and platform management practice is to oversee the
infrastructure and platforms used by an organization. When carried out properly, this practice
enables the monitoring of technology solutions available to the organization, including the
technology and external service providers.

The infrastructure and platform management practice ensures that the organization has a high-
quality IT infrastructure that efficiently meets its current and anticipated needs. ‘IT
infrastructure’ as a concept includes all of the hardware, software, networks, and facilities that
are required to develop, test, deliver, monitor, manage, and support IT services.

Depending on the architecture of the organization’s IT infrastructure, this practice may focus on
the management of the physical environment, physical equipment, or digital infrastructure
solutions, which may be the organization’s own resources or services provided by suppliers and
partners. Often, IT infrastructure solutions are managed as services; in these cases, the
infrastructure and platform management practice may include dedicated teams acting as service
providers for the application and/or product teams within the organization. If this approach is
taken, it is important to ensure that the infrastructure and platform teams are closely involved in
the overall service delivery activities of the organization and follow the ITIL principles focus on
value, think and work holistically, and collaborate and promote visibility. Members of these teams
should understand the wider context of the organization and its service value system (SVS).

This practice covers all stages of the infrastructure solutions lifecycle, from ideation and gathering
requirements to delivery and support. At every stage, it is used in conjunction with other practices
(including the business analysis, architecture management, service design, availability
management, capacity and performance management, service continuity management,
information security management, risk management practices, and others). The importance of
high-quality infrastructure and platforms for service delivery cannot be overstated; this practice is
vital for the success of the organization’s digital services and digitized business processes.

2.2 TERMS AND CONCEPTS

The infrastructure and platform management practice provides the structure to deliver and
support stable and well-performing technology services. Infrastructure and platform management
is provided directly to the business, or supports the applications used by the business. With a
robust infrastructure and platform management practice, an organization can enable value
creation with the confidence that the underlying technology will meet organization’s and service
consumers’ needs.

Definition: IT infrastructure

All of the hardware, software, networks, and facilities that are required to develop, test, deliver,
monitor, manage, and support IT services.

A wide range of activities are used to run and manage IT infrastructure effectively. These
activities range from understanding organization’s requirements and developing and planning
infrastructure and platforms, to performing routine maintenance and overseeing infrastructure
performance.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 5
for Redistribution © 2020 management

Definition: Operation

The routine of running and managing an activity, product, service, or other configuration item.

A large portion of the operational activities can be automated. Automation tools can monitor the
environment, identify changes, distribute patches and other updates, provide asset inventory, and
schedule and automate jobs.

2.2.1 Business alignment for infrastructure and platform solutions

Infrastructure and platform solutions are designed to meet specific quality criteria defined to
support the organization’s needs. The infrastructure and platform management practice is closely
connected with the architecture management practice, ensuring that all infrastructure and
platform solutions comply with the chosen architectural approach, model and standards, as well as
sharing knowledge on the innovation available and feeding possible infrastructure and platform
solutions into architecture management. The infrastructure and platform management practice
must support application architecture, data architecture, and business architecture as well as
align to the organization’s overall vision and principles.

To ensure alignment to the overall architectural model, standardized infrastructure and platform
solutions are defined to meet the organization’s needs in a repeatable manner, to simplify delivery
and ongoing management for these services. Standardized services allow for efficient provisioning
through repeatability and automation. Many infrastructure services are designed to enable speed
and agility. Self-service capabilities leverage automation capabilities to allow for users or other IT
staff to request and receive items without manual steps behind the scenes. This should account for
the majority of the services that are in utilized in the environment. Examples of standardized
solutions may include storage systems, application servers, database platforms, authentication
systems, single-sign-on, and others.

In integration with the architecture management the practice, the infrastructure and platform
management practice should ensure development or outsourcing and cost-efficient operation of
flexible and compatible core infrastructure and platform solutions, that should be easily
deployable and easily configured or merged to support the organization’s services or products,
serving as building blocks for the complex solutions, products, and services. One of the examples
of implementing such approach is usage of microservices, that are “small in size, messaging-
enabled, bounded by contexts, autonomously developed, independently deployable, decentralized
and built and released with automated processes”. 1

When the standard solution does not align with the business, a tailored or customized solution
must be developed. The selection of a non-standard service delays the delivery of the solution and
increases the ongoing effort and cost to the business for support for the solution. These non-
standard solutions should be deployed and managed as an exception due to the additional
overhead it requires.

In cases where the technology is not currently in place, the solution must be designed together
with the architecture management and service design practices for conceptual and detailed
design. During design, the infrastructure and platform management practice, business, and
technical requirements are aligned and the recommended infrastructure and platform solutions
are determined. As the solution is not currently available within the environment, additional steps
are taken to address the procurement, build, sourcing, and support of the solution. The solution
should be evaluated by infrastructure and enterprise architecture to determine if this should be
offered to additional consumers or to remain as an exception to the existing documented
standards.

1
Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and
Culture, O’Reilly 2016

AXELOS Copyright View Only – Not for Redistribution © 2020

6 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

When an organization needs an infrastructure and platform solution, infrastructure and platform
management practice ensures that a solution is designed and delivered to meet the organization’s
requirements. There are several ways to provide a solution. For requests that can be fulfilled using
documented standard packages, the solution is provided through defined provisioning methods.

2.2.2 Infrastructure and platform solution technologies – physical and

virtual
The technology used for infrastructure and platform solutions is either physical or virtual. Physical
resources run directly from the hardware, such as an operating system that is installed directly on
the hardware. This operating system can either host the application or services directly or virtual
systems can run on top of it.

Virtualization allows for additional systems to be built on the physical system. Virtualization
software runs on the hardware and allows for additional operating systems that are isolated and
separated to be installed, creating multiple servers residing on the physical server. All virtual
systems may run on the same or different hardware, but the virtual capabilities allow for dynamic
workload placement and other capabilities; it also allows for better utilization of the hardware.
The logical structure that connects the virtual servers and the physical servers should be
accounted for in the configuration management database (CMDB). Additional capabilities that
allow for dynamic moving of workloads should also be represented in the data model.

Infrastructure technologies, such as software-defined networking, virtual servers, and object

storage, simplify the provisioning of infrastructure services. This allows the organization to deliver
services quickly through automation.

Virtualization has greatly improved provisioning, performance, capacity, and availability for
solutions. Further development in the virtualization direction is the usage of infrastructure-as-code
(IaC) solutions. IaC is a way of managing and provisioning IT infrastructure and platforms by using
machine-readable definition files rather than physically configuring hardware components. IaC
solutions significantly speed up design (including hypothesis testing), development, building,
provisioning and changing the infrastructure and platform solutions. Such solutions also usually
make the infrastructure more reliable and fault resistant.

2.2.3 Infrastructure and platform solution delivery models

Advancements in technical capabilities have changed how services are delivered. Service providers
have embraced the ability to scale services. As organizations move to services offerings that allow
for flexibility in terms of how the service is provided, the organization can choose the model that
best aligns to their strategic goals. Many times, the preferred model is a combination of both
internal and external provided services. This complexity drives the need for a comprehensive
management approach that ensures end-to-end delivery meets customer expectations.

There are many models for providing infrastructure and platform solutions, ranging from in-house
dedicated data centres to fully out-sourced cloud environments. Many organizations continue to
provide and support infrastructure residing in their internal data centres. They can also use
solutions external to their organization. Cloud solutions provide offerings that allow systems and
applications to run in internal and external data centres. Most enterprises use public cloud
providers for at least part of their infrastructure. Cloud providers offer many solutions based on
the expected needs of the business. An application may be accessed through the cloud, leaving
infrastructure management activities beyond connecting to the cloud to be done externally by the
application provider. Cloud offerings can include platforms for application development and
infrastructure specific services like storage or backup as a service.

There is usually a mix of public and private cloud services in any organization. Both cloud services
and outsourcing can provide infrastructure and platform services. Cloud services provide technical
capabilities whereas outsourcing performs IT functions in a similar manner to internal teams. The
contract defines the outsourcing scope and service levels. Instead of managing technology
directly, internal IT teams focus on managing the contractual obligations and interactions with
internal teams in an outsourced environment.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 7
for Redistribution © 2020 management

2.2.4 Agile methods in infrastructure and platform management

Recent technology innovations have enabled changes to how infrastructure is delivered and
supported. Development practices have been adopted by teams providing infrastructure and
platform solutions. Engineering and support functions rely heavily on coding and other
development capabilities for automation.

Along with a focus on development from a system perspective, many organizations have also
moved into models that blend development and infrastructure capabilities on one team to provide
coverage throughout the lifecycle. DevOps and site reliability engineering (SRE) are examples of
these models.

Specifically, DevOps brings a robust landscape of tools to automate the tracking, building, and
deploying of small, agile-based releases. Agile is a development framework, but DevOps includes
the infrastructure components and operational activities. DevOps focuses on the opportunities
across all technology components and drives automation to enable rapid system updates.
Infrastructure can now fully benefit from structured development practices.

By accounting for the end-to-end development and management of the solution, this approach
allows for operational improvements to be included in the development releases. Machine
learning and AIOps leverages data collected on solutions to automate, address issues, or manage
requests without development. Through operational visibility and development capabilities, the
overall system is managed in a more comprehensive and consistent manner through automation.

When using DevOps for infrastructure and platform management, special attention must be paid to
obsolete systems and monolithic solutions that require manual operation and, therefore, slow
down all management processes and changes. There should be a clear roadmap of
decommissioning and replacing such solutions or replacing the manual activities with automation.
One of the ways to do this is have an SRE team to run operations.

SRE is a discipline that incorporates aspects of software engineering and applies them to
infrastructure and operations problems with the goal of creating ultra-scalable and highly reliable
solutions. SRE is an approach that tries to bridge the gap between development and operations and
find a consensus of their opposite objectives, which is to develop and release solutions fast and
have a stable solution to support. SRE teams usually have software developers who must support
the solutions they develop, and this stimulates them to automate most of the manual support and
management tasks (in the course of reducing toil: manual, repetitive, automatable, non-creative
work). With this, infrastructure and platform solutions become more manageable, require less
manual work, and gain agility in changes, delivery, and support. Probably one of the most
important gains of SRE operations is that infrastructure scale-out doesn’t lead to according linear
growth of the team size, as it often happens in classical operations.

AXELOS Copyright View Only – Not for Redistribution © 2020

8 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Key message

The practice is involved throughout the lifecycle of product and services. Figure 2.1 from “The Site
Reliability Workbook” by Google, illustrates how SRE teams are involved during the lifecycle. With
minor variations, this illustration is applicable to other approaches to infrastructure and platform
management.

Figure 2.1 Infrastructure and platform management during product and service lifecycle

2.2.5 Reliability and maintainability

Once the solution is in production, the primary focus of the team supporting and operating the
infrastructure is to ensure high-quality delivery through managing the ongoing performance and
functionality of the infrastructure and platform solutions. This team may be a dedicated
infrastructure team or a dedicated product team. The products and services rely on the solution’s
availability and performance to support them. In production, the organization has high
expectations for uptime and very little tolerance for any impact of any type on service or product.
To meet these demands, the solutions must be reliable and maintainable. Beyond infrastructure
and platform configurations to support reliability and maintainability, the infrastructure and
platform management practice must ensure the solution is supportable. Supportability addresses
the organization’s requirements to ensure that the solution is functional and ready to support
products and services.

Reliability is designed with the system. Reliability requirements are aligned to the uptime and
performance requirements, defined by the capacity and performance management practice.
These requirements ensure the solutions are built in to support the organization’s requirements.
For example, this may include high availability or redundant network connectivity.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 9
for Redistribution © 2020 management

Definition: Reliability

The ability of a product, service, or other configuration item to perform its intended function for a
specified period of time or number of cycles.

Maintainability of a system should be addressed during the design of a new system and tested
before being transitioned to production. There could be rules agreed for an infrastructure and
platform solution, ensuring maintainability based on the organization’s requirements and industry
practices. One example is the existence of a monitoring tool to identify issues, or general
monitorability of the solution planned at the design phase. Other examples could be the existence
of tools used to configure, deploy, and provision the solutions. These rules could also be used to
manage partners and suppliers responsible for infrastructure and platform service components.

Definition: Maintainability

The ease with which a service or other entity can be repaired or modified.

If maintainability is not addressed during the initial design and as part of daily operations, higher
support costs, extended outages, and negative impacts to performance will affect the production
environment. Maintainability is improved through appropriate monitoring configurations,
automation, and utilization of standards.

Another aspect of maintainability involves ensuring the solution is recoverable to meet availability
targets. This aspect is tightly aligned with the service continuity management. Maintainability
ensures that infrastructure and platform solutions can be recovered to meet availability targets.
This may mean, for example, ensuring that the hardware contract supports on-site replacements
within a set timeframe. It may also cover having on-site resources performing the repair. When
committing to availability targets, the parts and resources needed to restore service need to be
factored in and be in place throughout the solution lifecycle. The infrastructure and platform
management practice requires that the right pieces are in place to diagnose, repair, and recover in
order to restore services on time.

Automation is also used to improve a system’s maintainability. Repeatable actions are excellent
candidates for automation. Software development and management tools and techniques, such as
Agile and DevOps, can be applied to infrastructure and platform management to drive frequent
updates to systems and configurations. By addressing opportunities as they are identified and
implementing solutions in small releases, benefits are realized quickly.

2.3 SCOPE
The scope of the infrastructure and platform practice includes:
● activities used to plan, design, develop, deliver, maintain, and support infrastructure and
platform technology
● infrastructure and platform technology including:
● hardware (servers, desktops, routers, switches, storage, cabling, and data centre)
● software (operating systems, desktop applications, and middleware)
● management tools (monitoring, management tools, deployment, inventory)
● web hosting
● cloud infrastructure and platform
● identification systems and single sign-on (SSO).
● infrastructure and platform management skills, including:
● technical architecture and engineering

AXELOS Copyright View Only – Not for Redistribution © 2020

10 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

● technical administration and operations

● execution and enforcement of policies and procedures connected to infrastructure and
platform management (planning, decision making, oversight).
● integration with other practices
● skills required for infrastructure and platform management, including infrastructure
architecture, engineering, and administration.

There are many activities and areas of responsibility that are not included in the infrastructure
and platform management practice, although they are still closely related to infrastructure and
platform management. These are listed in Table 2.1, along with references to the practices in
which they can be found. It is important to remember that ITIL practices combine value chain
activities through value streams to deliver value.

Table 2.1 Activities related to the infrastructure and platform management practice described in
other practice guides

Activity Practice guide

Restoration of infrastructure and platform technology and Incident management
services including major incidents
Defining permanent resolution or workarounds for Problem management
infrastructure and platform known errors
Management of changes to the infrastructure and Change enablement
platforms
Tracking and management of infrastructure and platform IT asset management
assets
Tracking of infrastructure and platform configurations in Service configuration management
relationship to other configuration items (CIs)
Monitoring, event management, and log management for Monitoring and event management
infrastructure and platform technologies
Infrastructure and platform design Service design
Defining requirements for infrastructure and platform Business analysis
solutions
Definition of standards and road map for infrastructure Architecture management
and platforms

2.4 PRACTICE SUCCESS FACTORS

Definition: Practice success factor

A complex functional component of a practice that is required for the practice to fulfil its purpose.

A practice success factor (PSF) is more than a task or activity; it includes components from all four
dimensions of service management. The nature of the activities and resources of PSFs within a
practice may differ, but together they ensure that the practice is effective.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 11
for Redistribution © 2020 management

The infrastructure and platform practice includes the following PSFs:

● establishing an infrastructure and platform management approach to meet evolving
organizational needs
● ensuring that the infrastructure and platform solutions meet the organization’s current and
anticipated needs.

2.4.1 Establishing an infrastructure and platform management approach

to meet evolving organizational needs
The needs of organizations and their customers are continually changing which leads to the
technology industry continually transforming. The changes may result from industry trends,
changes within organizations, business process innovation, or changes to business volumes. The
infrastructure and platform management practice ensures that infrastructure and platform
solutions are flexible and scalable so that they are aligned with demand. Organizational
infrastructure and platforms meet this demand through optimized solutions that are designed for
and used by all parts of the organization.

To properly design these solutions, teams delivering infrastructure and platform change must be
aware of new technologies and techniques. The evolution of technology can be seen in examples
like email, virtual server farms, storage arrays, single sign-on, and cloud platforms. When solutions
are identified based on requirements, requests are promptly fulfilled. With virtual server
technology that is used both internally and for cloud offerings, the turnaround time for requests
can be reduced to minutes. Technological progress, such as virtualization, containers, continuous
integration/continuous delivery (CI/CD), and IaC, significantly impacts the rate of change and
innovation.

Organizations that deliver and support infrastructure and platform solutions have evolved through
models, such as DevOps and SRE; they eliminate the use of traditional waterfall techniques in
favour of end-to-end development and management within one team. Crucially, the organization’s
structure and technology components must align with its overall strategic direction in order to
ensure the consistent delivery and support of infrastructure and platform solutions. Components
must align with the overall strategic direction to ensure consistent delivery and support of
infrastructure and platform solutions.

It is important to plan how infrastructure and platform teams will identify, design, and introduce
innovation into the environment at the solution and strategic levels. Depending on the current
needs, infrastructure and platform management might need initial research and testing so that,
when the need is presented, there is a clear plan of action. If the need is pressing, the technology
may be selected, purchased, designed, and configured before any official requests are received.

The infrastructure and platform management practice should ensure that the infrastructure and
platforms are built to promote experimentation, quick technology adoption, the ability to test
theories and hypotheses, change the infrastructure and platform iteratively with feedback, fail
fast, and learn from experience and errors in a safe environment. Each organization should define
its innovation and risk appetite and consider their financial constraints for innovation in the
infrastructure and platforms areas.

2.4.2 Ensuring that the infrastructure and platform solutions meet the
organization’s current and anticipated needs
The main focus of the infrastructure and platform management practice should be ensuring that
stakeholders receive value throughout the infrastructure and platform solution lifecycle.
Stakeholders must be engaged from the initiation of a request or project until the solution’s
retirement. Understanding stakeholder expectations, from design to the ongoing management and
support of the solutions, is an essential aspect of delivering infrastructure and platform solutions.
This ongoing relationship will drive improvement opportunities and ensure value continues to be
co-created as the solution evolves.

When the organization needs a technical solution, requirements are defined in order to ensure that
the solution meets the organization’s needs. The solution design should include technical and

AXELOS Copyright View Only – Not for Redistribution © 2020

12 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

business requirements. The infrastructure and platform management practice is involved in

analysing requirements to create a high-level design (in conjunction with the architecture
management, business analysis, and service design practices, and others).
The requirements for infrastructure and platform solutions may come from different sources,
including:
● architectural standards and guidelines
● compliance requirements, if the organization is subject to legislation
● direct requirements from customers, if a solution is a service or service component that will be
directly released to customers.

Where possible, the infrastructure and platform management practice ensures that standards can
be defined and utilized in order to simplify the management of infrastructure and platform
solutions. The enforcement of these standards ensures the reliability and maintainability of
solutions. Standards enable efficient and effective operations and may include the hardware and
software versions, configuration settings, management and monitoring tools, and support
structures. Through standards, solutions are easier to operate, monitor, and upgrade.

Designs should be assessed against current and planned standards and validated against the current
and anticipated levels of availability, performance, capacity, information security, and so on.
Management practices supporting these should have active involvement.

Standard infrastructure solution packages should be utilized wherever possible. Any portion of the
solution that is not standard increases cost, delays delivery, and requires customized support
throughout the life of the solution. Exceptions to standards may result in extended downtime or
other impacts to the customer. They may also delay teams responsible for performing other
activities for other infrastructure and platform solutions.

If there are multiple exceptions to a standard, a review should be conducted to ensure that the
standard still meets the organization’s needs. If it does not, a new standard should be designed
and its implementation should be planned. Retiring the standard may include planning the removal
of current systems that were installed as part the retired offering in order to reduce technical
debt and the potential risk to the environment. The development and maintenance of the
standards and standard packages are also within the scope of the infrastructure and platform
management practice.

Part of the practice’s focus is to manage risk to the organization throughout the infrastructure and
platform. As part of this effort, input from practices such as information security, service
continuity, and risk management are taken to ensure that risks are managed throughout the
lifecycle of the solution. This ongoing management includes, for example, ensuring that network
devices are configured based on defined security policies, controls are tested periodically, and
risks are identified and effectively managed. Requirements are handled on an ongoing basis to
prevent adverse impacts, such as extended service downtime or a security breach of confidential
information.

The overall management of infrastructure and platform solutions often includes internal and third-
party solutions and components. Understanding the overall structure of these solutions and
ensuring that the overall level of service provided meets customer expectations is critical.
Management need visibility to validate that solutions are performing at acceptable levels and to
highlight opportunities. These may include addressing any issues and identifying areas that could
be improved. The infrastructure and platform management practice should provide visibility to
stakeholders in performance and improvement plans. This practice interacts with other practices
to ensure that any issues or requests on solutions are resolved promptly. For this reason, the
practice participates in agreeing targets for incident response, restoration, and request fulfilment
times to align with customer expectations. This practice may include managing and reporting on
the ability of solutions to meet targets. This visibility also provides an opportunity to improve
performance in this area through automation or process refinement.

This practice also contributes to ensure that the agreed-upon levels of service is met. The scope of
this effort includes any internal or external components used in the solution. Third-party services

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 13
for Redistribution © 2020 management

must align with customer expectations, or the expectations must be reset. External providers must
meet the service levels in their contracts. By managing performance levels across internal and
external services, the practice is able to report performance and other outcomes to the business.

The infrastructure and platform management practice ensures that solutions within its scope
effectively contribute to overall financial targets. Infrastructure and platform solutions should be
benchmarked against cloud offerings and external provider solutions. From a technology
perspective, automation, consolidation, and standardization simplify the infrastructure and
platforms and release resources, which can then be used to drive value. The current and potential
partnerships with external providers can also be evaluated and existing agreements optimized.

2.5 KEY METRICS

The effectiveness and performance of the ITIL practices should be assessed within the context of
the value streams to which each practice contributes. As with the performance of any tool, the
practice’s performance can only be assessed within the context of its application. However, tools
can differ greatly in design and quality, and these differences define a tool’s potential or
capability to be effective when used according to its purpose. Further guidance on metrics, key
performance indicators (KPIs), and other techniques that can help with this can be found in the
measurement and reporting practice guide.

Key metrics for infrastructure and platform management are mapped to its PSFs. They can be used
as KPIs in the context of value streams to assess the contribution of the practice to the
effectiveness and efficiency of those value streams. Some examples of key metrics are given in
Table 2.3.

Table 2.3 Examples of key metrics for the practice success factors

Practice success factors Key metrics

Establishing an infrastructure and ● Stakeholder satisfaction with the approach to management of

platform management approach infrastructure and platforms
to meet evolving organizational ● Alignment of the infrastructure and platform management
needs approach with the organization’s strategy and architecture
● Number and impact of deviations from the organization’s
strategy and architecture road map
● Level of benefits, costs, and risks associated with the
approach to management of infrastructure and platforms

Ensuring that the infrastructure ● Stakeholder satisfaction with infrastructure and platform
and platform solutions meet the solutions
organization’s current and ● Number and impact of infrastructure incidents
anticipated needs ● Number and impact of constraints imposed by infrastructure
and platform solutions
● Number and impact of deviations from the agreed approach

The correct aggregation of metrics into complex indicators will make them easier to use for the
ongoing management of value streams and for the periodic assessment and continual improvement
of the infrastructure and platform management practice. There is no single best solution. Metrics
will be based on the overall service strategy and priorities of an organization, as well as on the
goals of the value streams to which the practice contributes.

AXELOS Copyright View Only – Not for Redistribution © 2020

14 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

3 Value streams and processes

3.1 VALUE STREAM CONTRIBUTION
Like any other ITIL management practice, the infrastructure and platform management practice
contributes to multiple value streams. Remember, no value stream is made up of a single practice.
The infrastructure and platform management practice combines with other practices to provide
high-quality services to consumers. The main value chain activities to which this practice
contributes are:
● deliver and support
● design and transition
● obtain/build
● plan.

The contribution of the infrastructure and platform management practice to the service value
chain is shown in Figure 3.1.

Figure 3.1 Heat map of the contribution of the infrastructure and platform management practice
to value chain activities

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 15
for Redistribution © 2020 management

3.2 PROCESSES
Each practice may include one or more processes and activities that may be necessary to fulfil the
purpose of that practice.

Definition: Process

A set of interrelated or interacting activities that transform inputs into outputs. A process takes
one or more defined inputs and turns them into defined outputs. Processes define the sequence of
actions and their dependencies.

There are numerous models to structure activities of the infrastructure and platform management
practice. These span several decades and range from waterfall and manual, to iterative and
incremental.

This practice is one of the two ITIL practices (the other is the software development and
management practice) where activities do not always form processes that could be described as
sequences at the level of detail appropriate to this guide. This is because the infrastructure and
platform management activities are always performed in a context of one or another value stream,
and always in conjunction with other practices. However, activities of this practice can be
categorized in three groups:
● technology planning
● product development
● technology operations.

3.2.1 Technology planning activities

Technology planning activities ensure that the organization has a technology management
approach and a roadmap for infrastructure development and improvement. These activities ensure
the organization’s financial, architectural, and resource plans are aligned. With formalized and
repeatable planning and effective integration with other practices, infrastructure and platform
solutions will continually support alignment with the strategic goals of the organization. Table 3.1
shows how the activities transforms the inputs into outputs.

Table 3.1 Inputs, activities, and outputs of technology planning

Key inputs Activities Key outputs

● Organization’s principles,
● Analyse the organization’s ● Infrastructure and platform
strategy and architecture management approach and
policies, and vision
● Develop and agree the roadmap
● Organizational strategy
infrastructure and platform ● Improvement initiatives and
● Organizational structure
management approach requests for changes
● Product and service portfolio
● Review the infrastructure and
● Customer portfolio
platform management
● Business analysis records and
approach
review reports
● Audit reports

AXELOS Copyright View Only – Not for Redistribution © 2020

16 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Figure 3.2 shows a workflow diagram of the process.

Figure 3.2 Workflow of technology planning

Table 3.2 provides an example of the technology planning activities.

Table 3.2 Example activities of technology planning

Activity Example
Analyse the IT Leaders of the organization analyse the organization’s strategy,
organization’s strategy architecture road map, and portfolios and define requirements to the
and architecture infrastructure and platform management approach.

Develop and agree the Business analysts, architects, product owners, and infrastructure
infrastructure and experts agree and communicate an infrastructure and platform
platform management approach, including scope, sourcing strategy, methods and techniques,
approach procedures, and responsibilities.

Review the Based on infrastructure review reports, periodic reviews, and audit
infrastructure and reports, product owners and infrastructure experts review the
platform management effectiveness of the infrastructure and platform management approach
approach and provide input to the analyse the organization and requirements
activity, and/or initiate required changes.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 17
for Redistribution © 2020 management

3.2.2 Product development activities

In many organizations these activities are performed within product development value streams in
conjunction with other practices. The infrastructure and platform management practice serves as
a source of technical expertise and other resources to support product ideation, design,
development, and deployment. In other organizations, infrastructure and platform solutions are
developed in a separate value stream and provided to as services to product teams and their
products. The activities of the infrastructure and platform practices are similar in these scenarios.
In many cases, infrastructure solutions are sourced from external developers; the activities of the
practice are focused on ensuring that the solutions meet the organization’s requirements and
constraints.

This group includes the activities outlined in Table 3.3 and transforms the inputs into outputs.

Table 3.3 Inputs, activities, and outputs of product development

Key inputs Activities Key outputs

● Infrastructure and platform ● Create a basic solution design ● Basic and detailed design
management approach
● Create a detailed solution ● Agreed service level
design objectives
● Solution requirements
● Source/develop/configure the ● Components and solutions
● Budget and other resources
and constraints
components ● Solution documentation
● Sourcing and supplier
● Source/build/configure the ● Setup in management tools
solution including monitoring, ITSM
management policies
● Sourcing and build policies
● Support validation and testing tools
and guidance
● Support deployment and ● Operational run books
● Operational standards
release ● Reports and scheduled
● Success criteria
● Review solution development reviews
and implementation
● Project structure (schedule,
assignment, methods)

The focus of technology delivery and engineering is on designing, building, and transitioning
infrastructure and platform services. These activities may vary, depending on how the services
will be delivered and how the organization applies these steps, as is outlined in Table 3.4.

Table 3.4 Technology delivery and engineering activities

Activity Internal build Sourced

Based on the requirements identified by business analysts and
Create a basic solution design
product owner, infrastructure specialists agree service level
objectives for the infrastructure solution and create a basic
solution design. The basic design is approved by the product
owner.
Infrastructure specialists and/or site reliability engineers
Create a detailed solution design
creates a detailed solution design, ensuring its reliability,
efficiency, scalability, and other quality characteristics
required by the agreed SLOs and the organization’s
infrastructure management approach are met.
The resulting design includes a recommended sourcing and
delivery model for the components and the solution.
Agreed components are Agreed components are
Source/develop/configure the
developed and configured by procured and configured by
components
infrastructure specialists a supplier according to the
according to the design design; their work is
monitored and accepted by
infrastructure specialists

AXELOS Copyright View Only – Not for Redistribution © 2020

18 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Agreed solution/system is Agreed solution/system is

Source/build/configure the
built/configured by built/configured by a
solution
infrastructure specialists supplier according to the
according to the design; their design; their work is
work is accepted by the monitored and accepted by
product owner infrastructure specialists
and the product owner
Infrastructure specialists Infrastructure specialists
Support validation and testing
participate in the validation participate in the validation
and testing of the components and testing of the
and the solution at all stages components and the
of the solution development, solution at all stages of the
ensuring effective integration solution development,
with the service validation ensuring effective
and testing practice integration with the service
validation and testing
practice and the supplier
management practice
Infrastructure specialists Infrastructure specialists
Support deployment and release
participate in the deployment participate in the
and release of the solution, deployment and release of
ensuring effective integration the solution, ensuring
with the respective practices effective integration with
the supplier management
practice
Infrastructure specialists, Infrastructure specialists,
Review solution development and
product owners, and product owners, application
implementation
application developers review developers, and supplier
the infrastructure solution representatives review the
development activities and infrastructure solution
outcomes. The resulting development activities and
report is used as an input to outcomes. The resulting
the technology planning report is used as an input to
activities and other the technology planning
improvement initiatives activities, supplier
management
improvements, and other
improvement initiatives

Product development activities ensure the delivery of a supportable solution that meets the
organization’s needs and agreed SLOs. Even if an external provider provides a solution, steps are
taken to ensure it fits into the overall delivery and support model.

3.2.3 Technology operation activities

The technology operations activities are performed after the solution goes into the live
environment. These activities include planned maintenance and unplanned support activities.
Maintenance focuses on the normal operations of the solution, such as administration and
monitoring. Support focuses on addressing events, incidents, alerts, and other areas that are not
performing as planned. In an organization that is not functioning well, the unplanned activities
typically take most, if not all resource time. A more mature organization will focus on planned
activities that will result in less unplanned work.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 19
for Redistribution © 2020 management

This group includes the following activities, and transforms the following inputs into outputs:

Table 3.5 Inputs, activities, and outputs of the technology operation

Key inputs Activities Key outputs

● Manage queues of queries and ● Reports
● Solutions and support
documentation, such as
events ● Closed tickets and events
operational run books
● Perform scheduled tasks ● Scheduled job completion
● Policies and guidelines
● Patch and update the system ● Backup completion
● Monitoring data
● Updated solution and support
documentation
● Queries (incidents, problems,
and so on)
● Automation
● SLAs
● Improvements

Table 3.6 provides example descriptions of the technology operation activities

Table 3.6 Technology operation activities

Activity Example

Manage queues of queries and Infrastructure management teams and tools process incoming
events queries and events, ensuring timely and successful resolution of
detected incidents, alerts, and other events requiring a response.
Logs and reports reflecting this activity are created as agreed in
the infrastructure and platform management approach and
solution documentation.

Examples of this work include:

● rolling back a bad software push
● blocking or rate-limiting unwanted traffic
● bringing up additional serving capacity
● using the monitoring systems (for alerting and dashboards)
● solving incidents
● analysing problems
● conducting post-mortems.

Perform scheduled tasks Several actions are performed by infrastructure management

teams or tools on a scheduled basis, such as daily backups or a
data transfer between systems. Logs and reports reflecting this
activity are created as agreed in the infrastructure and platform
management approach and solution documentation.

Examples of this work include:

● administering production jobs
● describing the architecture, various components, and
dependencies of the services
● testing back-up restoration
● training users
● reviewing supplier performance
● reviewing solution performance.

Patch and update the system Patches and system updates are released to the environment in a
structured manner. Typically, patches deployed to the lower
environments for testing and then deployed to production.

AXELOS Copyright View Only – Not for Redistribution © 2020

20 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Despite this structure, there are exceptions where systems are

not patched as part of this scheduled release due to an
application incompatibility, business usage of the solution, or
issues identified through testing. It is important to track the
solutions that are not at current levels. Completing these updates
should be rolled out promptly to maintain overall supportability.
Up-to-date solutions reduce the risk of downtime or security
breaches.

There are also situations where system updates or patches are

installed to resolve an incident and then need to be rolled out to
the rest of the organization. The result of applying patches and
updates reactively creates a non-standard environment.

The infrastructure specialist manages these exceptions and

identifies a plan to address these exceptions. Understanding and
addressing these deviations is a vital part of technology
management.

The technology operation activities ensure that solutions are available and functioning as designed
from acceptance into the live environment through retirements. Technical experts and technical
coordinators perform the activities in this process.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 21
for Redistribution © 2020 management

4 Organizations and people

4.1 ROLES, COMPETENCIES, AND RESPONSIBILITIES
The practice guides do not describe the roles of practice owners or managers that should exist for
all practices. They focus instead on specialist roles specific to each practice. The structure and
naming of each role may differ from organization to organization, so any roles defined in ITIL
should not be treated as mandatory, or even recommended. Remember, roles are not job titles.
One person can take on multiple roles and one role can be assigned to multiple people.

Roles are described in the context of processes and activities. Each role is characterized with a
competency profile based on the model shown in Table 4.1.

Table 4.1 Competency codes and profiles

Competency code Competency profile (activities and skills)

L Leader Decision-making, delegating, overseeing other activities, providing

incentives and motivation, and evaluating outcomes

A Administrator Assigning and prioritizing tasks, record-keeping, ongoing

reporting, and initiating basic improvements

C Coordinator/communicator Coordinating multiple parties, maintaining

communication between stakeholders, and running awareness campaigns

M Methods and techniques expert Designing and implementing work techniques,

documenting procedures, consulting on processes, work analysis, and continual
improvement

T Technical expert Providing technical (IT) expertise and conducting expertise-

based assignments

AXELOS Copyright View Only – Not for Redistribution © 2020

22 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Table 4.2 Examples of the roles involved in infrastructure and platform management activities

Activity Responsible roles Competency Specific skills

profile

Technology planning

Analyse the organization’s Architects, business TC Good knowledge of the

strategy and architecture analysts, product organization and its
owners, infrastructure environment, portfolios,
specialists products, resources, and
customers

Understanding of the
current infrastructure
architecture and
architecture roadmap

Analytical skills

Good knowledge of current

and available technology

Develop and agree the Architects, business TLMC Good knowledge of the
infrastructure and analysts, product organization and its
platform management owners, infrastructure environment, portfolios,
approach specialists, consultants products, resources, and
customers

Excellent knowledge of
current and available
infrastructure and platform
solutions

Good knowledge of
infrastructure and
technology services
suppliers and market

Review the infrastructure Architects, business TCA Good knowledge of the

and platform management analysts, product organization and its
approach owners, infrastructure environment, portfolios,
specialists, consultants products, resources, and
customers

Understanding of the
current infrastructure
architecture and
architecture roadmap

Analytical skills

Good knowledge of current

and available technology

Product development

Create a basic solution Solution architects, TA Understanding of the

design infrastructure requirements
specialists, site
reliability engineers, Good knowledge of the
product owners infrastructure and platform

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 23
for Redistribution © 2020 management

management approach

Expertise in the available

technology

Create a detailed solution Solution architects, TA Understanding of the

design infrastructure requirements
specialists, site
reliability engineers, Good knowledge of the
product owners infrastructure and platform
management approach

Expertise in the available

technology and services

Source/develop/configure Infrastructure TC Technical expertise

the components specialists, site
reliability engineers, Communication and
product owners, collaboration skills
suppliers

Source/build/configure the Infrastructure TC Technical expertise

solution specialists, site
reliability engineers, Communication and
product owners, collaboration skills
suppliers

Support validation and Infrastructure TC Technical expertise

testing specialists, site
reliability engineers, Communication and
product owners, collaboration skills
suppliers

Support deployment and Infrastructure TC Technical expertise

release specialists, site
reliability engineers, Communication and
product owners, collaboration skills
suppliers

Review solution Solution architects, TCA Good knowledge of the

development and infrastructure infrastructure and platform
implementation specialists, site management approach
reliability engineers,
product owners Technical expertise

Good knowledge of the

organization and its
environment, portfolios,
products, resources, and
customers

Technology operations

Manage queues of queries Infrastructure TA Technical knowledge

and events specialists, site
reliability engineers Understanding of business
and customer context

Communication and
coordination skills

Perform scheduled tasks Infrastructure TA Technical administration

specialists, site knowledge

AXELOS Copyright View Only – Not for Redistribution © 2020

24 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

reliability engineers

Patch and update the Infrastructure TA Knowledge of security

system specialists, site policies, standards, and
reliability engineers requirements

Technical knowledge

4.1.1 Infrastructure specialist

The key role for this practice is infrastructure specialist. This is a generic term to describe roles
that can be specified either by the technology, like network, SRE, and so on (for example, network
specialist, site reliability engineer, or virtualization specialist) or by the phase in product lifecycle,
like design, testing, or operations (for example,. infrastructure designer/development specialist,
testing specialist, or operations administrator).

Those distinctions are defined by the organization’s size and structure, but the general set of
competencies are similar, and usually includes:
● technology subject matter expertise
● good understanding of the organization’s architecture
● knowledge of the frameworks and techniques adopted by the organization
● knowledge of organization’s products and services
● service mindset
● good knowledge of organization’s operating model and value streams.

Examples of other roles which can be involved in infrastructure and platform management
activities are listed in Table 4.2, together with the associated competency profiles and specific
skills.

4.2 ORGANIZATIONAL STRUCTURES AND TEAMS

Infrastructure and platform management specialists often form a dedicated team (or teams).
However, in some organizations they are included in product teams and focused on infrastructure
solutions supporting respective products. Regardless of the organizational solution, it is important
to maintain shared view and responsibility across infrastructure and product teams.

Key message

“Rigid boundaries between “application development” and “production” (sometimes called

programmers and operators) are counterproductive. This is especially true if the segregation of
responsibilities and classification of ops as a cost center leads to power imbalances or
discrepancies in esteem or pay.

(…) Ideally, both product development and SRE teams should have a holistic view of the stack—the
frontend, backend, libraries, storage, kernels, and physical machine—and no team should jealously
own single components. It turns out that you can get a lot more done if you “blur the lines”11 and
have SREs instrument JavaScript, or product developers qualify kernels: knowledge of how to make
changes and the authority to do so are much more widespread, and incentives to jealously guard
any particular function are removed.”

This quote from “The Site Reliability Workbook” by Google refers specifically to SRE teams.
However, it is valid for any other approach to infrastructure and platform management.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 25
for Redistribution © 2020 management

The infrastructure and platform management practice needs to allow for organization variations
while ensuring some level of consistency across infrastructure teams. The teams may be split by
geography, type of technology, or business service. Having an overall structure to manage practice
changes and communication is important to keep the overall service functioning in an optimal
manner. This may be done with an overall governance group or through representation in an
infrastructure committee.

AXELOS Copyright View Only – Not for Redistribution © 2020

26 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

5 Information and technology

5.1 INFORMATION EXCHANGE
The effectiveness of the infrastructure and platform management practice is based on the quality
of the information used. This information includes, but is not limited to:

● business services and processes

● customers and users
● partner and suppliers including contracts and service levels
● SLAs
● architecture and design documentation
● portfolio and project management plans
● policies, requirements, and controls
● change records
● incident records
● request records
● problem records
● release records
● financial information
● application development and testing information
● system information (versions, baselines, configurations)
● monitoring and event information
● IT assets and inventory information.

5.2 AUTOMATION AND TOOLING

In most cases, the infrastructure and platform management practice can significantly benefit from
automation. Where this is possible and effective, it may involve the solutions outlined in Table
5.1.

Table 5.1. Automation solutions for infrastructure platform management activities

Process activity  Means of automation  Key functionality  Impact on the

effectiveness of the
practice 

Technology planning

Analyse the organization’s Communication and Collection, processing, High

strategy and architecture collaboration tools and presentation of data
from diverse sources
Analytical systems

Knowledge
management tools

Develop and agree the Communication and Collaboration and Medium

infrastructure and platform collaboration tools information sharing
management approach

Review the infrastructure Communication and Collection, processing, High

and platform management collaboration tools and presentation of data
approach from diverse sources
Analytical systems
Reporting engines
Knowledge Dashboard systems
management tools

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 27
for Redistribution © 2020 management

Product development
Create a basic solution Workflow tools Ability to assign design High
design including task tasks and approval for
assignment, routing, planning activities,
approvals, tracking, including status tracking,
and notifications notifications, and
reporting to ensure
actions are on task and
the design is approved
Create a detailed solution Workflow tools Ability to assign tasks High
design including task and approval for
assignment, routing, planning activities,
approvals, tracking including status tracking,
and notifications, notifications, and
contract management reporting to ensure
with templates, actions are on task
approvals, and review
schedules
Source/develop/configure Automated Ability to receive High
the components provisioning, building, approved request and to
and configuring tools build a solution with no
or limited manual
intervention ensuring
consistent and timely
delivery
Source/build/configure the Automated Ability to receive High
solution provisioning, building, approved request and to
and configuring tools build a solution with no
or limited manual
intervention ensuring
consistent and timely
delivery
Support validation and Automated testing and Automated testing, High
testing defect tracking reporting, and logging
into the defect
management system
Support deployment and Deployment tools Automated deployment High
release from testing to
implementation,
including submission of
change request
Review solution Workflow tools Dashboards and reports, Medium to high
development and including task trend analysis
implementation assignment, routing,
approvals, tracking,
and notifications
System health
monitoring and
reporting tools
Technology operation
Manage queues of queries Automated request Ability to close repeat High
and events provisioning, tickets automatically and
automated resolution, assign the tickets
ChatOps, AIOps, automatically to the correct
group without manual triage

AXELOS Copyright View Only – Not for Redistribution © 2020

28 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

steps
Workflow tools
Task assignment, routing,
approvals, tracking and
notifications

Perform scheduled tasks Job scheduling tools Automation of scheduled High

and scripts for backup, tasks including notification
batch, and other on failures reducing the
automated tasks potential for missed
procedure execution
Vulnerability tools and
report and testing Ability to automatically
automation for verify and test solutions for
compliance, automated security hardening,
solution recovery, and recoverability, and controls
testing
ITSM report and
dashboard automation
Automated report
consolidation and
generation, customer
feedback surveys
Workflow tools
including task
assignment, routing,
approvals, tracking,
and notifications
Patch and update the System and security Ability to automatically High
system patch deployment and deploy and report on
inventory tools, installation status for
software distribution patches and system updates
and inventory tools

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 29
for Redistribution © 2020 management

6 Partners and suppliers

Very few services are delivered using only an organization’s own resources. Most, if not all, depend
on other services, often provided by third parties outside the organization (see section 2.4 of ITIL
Foundation: ITIL 4 Edition for a model of a service relationship).

The infrastructure and platform management practice allows for many outsourcing options both
from an activity perspective as well as from a technology perspective. Table 6.1 provides
examples of areas that are candidates for outsourcing.

Table 6.1 Infrastructure and platform management sourcing considerations

Activity Opportunity Applicability

Provisioning Delivery of desktops, servers, computer, Outsourcing is most effective when

network, and storage services or other standards are in place. Outsourcing may
technology services be selectively used for remote locations.

Support Restoration and prevention of incidents Support for the entire capability may be
for in-scope technologies outsourced or focused on specific roles.
Providers should adhere to standard
service desk processes for a consistent
customer experience. This works well for
remote sites, especially for desktop
support.

Administration Performing routine tasks based on Administrative tasks need to be well

operational procedures and requests documented and sufficient access must be
provided.

Operations center Outsourcing the operations center This reduces internal staffing
function reduces the need to ensure requirements. This function must be well
adequate coverage with internal staff, documented, have adequate access and
especially if it is provided at all times. frequent touchpoints are recommended to
This function can provide monitoring, understand any open issues or
systems management, job scheduling, or improvement opportunities.
other activities

Backup/restore Provider configures and manages backup Providers may leverage internal backup
jobs and repositories, addresses backup tools or may include backup solutions and
failures, and restores files as needed storage as part of the agreement.

Systems management, Manage systems to keep up to date for Standards and configurations must be well
patching, or other versions, configurations, and patches documented, and access provided.
updates Access to management tools is required.

Technology ownership Technology can be leased through With cloud offerings, this is a prominent
subscription services, reducing the capital trend in the industry. This allows for
required to implement and maintain service levels and capabilities to be
technology delivered without the overhead of building
and supporting technology internally.

With a large amount of opportunity within this space, understanding and managing outsourcing
risks is an important activity to ensure that services meet customer expectations. This should be
done in a close conjunction with other practices, such as the risk management and supplier
management practices.

AXELOS Copyright View Only – Not for Redistribution © 2020

30 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

Some examples of these risks are:

● loss of flexibility due to constraints of agreement
● additional unplanned costs if the scope needs to be modified or if consumption exceeds the
contractual terms
● contractual service levels may not align with customer expectations
● security and policy adherence of providers
● loss of internal talent as role moves from performing activities to oversight of those activities
● lack of visibility.

Although all functions can be outsourced, it is recommended to retain oversight and architecture
functions. Oversight ensures providers are delivering to their committed levels and allows insight
into potential improvements to the existing agreement. To effectively support and continue to
deliver services, the knowledge of how solutions connect across providers must be well understood
by the internal team. As the specific knowledge in specific technologies moves to the provider,
there should be an architectural role internally that understands the design and operations of the
infrastructure environment.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Infrastructure and platform 31
for Redistribution © 2020 management

7 Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an
organization might consider when establishing and nurturing their own practices. The practice
guides are catalogues of topics that organizations might think about, not a list of answers. When
using the content of the ITIL practice guides, organizations should always follow the ITIL guiding
principles:
● focus on value
● start where you are
● progress iteratively with feedback
● collaborate and promote visibility
● think and work holistically
● keep it simple and practical
● optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of ITIL
Foundation: ITIL 4 Edition.

AXELOS Copyright View Only – Not for Redistribution © 2020

32 Infrastructure and platform AXELOS Copyright View Only – Not
management for Redistribution © 2020

8 Acknowledgments
AXELOS Ltd is grateful to everyone who has contributed to the development of this guidance.
These practice guides incorporate an unprecedented level of enthusiasm and feedback from across
the ITIL community. In particular, AXELOS would like to thank the following people.

8.1 AUTHORS
Angie Pederson.

8.2 REVIEWERS
Dinara Adyrbayeva, Akshay Anand, Peter Farenden, Roman Jouravlev, Vernon Lloyd.

AXELOS Copyright View Only – Not for Redistribution © 2020

Software development and management

ITIL®4 Practice Guide

AXELOS.com

11th January
2020

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 2
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020

Contents
About this document 3
General information 4
Value streams and processes 12
Organizations and people 17
Information and technology 22
Partners and suppliers 25
Important reminder 26
Acknowledgments 27

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 3
management View Only – Not for Redistribution
© 2020

About this document

This document provides practical guidance for software development and management. It is split
into five main sections, covering:

● general information about the practice

● the processes and activities of software development and management and their roles in the
service value chain
● the organizations and people involved in software development and management
● the information and technology supporting software development and management
● considerations for partners and suppliers for software development and management.
1.1 ITIL® 4 QUALIFICATION SCHEME
Selected content from this document is examinable as a part of the following syllabuses:

● ITIL Specialist: Create, Deliver and Support

● ITIL Specialist: High-velocity IT
Please refer to the respective syllabus documents for details.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 4
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020

General information
2.1 PURPOSE AND DESCRIPTION

The purpose of the software development and management practice is to ensure that
applications meet internal and external stakeholder needs, in terms of functionality, reliability,
maintainability, compliance, and auditability.

The software development and management practice focuses on the development and
management of application software. However, many of the principles are also applicable to the
software that is part of the infrastructure on which applications are developed and managed.
Software engineering is increasingly important for infrastructure and platform management, for
example in the application of Infrastructure as Code. This concept uses machine-readable
definition files to manage and provision IT infrastructure and platforms, instead of physically
configuring hardware components.

Software development and management covers the whole lifecycle of applications. This can vary
from several months to several decades and is on average 10 to 15 years. From an economic
perspective, historically on average 20% of the total costs of ownership of an application was spent
on development as opposed to management, and 20% of software management costs is related to
corrective maintenance.

In the modern world bigger shares of an application’s total costs of ownership shifts to
development. Since constant changes become an integral part of the application lifecycle, all
maintenance activities can become a part of development and are usually not referred to as
maintenance.

2.2 TERMS AND CONCEPTS

Software

A set of instructions that tell the physical components (hardware) of a computer how to work.
Software manifests itself in applications for end users but also in the underlying infrastructure that
is needed to develop and operate applications. Software and infrastructure are service
components that are combined with other service components or resources to form products and
services.

Software is a crucial part of business. It can provide value to customers through technology-
enabled business services. Software development becomes critical as most modern services
become not software-aided, but software-enabled.

Software Development

The design and construction of applications according to functional and non-functional

requirements and correction and enhancement of operational application according to changing
functional and non-functional requirements.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 7
management View Only – Not for Redistribution
© 2020
The trend to outsource software development services has been reversed in recent years, with
many organizations taking critical and strategic development back in-house. This includes banks,
insurance and retail companies.

Maintenance

The modification of the application as part of development, for both correction

and enhancement purposes:
• corrective: correcting defects in the application that have caused incidents
• preventive: preventing defects in the application before they have manifested
themselves
• adaptive: adapting the application to work with changed infrastructure
• perfective: enhancing the functionality, usability and performance of the application
(sometimes known as ‘additive maintenance’, ‘enhancement’ or ‘development’).

With the rate of change modern services are experiencing, services become ever-changing. It is
usual for the modern application to be modified throughout its lifecycle. This means that all the
activities which used to form maintenance are now part of development process.

Software management is a broader term, potentially referring to application strategy and

planning, operation, safekeeping of the application artefacts and application decommissioning.

The purpose of the practice states that applications should meet internal and external stakeholder
needs, in terms of functionality, reliability, maintainability, compliance, and auditability. All the
terms mentioned describe software quality.

Software quality

A qualification of the value of software as a product and in its use. A common categorization
(ISO/IEC 25010:2011) is:
• product quality: functional suitability, performance efficiency, compatibility, usability,
reliability, security, maintainability, and portability
• quality in use: effectiveness, efficiency, satisfaction, freedom from risk, and context
coverage.

Quick-fixes are often preferred to proper but time-consuming changes. The high rate of change in
software may lead to an accumulated amount of rework that will have to be done at some point,
known as a technical debt.

Technical debt

The total rework backlog accumulated by choosing workarounds instead of system solutions that
would take longer. In case of software development and management, it’s total amount of rework
needed to repair substandard (changes to) software.

For many practitioners involved in software development and management the main watershed
lies in how Agile the chosen software development lifecycle (SDLC) model is.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 7
management View Only – Not for Redistribution
SDLC model

The sequence in which the stages of the software development lifecycle are executed.
The major stages are:
• establish requirements
• design
• code
• test
• run/use the application.
• waterfall model: each stage of the development lifecycle is executed in sequence,
resulting in a single delivery of the whole application for use.
• incremental model: after the requirements and priorities for the whole application have
been established the application is developed in parts (builds). For each build, each of the
further stages of the development lifecycle is executed in sequence. Builds can be
(partially) developed in parallel, and the application is delivered in useable parts.
• iterative or evolutionary model: after the requirements and priorities for the whole
application have been partially established, the application is developed in separate builds
such as in the incremental model, but because the requirements could not be fully
established at the start, the design, coding, testing or the use of a build may lead to
refinement of the requirements, leading to refinement of part of the application in another
build.

Agile and Scrum approaches are a combination of incremental and iterative, focusing on close
collaboration with the owner of the application in order to obtain fast feedback and achieve quick
development of small increments from which the owner can derive value.

Scrum

An iterative, timeboxed approach to product delivery that is described as ‘a framework within

which people can address complex adaptive problems, while productively and creatively delivering
products of the highest possible value’ (The Scrum Guide by Ken Schwaber and Jeff Sutherland,
updated November 2017).

DevOps approaches further improve throughput by speeding up the transition from coding to
run/use, using techniques such as continuous integration/continuous delivery to (partially)
automate the deployment pipeline.

Many Agile approaches use ‘definition of done’ as a tool to agree the set of criteria to be met
before the product or product increment/backlog item is considered done.

Definition of done

The agreed criteria for a proposed product or service, reflecting functional and non-functional
requirements.

2.3 SCOPE
The scope of software development and management is defined in terms of activities and the
resources affected by the activities.

The activities supported by the software development and management practice include:

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 7
management View Only – Not for Redistribution
● application development
© 2020
● software and software artefacts management
● operating the application (in close collaboration with infrastructure and platform management).
The resources within the scope of the software development and management practice are the concrete
application artefacts within the various environments that are used. The major application artefacts are
specifications, designs, source code, object code, and documentation.

In terms of responsibilities, the software development and management practice is positioned between:

● the owners of the application, who determine the requirements for development and/or
management
● infrastructure management, that (a) provides the environments for software development and
management and (b) manages the production environment in which software management
operates the applications
● users that require support regarding the use of applications
● software management organizations that:
• were previously tasked with management of the application and are involved with
onboarding of an application
• are tasked with the future management of the application and are involved with offboarding
of an application.

There are many activities and areas of responsibility that are not included in the software
development and management practice, but they are still closely related. These are listed in
table 2.1, with references to the practices in which they can be found. It is important to
remember that ITIL practices combine value chain activities through value streams to deliver
value.

Table 2.1 Related activities described in other practice guides

Activity Practice guide
Software architecture Architecture management
Utility and warranty Business analysis
requirements
Deployment of application Deployment management
artefacts from one environment
to another
Providing interface for feedback Service desk
from users
Portfolio management
Application portfolio
management
Making applications available for Release management
use and enabling users
Validating that application meets Service validation and testing
the requirements
Testing the potentially releasable
application

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 8
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020
Orchestrating overall design for Service design
applications
Applications monitoring Monitoring and event management

2.4 PRACTICE SUCCESS FACTORS

Practice Success Factor (PSF)

A complex functional component of a practice that is required for the practice to fulfil its
purpose.

A PSF is more than a task or activity; it includes components from all four dimensions of service
management. The nature of the activities and resources of PSFs within a practice may differ, but
together they ensure that the practice is effective.

The software development and management practice includes the following PSFs:

● agree and improve an organization's approach to development and management of software

● ensure that software continually meets organization's requirements and quality criteria
throughout its lifecycle.

The first PSF is about selecting the appropriate approach and the second one about applying it.

2.4.1 Agree and improve an organization's approach to development and

management of software
There are various ways of developing and managing software, as described in SLDC model (2.2).
These are waterfall, incremental, and iterative (or evolutionary). Agile and Scrum approaches are
a combination of incremental and iterative.

It is a prerequisite for the software development and management practice that multiple
approaches are available. These reflect the variety of situations that are expected to occur. This
strategic decision also involves other practices, for example architecture management, business
analysis, change enablement, release management, deployment management, information
security management, portfolio management, risk management, service validation and testing,
and strategy management. The decision is therefore taken in the context of the (service) value
streams in which these practices are applied.

This Practice Success Factor for software development and management concerns itself with the
tactical decision to select from this pre-defined set of approaches, the best approach for each
software product, based on the organization’s requirements for the product.

This tactical choice depends on how much information is available about both the work to be
completed and the resources that are needed to execute the work. The work to be completed can
be subdivided into the requirements and the priority with which they must be fulfilled. Depending
on the how much information is available about the requirements, priorities, and required
resources, an appropriate approach can be selected.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 9
management View Only – Not for Redistribution
© 2020
Some examples:

● A waterfall approach can be an effective choice when the requirements and priorities are
known, and when it is also known how to develop the software, and which resources are
needed.
● A timeboxing approach in which the most important work items are developed first, could be a
better choice when the requirements and priorities are known, but it is not yet known how to
develop the software and which resources are needed.
● When the requirements and priorities are known at a high level but are difficult to finalise, a
linear iterative approach would allow the product owner to experience and refine the product
across several iterations.
● Parallel experimentation may provide the product owner with prototypes that help formulate
the requirements when the requirements are ambiguous or even unarticulated.

Different approaches require different combinations of resources. These resources span all four
dimensions of service management and are addressed in sections 3 to 6 of this document.

Commonly encountered combination of resources:

● Small, relatively independent, multi-functional, product-based development/maintenance

teams in which a product owner manages the priority of the work to be done.
● Platform-based teams that support the development/maintenance teams with the
(self-)provision of the required infrastructure for development/maintenance and production.
● Version control tooling that tracks all production artefacts (e.g. code and documentation).
● Automated processes for continuously integrating and delivering/deploying software.

Several practices are involved in realizing this PSF. The requirements for the approach from the
software development and management practice emerge in the form of organizational
performance information and improvement opportunities. These transformed into improvement
initiatives and plans (continual improvement practice). The plans are executed (organizational
change management practice), resulting in various approaches and resources that can be applied
according to the characteristics of the work to be done (software development and management
practice).

2.4.2 Ensure that software continually meets organization's

requirements and quality criteria throughout its lifecycle
Software quality is used to describe software as a product and in its use, commonly in terms
such as:

● product quality: functional suitability, performance efficiency, compatibility, usability,

reliability, security, maintainability, and portability
● quality in use: effectiveness, efficiency, satisfaction, freedom from risk, and context coverage.

In the ISO/IEC 25010:2011 standard, each of these characteristics comprises up to six sub-characteristics
that help to specify the desired properties of the software. They can also be regarded as utility
requirements (e.g. functional suitability and usability) and warranty requirements (e.g. performance
efficiency and maintainability).

Software development and management-related activities influence, or are influenced by, these
characteristics. For example, maintainability depends significantly on how source code is
structured and documented (both in the documentation for maintenance and in the source code

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 10
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020
itself). At the start of the initial development of the software, decisions are taken how much time
to invest in maintainability. This depends on how much maintenance is expected, and whether the
investment will be worthwhile. During the initial development of the software, these requirements
are fulfilled. The initial development therefore influences the maintainability of the software.
After the initial development, maintenance is affected by the realised maintainability of the
software. Understanding the software typically represents half of the maintenance effort, so
maintainability influences the speed and cost of maintenance.

Maintenance is not only influenced by maintainability but also influences it. The quality of
software tends to degrade (‘software entropy’) unless an effort is made to maintain it. This
investment limits technical debt (the rework needed to repair substandard changes to software).

Many of the requirements for these software quality characteristics are input for software
development and management. They are determined by the owner of the software. However,
some characteristics are not the primary concern of software development and management. For
example, effectiveness is determined by the users’ understanding of the software and how they
use it and the information or devices that the software enables.

The most important components of this Practice Success Factor are:

● understanding the source code, how the various modules are interrelated, and the application
architecture
● understanding the requirements and the context in which the application is used
● ensuring that non-functional (warranty) requirements are included in the Definition of Done
● creating tests before coding
● effective version control of all application artefacts
● approaching the task of coding with a full appreciation of its tremendous difficulty and
respecting the intrinsic limitations of the human mind1
● adhering to coding conventions
● peer review
● fast feedback from testing, for example by using automated testing, and taking remedial action
quickly.

Software development and management is not the only practice involved. Realising this PSF also
entails establishing the right requirements for the software (business analysis), testing whether the
software complies with these requirements (service validation and testing), running the software
on the production infrastructure (infrastructure and platform management), formulating problem
reports (problem management), etc. The metrics must therefore be regarding in this broader
context.

2.5 KEY METRICS

The ITIL practices are means, or tools, for the management of products and services. Like the
performance of any tool, practice performance can be assessed only in the context of that tool’s

1
Dijkstra, E.W. The Humble Programmer (1972)
www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html [Accessed 29th October 2019]

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 11
management View Only – Not for Redistribution
© 2020
application. However, tools can differ in quality. This difference defines the tool’s potential or
capability

Table 2.2 Example metrics for the practice success factors

Practice success factors Example metrics

Agree and improve an ● Stakeholders’ satisfaction with the approach chosen for
organization's approach to software development and management
development and management of
● Percentage of the development teams following the chosen
approach
software
● Stakeholders’ satisfaction with the rate of change allowed by
the chosen approach
● Improvement initiatives throughput for the software
development and management practice
● Approach compliance to the internal and external
requirements, policies and legislation.

Ensure that software continually ● Stakeholder satisfaction with the applications delivering the
meets organization's value
requirements and quality criteria
● Applications compliance with internal and external
requirements and policies
throughout its lifecycle
● Frequency of delivery of software (for new or changed
functionality)
● Speed of delivery of software (from receipt of specifications to
code committed to the repository and released for
deployment)
● Reliability of delivery of software (defects detected after
release for deployment)
● Cost (per function point or other unit of size; decreasing cost)
● Technical debt (estimated cost of rework to repair
substandard (changes to) software)
● Resource utilization (compute, network, storage)
● Availability of software (MTTR, MBTF)
● Security breaches and costs related to audits etc.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 12
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020

Value streams and processes

3.1 VALUE STREAM CONTRIBUTION
Like any other ITIL management practice, software development and management contribute to
multiple value streams. Remember, no value stream is made up of a single practice. Software
development and management combines with other practices to provide high-quality services to
consumers. The main value chain activities to which software development and management
contributes are:

● obtain/build
● deliver and support.

Figure 3.1 Heat map showing the main value chain activities to which software
development and management contribute to

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 13
management View Only – Not for Redistribution
© 2020

Figure 3.2 Code, build and run correspond with the service value chain activities
obtain/build and deliver and support

3.2 PROCESSES
Each practice may include one or more processes and activities that may be necessary to fulfil the
purpose of that practice.

Process

A set of interrelated or interacting activities that transform inputs into outputs. Processes
define the sequence of actions and their dependencies.

There are numerous models to structure processes of the software development and management
practice. These span several decades and range from waterfall, such as the V-model or the
Winston W. Royce’s model, to iterative and incremental ones, such as Agile and Spiral approaches.

A service provider organization normally combines vastly different approaches to achieve the most
efficient and manageable set of repeatable processes. However, a set of activities common among
the majority of practical approaches can be identified for the purposes of this publication.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 14
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020
Table 3.1 Inputs, activities and outputs of the software development and
management practice
Input Activities Output
● Product planning and ● New backlog/project tasks,
● Business case, business logic
prioritization project or change delivery plan
requirements, service
● Software design ● Technical requirements for new
models, architecture
● New code production or changed software.
documents, user stories,
● Code review ● Application code, test cases,
tasks, defects in the
existing backlog and project
● Defect handling automated unit tests
● Technical debt management ● Updated code, new backlog
plan
● Relevant backlog\project
● Code refactoring items
● Research and Development ● Meeting agendas, meeting
items
● Existing environment ● Regular meetings and minutes, schedules, meeting
improvement activities minutes, decisions and new
configuration
● Existing development ● Software operation and rules, action plans

toolset and version tracking maintenance automation ● Software pipeline, monitoring,

methods ● Managing development and maintenance automation
environments tools
● User feedback on
applications ● Version Control. ● Updated development
environment configuration
● Technical standards for
application development.
● New versions ready for
deployment, software change
record keeping
● New/proposed changes to
architectural decisions
● Information about the value of
the software
● Release notes about the
software being developed:
technical documents and user
documentation (how to use,
install, configure);
administration documentation
(how to manage)
● New/proposed changes to
technical standards.

Table 3.2 below suggests two different scenarios of realising the activities: in a traditional
waterfall project environment, and in an agile product centred development team.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 15
management View Only – Not for Redistribution
© 2020
Table 3.2 Activities of the software development and management practice
Activity Project management example Product management example

Product planning and A requestor submits a new batch A product owner collects new
prioritization of work to a relevant project external requirements, including
manager, or to a development discovered defects to a backlog,
team leader. and possibly along with the
development team selects the
tasks from backlog to be
delivered in the next iteration.
Software design A developer or an analyst Based on the specifics of the
delivers technical code software and coding
requirements to be realized in conventions, the technical
the software, based on the specifications and algorithm
business logic documents. descriptions can be built in the
code directly with no separate
documentation delivered.
New code production A software developer delivers A software developer delivers
the software code along with the the software code and ensures
unit tests and ensures the unit the unit tests pass completion.
tests pass completion. They then They then commit the code for
submit the code for testing and automated or manual testing.
validation and approval.
Defect handling A software developer analyses A software developer analyses
the defect task to verify the the defect task to verify the
defect. They raise project issue defect. They then amend the
with the project management to software code to fix the defect.
ensure resources to fix the
defect are planned. and amends
the software code accordingly.
Technical debt mitigation A software developer analyses the technical debt task and amends
the software code or architecture accordingly.
Code review A software developer checks the code by viewing or reading the
code. It is preferable that at least one of the reviewers is not an
author of the code.
Code refactoring Refactoring is restructuring source code without changing its
external behaviour, with the intent to improve the
maintainability, efficiency etc.
A software developer analyses the code refactoring tasks and
amends the software code or architecture accordingly.
Research and development A software developer analyses the research and development
task, in the backlog and proposes new tasks to be added to the
backlog.
Regular meetings and Software developers, or The development team performs
improvement activities development team leader regular iteration assessment, for

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 16
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020
participate in project example to ensure valid progress
communications and interact on the tasks, to plan next period
with other project teams to of work, and to highlight
ensure timely information impediments.
exchange, and risk and issue
management.
Software operation and During an implementation The software developers
maintenance automation project, the software developers optimize the human resources
deliver a toolset to automate required to operate the software
operations of the software, such by developing and evolving an
as diagnostics harvesting, operations toolset.
resilience enhancements,
monitoring and alerting systems,
routine maintenance, etc.
Software developers maintain
and evolve the toolset alongside
software operations.
Managing development The development team leader ensures that a development
environments environment configuration is provided to the development team.
Version control The development team leader implements a version control rules
and toolset to ensure consistent code tracking among the team
members.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 17
management View Only – Not for Redistribution
© 2020

Organizations and people

4.1 ROLES, COMPETENCIES, AND RESPONSIBILITIES
The practice guides do not describe the practice management roles such as practice owner,
practice lead or practice coach. The practice guides focus on specialist roles specific to each
practice. The structure and naming of each role may differ from organization to organization, so
any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember:
roles are not job titles. One person can take on multiple roles and one role can be assigned to
multiple people.

Roles are described in the context of processes and activities. Each role is characterized with a
competence profile based on the following model:

Competence Description
code

L Leader. Activities and skills associated with this competence include decision
making, delegation, overseeing other activities, incentives and motivation, and
evaluating outcomes.

А Administrator. Activities and skills associated with this competence include the
assignment and prioritization of tasks, record keeping, ongoing reporting, and basic
improvement initiatives.

C Coordinator/communicator. Activities and skills associated with this competence

include the coordination of multiple parties, communication between stakeholders,
and the running of awareness campaigns.

М Methods and techniques expert. Activities and skills associated with this
competence include the design and implementation of work techniques, the
documentation of procedures, consulting on processes, work analysis, and continual
improvement.

Т Technical expert. This competence focuses on technical (IT) expertise and

expertise-based assignments.

4.1.1 Roles involved in the software development and management

activities
Examples of roles which can be involved in the software development and management
practice activities are listed in table 4.1, together with the associated competence profiles
and specific skills.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 18
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020
Table 4.1 The roles involved in the software development and management activities

Activity Responsible roles Competency Specific skills

(examples) profile

Product planning and Project manager CMLT Good knowledge of business

prioritization objectives
Product owner
Good command of project
management practices and
other relevant delivery
methods

Software design Business analyst TM Technical development and

analysis tools specific to
Or
software
Software developer

New code production Software developer TM Technical development and

analysis tools specific to
software

Defect handling Software developer TM Technical development and

analysis tools specific to
software

Technical debt mitigation Software developer TM Technical development and

analysis tools specific to
software

Code review Software developer TM Technical development and

analysis tools specific to
software

Code refactoring Software developer TM Technical development and

analysis tools specific to
software

Research and development Software developer TMC Technical development and

analysis tools specific to
software

Regular meetings and Software development CLT Technical development and

improvement activities team leader, Product analysis tools specific to
owner, software software
developers, business
analysts, Testing
engineers, Scrum master

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 19
management View Only – Not for Redistribution
© 2020

Software operation and Software developer TMC Technical development and

maintenance automation analysis tools specific to
software

Understanding of software
operations and nature of the
manual activities required to
maintain and operate the
software.

Managing development Software development MTC Good knowledge of controlled

environments team leader, software environment configuration
developers, infrastructure
engineer

Version control Software development MTC Good knowledge of software

team leader, software version tracking approaches
developers

4.1.2 Software developer/team member

The key role for the software development and management practice is the developer, or an
engineer. This is the most common type of a knowledge worker in the IT field. The algorithmic
thinking is a core of the skillset for a software developer. Other aspects of the core software
developer knowledge and skill set are:

● programming languages, environments, and technologies

● object oriented software design
● contemporary system architectures, such as Event Driven Architecture (EDA)
● software testing approaches and methods
● problem-solving techniques.

However, a modern software developer needs to have a strong command of a broad spectrum of
technical and communication competencies:

● knowledge of technologies adjacent to the technology stack that they work in

● techniques to plan and priorities activities, decisions, and risk mitigation measures within their
scope of control, be it themselves, or the team they manage
● skills in interpersonal, bi-directional, and broadcasting communications, including ability to
highlight issues, transfer ideas and concepts, and document and present the solutions
● continuous learning ability to keep up with the pace of technology evolution.

There are also a set of personal traits that a software developer must maintain and harness:

● Willingness to quickly advance on a problem resolution journey to explore new possibilities, to

experiment, and to take reasonable risks (see for example the OODA Loop approach, High-
velocity IT).
● Eagerness to review what has been done, such as bug fixing, code refactoring, legacy software
maintenance, and technical debt tasks.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 20
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020
● Systemic approach to the operations tasks, with an outlook to automate deployment,
maintenance, backup, monitoring and other mundane chores related to operating of the
software.
● Agility in teamwork approach, where software developers migrate between teams, products, or
projects, which is especially crucial in commercial and large-scale service provider
organizations.

4.1.3 Software team leader

It is common for a software developer to go through a career progression from a junior developer,
dealing with elementary tasks of low risk, to a senior developer with more experience around a
specific product and underpinning technologies. A senior developer can be the key knowledge
bearer other development team members seek for advice.

One career path open to a senior developer is a team leader, colloquially known as a ‘team lead’
role. A team leader can in some organizational environments carry a managerial designation
(especially in traditional teams) but is first and foremost a servant leader for their team of
developers (read more on Servant Leadership in High-velocity IT and Create, Deliver and Support).

The primary task of a team leader is to be an effective liaison for their software development
team within a broader business or service provider context. Apart from skills and behaviours listed
for a software developer, the following should be prominent in a team leader:

● understanding of the business problem the software is solving

● understanding of impediments their team is facing
● understanding of the service provider context and value streams that the service provider which
the development team is part of owns
● understanding of the business context the software is going to be used in
● understanding of other disciplines like management, product development, marketing, etc.
● negotiation techniques
● motivation and incentivizing of the personnel techniques.

There are further roles within a software development and management organization with
progressively expanding scope of control, such as tech lead, development managers, etc. See
section 4.2 Organizational structures below.

4.1.4 Scrum master/Agile coach

A Scrum master is a colloquial term originating from the Scrum Guide by Jeff Sutherland and Ken
Schwaber (see https://www.scrumguides.org). This role normally represents a coaching discipline
in an Agile environment. The scrum master is there to ensure that an agile way of working is
adhered to by all staff involved. This objective can be realized in a variety of ways, from purely
consulting and communication tasks to a subset of the servant leadership and management tasks.
In the latter case naturally the team leader takes upon responsibilities of a scrum master.

The importance of coaching originates from the fact that Agile methods require foundational
changes to the habits and traditions around how the services and products are delivered. Coaching
helps team members develop and maintain new behaviours and attitudes, as well as promote the
visibility of the outcomes of all team activities. The coaching for example is the foundation of
suggested Toyota Kata continual improvement practice (see 3.4.3 High-velocity IT).

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 21
management View Only – Not for Redistribution
© 2020
Read more on the culture shift that modern agile service provider environments require in High-
velocity IT (3. High-velocity IT culture) and in Create, Deliver and Support (2.3 Developing team
culture).

4.1.5 Product owner

This is a role external to the software development and management team, but which is
paramount to its success. The product owner is generally defined in some agile frameworks as the
person ultimately responsible for business results. There are parallels in a traditional
organizational set up, such as project managers, or even service owners.

The software development and management practice may be realised in a service provider
organization in a variety of ways, including agile frameworks such as Scrum. It is crucial therefore
to define a single authority for the development team to turn to for prioritization of its work, and
for external escalations. Therefore, this role is the pivotal point to enable correct interfaces
between the development team and other parts of service provider and service consumer
organizations.

4.2 ORGANIZATIONAL STRUCTURES AND TEAMS

However talented or productive, a single development team can rarely satisfy all the demand for
new or updated services. As the size of a team is conventionally defined around natural ability to
manage directly, i.e. 5 to 7 staff per manager, the number of development teams is a primary
organizational variable, determining the human resource investment in the software development
and management practice.

Although all software development and management teams perform similar activities, they can be
grouped together differently, depending on relative importance of software products in the service
offerings and on overall organizational design, for example:

● the purpose and functionality of the software

● the functionality of the software
● the platform on which the software runs
● the type or brand of technology used.

One example is product teams: a relatively self-contained, multi-disciplinary and multi-tasking

development/management team that exists for as long as the application (the ‘product’) exists;
this is an alternative to temporary project-based teams that are formed to execute a project and
are then disbanded. Work is executed in more consistently than in the project-based scenario.

By the end of the 20th century, application development and management departments within
internal and commercial IT service providers acted mostly as independent units, at times even as
parts of different entities. The disconnect between the two has not been dissimilar to the
traditional project vs operations silos. However, more recently these two departments are being
brought together, experiencing greater pressure from the business to be more responsive and
cooperative. The DevOps model caters for such integration, suggesting that the onus is on
developers to ensure automated and error-prone deployment of software and its ongoing operation
and maintenance.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 22
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020

Information and technology

5.1 INFORMATION EXCHANGE
Effective information exchange is essential for the success of the software development and
management practice. It is important to note that each development team rarely acts
independently by delivering a full-scale software product, but rather contributes constituent parts
to service offerings. Such team depends on outputs from other teams (such as infrastructure and
platform management) and produces outcomes likely used by other development team (for
example reusable code libraries) and further steps in value streams (such as quality assurance or
deployment).

Requirements, support requests, and incidents are the primary input for software development
and management, and access to and information about the operational application are the
primary output.

Figure 5.1 software development and management input and output

It is important information exchange is clear and reliable. It should be designed to be efficient

both among team members, possibly widely distributed geographically, and also with external
teams.

At the core of almost every activity in the software development and management practice is the
concept of an item in a backlog.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 23
management View Only – Not for Redistribution
© 2020
Depending on specific toolset or a method in use, the items can bear different names and
taxonomies. A hierarchical roll-up groupings, such as ‘epic’ or ‘themes’ can be in use in
development environments where hundreds and thousands of items are in progress simultaneously.
In some cases, items of different nature can even have different life stages and progress
conditions. And large development and product-focused organisations can adopt a hierarchy of
backlogs to distribute and control items flow.

It is nevertheless generally accepted that items of a backlog should be processed in a unified lean
manner, much like the value stream method suggests. The development team should plan the
work, look for bottlenecks, and focus its activities and information exchange on the value it
delivers.

An agreed amount of documentation must be produced to support:

● ongoing development
● operations
● use.
This documentation is in addition to temporary design documentation, which describes what needs
to be created or modified.

5.2 AUTOMATION AND TOOLING

Software-related activities benefit greatly from information management tools that underpin
them. Table 5.1 below suggests specific tools for each of the activities.

Table 5.1 Automated solutions for software development and management

activities.

Activity Means of Automation Key Functionality Impact on Practice

Product planning and Task and workflow Work scheduling and High
prioritization tracking toolset visualization

Project management
toolset

Software design Development toolset, Collaboration and High

development automated design
environments

New code production Development toolset, Code management High

development
environments

Code review development toolset, Code management High

development
environments

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 24
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020

Defect handling Development toolset, Code management High

development
environments

Technical debt Workflow and task Code management High

mitigation tracking systems, Known
errors database,
Development toolset,
development
environments

Code refactoring development toolset, Code management High

development
environments

Research and Development toolset, Code management High

Development development
environments

Regular meetings and Development toolset, Collaboration and Medium

improvement activities development scheduling; record
environments keeping

Software operation and Remote administration Scripted task automation High

maintenance automation tools, configuration and scheduling,
management tools, infrastructure
automated deployment orchestration
systems, development
toolset, development
environments

Managing development Configuration Infrastructure High

environments management toolset, orchestration
development
environments

Version Control Development toolset, Code repository High

development management
environments

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 25
management View Only – Not for Redistribution
© 2020

Partners and suppliers

Very few services are delivered using only an organization’s own resources. Many organizations
often depend on services provided by third parties (see ITIL® Foundation: ITIL 4 Edition section 2.4
for a model of a service relationship).

Development teams represent a highly specialised capability that most organisations would not
have suitable means to manage. It is common for contemporary internal service providers to
outsource the software development and management capabilities to third parties. When either or
both development and management of business applications and other software is sourced
commercially, the service provider management should consider all complexities that accompany
defining what good output from that external provider must look like.

There are several important quality criteria that need to be negotiated, agreed, and defined in the
respective software sourcing contract:

● The definitions of service. As obvious as it can be, the exact and explicit definition of the
service offerings for a development and management contract is an absolute must. The
activities within this practice provide an overall range of things that a development team can do
in order to ensure software quality. That list is not limited to simple new coding and bug-fixing
but encompasses whole software lifecycle. The parties should consciously negotiate the
required activities from the range and consider both pricing, and partnership benefits that are
most important to both.
● People and organisations. The parties must agree on the organizational structure, expected
knowledge transfer mechanisms, expected turnover rates, vetting principles, and geographical
location of the staff that will populate the development teams.
● Value streams and processes. The parties must agree on how the external development teams
should interact with others. This is especially important, where some development and
management capabilities are retained within the service provider and external teams will need
to be compliant to two sets of controls: one within the supplier organization, i.e. their
employer, and another one within the service provider, i.e. the client organization. Examples of
clashes that can occur are abound: from simple burden of double record keeping and backlog
grooming (borderline waste), to complications during availability planning. The work of service
owners (or product owners in an agile environment) becomes pivotal in analysing the external
development team involvement in value streams.
● Information and technology. The parties must clearly define the single systems of record for the
purpose of the contract, as mentioned above, there is little merit in making the development
teams spend time in duplicating defect records in their ‘native’ and external systems. The
information security considerations and onboarding of new staff are also something to be
covered explicitly in the agreement.

Arguably a systemic cost-benefit analysis yields results quite different from an intuitive
expectation that external specialised development teams are always ‘cheaper’ and ‘more
effective’ than internal teams. The additional benefits expected in the short term have no long-
term guarantee, simply because of the speed and emerging nature of software development. That
rate of change in practices, architectures, and user expectations may require capabilities that an
external supplier might not be willing to deliver.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 26
Software development and AXELOS Copyright
management View Only – Not for Redistribution
© 2020

Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an
organization might consider when establishing and nurturing their own practices. The practice
guides are catalogues of things that organizations might think about, not a list of answers. When
using the content of the ITIL Practice guides, organizations should always follow the ITIL guiding
principles:

● focus on value
● start where you are
● progress iteratively with feedback
● collaborate and promote visibility
● think and work holistically
● keep it simple and practical
● optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of the
ITIL® Foundation: ITIL 4 Edition publication.

AXELOS Copyright
View Only – Not for Redistribution
© 2020
Software development and AXELOS Copyright 27
management View Only – Not for Redistribution
© 2020

Acknowledgments
AXELOS Ltd is grateful to everyone who has contributed to the development of this guidance.
These practice guides incorporate an unprecedented level of enthusiasm and feedback from across
the ITIL community. In particular, AXELOS would like to thank the following:

8.1 AUTHORS
Mark Smalley, Konstantin Naryzhny

8.2 REVIEWERS
Oleg Skrynnik

AXELOS Copyright
View Only – Not for Redistribution
© 2020
 AXELOS Copyright
View Only – Not for Redistribution
© 2020