- [Instructor] How can we adapt devops values,
principles, methods, practices, and tools
for ITIL-driven shops
and ITIL-driven shops for devops?
Let's have a look at this now.
The four fundamental devops values
used by many devops practitioners
are summarized in the acronym CAMS
created by devops pioneers John Willis and Damon Edwards
which stands for
Culture, Automation, Measurement, and Sharing.
The C in CAMS stands for Culture.
In devops, this is a blameless culture
which balances safety for sharing failures
and asking for help with accountability
as well as a culture of breaking down barriers
to effectively working together.
The A in CAMS is for Automation,
the devops value of saving time,
preventing defects and variation, and enabling self-service.
M is for Measurement,
the devops value of data being transparent
and accessible to all
as a basis for fact-based decision and improvement.
And finally, S is for the value of Sharing of tools,
discoveries, lessons, and so on
across and outside the organization.
So how do devops values
intersect with ITIL-driven practices?
Let's have a look.
Let's start with culture.
Culture is a system of shared
assumptions, values, and beliefs
which governs how people behave in organizations.
These shared values have a strong influence
on the people in the organization
and dictate how they dress, act, and perform their jobs
where your organization develops and maintains
a unique culture which provides guidelines and boundaries
for the behavior of the members of the organization.
In ITIL, four organizational units are specified,
the service desk, IT operations,
applications management, and technical management.
So apply the C in CAMS to these ITIL functions
and break down barriers.
One way you can do this
is by engendering a blameless culture.
Blamelessness is a huge barrier breaker.
The reason you can be iterative is failure is expected
and that means a blameless environment.
The blameless culture,
especially evidenced in blameless postmortems,
is perfectly compatible with ITIL practices.
And if it's not already how you do things around here
for your organization,
consider adapting it for all post implementation
and major incident and problem reviews.
Automation is the A in CAMS.
Devops is not just about automated tooling.
People and process, they've got to come first.
Damon Edwards expressed this view as
people and process over tools.
Having said this, the fabric of automation you create
allows you to control your systems and your applications
to minimize and eliminate variations and defects,
enable self-service, and reduce time to value.
Automation is super important,
but also the understanding of what you're trying to automate
and why is also super important.
Here you can apply the devops value of automation
to service management technology and architecture.
For example, you can set up self-service tooling
to allow dev plus ops service teams
to develop, test, deploy, and operate their services.
Measurement is the M in CAMS.
The devops value for making data transparent
and accessible to all
and meaningful and readily visualized
as a basis for fact-based data-driven
decisions and improvement.
Here we can apply the devops value of measurement
to the ITIL service lifecycle phase
of continuous service improvement.
ITIL-driven shops emphasize technology
service and process metrics.
The one thing to understand here is that in devops culture,
you just don't show up without data
and everything is shared
and there's instrumentation and analytics
and telemetry on everything.
It's like measurement on steroids.
To adapt our ITIL shop for devops,
make sure all technology process
and service metrics are shared,
easily accessible by self-service pull rather than push.
Measure and share things like mean time to repair,
costs, revenues, and customer and employee satisfaction
internally and even externally with customers
so that you can achieve shared insight
across systems and teams
into the state of your systems and services.
Sharing is the S in CAMS.
Sharing objectives, ideas, problems,
tools, code, discoveries, lessons, and work products
across the organization and even outside the organization.
It can eliminate duplication of effort.
It can reduce the time it takes to innovate
and to deliver more value.
Sharing is the feedback loop
that helps teams continuously improve.
Here we apply the devops value of sharing
to the ITIL process of knowledge management.
Start by shifting from an emphasis
on knowledge management processes
that capture and curate knowledge
to one that focuses on openness and transparency
and the sharing of ideas, problems, tools, codes,
discoveries, lessons, and work products
across the organization.
For example, many tools could be shared between dev and ops
and used in both dev and production,
but some are not
such as monitoring and control applications.
So start there
or start by putting in place the open office concept
which lends itself to collaboration and sharing
as sharing is enabled by culture and environment
which, if left the chance, may prevent
or at least not promote sharing from happening.