- [Narrator] The ITIL glossary covers literally
hundreds of concepts, definitions, and acronyms,
as well as key principles and models.
Those covered in the ITIL foundation course
are shown here for your reference.
ITIL makes a point of defining terms
and drawing distinctions,
because when people don't share the same language
and understanding,
a lot of time and resources can get wasted
defining and redefining terms and then
making and recovering from errors
due to a lack of shared understanding
of terminology.
Having a shared understanding of standardized definitions
for common I.T. terms is one of the most valuable
aspects of adopting and adapting ITIL,
as it lowers this overhead across the board,
within teams, across the organization
between organizations,
with suppliers, and with consultants,
in ephemeral project teams.
With the introduction of DevOps practices,
new terminology is introduced.
We are not concerned with this here,
here we're concerned with how the introduction
of DevOps
affects ITIL terminology, key principles, and models.
Here's how.
First,
some terminology, like patterns
of business activity,
is unaffected by the introduction of DevOps practices.
Next, for most, if not all terminology,
the why, or outcome, is unaffected.
It's more a matter of the pace at which things
are conducted,
and what gets done and how.
For some terminology, the how gets affected.
What it means the next level down.
For example, in value creation through services,
how value is delivered to customers and users
changes with DevOps.
For example,
with a faster pipeline in smaller increments.
For some terminology, there is a deeper impact,
affecting the what.
For example, when we move from pets to cattle
with the cloud in DevOps,
we don't care what CI's look like,
because we know what they look like.
All sequel boxes, for example,
look the same.
And they're either small, medium,
or large.
What we focus on instead of managing CI's,
is managing the scripts through which they're realized.
In other cases,
with the adoption of DevOps, some of the how to do
this typical practice in ITIL driven shops gets
superseded by DevOps how to do.
For example, ITIL major incident processes are supersesed
by ICS.
Slower paced, heavier weight,
check and balance, ITIL release processes
are replaced by
blue green deployment practices
and heavier weight incident ticketing processes
might get supplanted at least in part,
by chat and chat bots and chat ops.
Now, lets turn our attention to DevOps terminology.
DevOps introduces a whole new set of terminology
and key principles and models,
much of which come from lean and agile
practices, applied to I.T. shops overall,
and Dev in particular.
This new terminology is driven by the shift
in what me manage.
From traditional I.T.
To hybrid,
to cloud and mobile.
While service management outcomes remain vaild,
the specifics of what to do and how
to achieve those outcomes,
changes as you move from traditional I.T. to
hybrid to cloud and mobile platforms.
And this change in language reflects that fact.
One thing you can do at this intersection
is to review as a team,
how each concept, key principle, and model,
helps deliver on the what and why of
service management.
With a new how,
that is driven by the cloud mobile portion
of your hybrid environment.
This shared understanding is an important
first step in integrating DevOps language,
key principles, and models,
into your ITIL driven shop.