- [Instructor] ITIL arranges service management processes
and functions into a lifecycle from strategy, to design,
to transition, to operations, and finally
continual improvement.
While all value is seen and realized by the customer
and users in operations, the quality of that value
is the function of having the right strategy in the
first place, and therefore, the right services,
and service management capability,
and how well services are designed and moved to
production and whether or not you've got a virtuous
cycle of continual improvement for services
and service management.
In the strategy phase, we're working to make sure we
have the right services and service
management practices in place.
Listening to what consumers of our services need
and how those needs are changing,
and bringing the possibility of new technology to the table.
Then taking all of that into account and adding, changing
into leading services to gyroscopically align them
to what consumers want and need and what
technology makes possible.
To adapt your ITIL driven shops strategy phase to DevOps,
the key action is taken under principle two,
amplifying feedback loops and principle three,
a culture of continual experimentation and learning.
For principle 2, you'll need to put in place
faster more tighter feedback loops between strategy,
continual improvement and sprint planning and reviews.
You should expect shorter roadmaps, and for the typical
unit of work to shift from entire services to feature sets
and individual features and for the whole
thing to happen much faster.
The core part of strategy will also have to be
figuring out what you will do to ensure uptake
of new features and feature sets,
so that value is realized by consumers.
Think about it.
As you rack it up the pace of deployment,
it becomes more difficult for consumers to take up what
you're putting down.
You'll need a strategy to ensure they do.
For principle three, a culture of continual experimentation
and learning in strategy, you should look for more failures.
Let me explain.
With DevOps it's not that it's suddenly okay for us to
fail to plan and plan to fail,
it's just that if we're not failing at all,
we're not stretching enough.
So working to ensure that there is enough stretch,
naming more failures,
the reaction to which should be namelessness and learning.
In ITIL driven design, we design services, processes,
technology, and management architecture tools and
measurement methods and metrics
to realize the directions we decided in the strategy phase
for services and service management.
Just about every aspect of service design is
or can be deeply effected by many of the values,
principles, methods, practices, and tools of DevOps.
The cloud broadens the design palette and service design.
Adding new fabric options like microservices architecture
available for use, especially on greenfield projects.
So that's a key impact on the ITIL design phase.
Also, your DevOps tool chain and agile scrum practices
and things like CI and CD greatly effect the way
things get done in design.
You could pick with any of these to start with
in integrating DevOps in your ITIL driven practices.
So start with what makes the most sense for your situation.
In the ITIL driven transition phase, you release and deploy
the services, processes, technology, and management
architecture tools, and measurements, and metrics
we built in the design phase to realize the vision
for services and service management we decided on
in the strategy phase.
As with design, most aspects of an ITIL drive service
transition phase are impacted by DevOps.
Automation and measurement are key here as well as
CD, visible ops style change control, and
infrastructure automation.
Blandless post-morterms, the cloud, hand in cords,
and bluegreen deployment also have a big impact here.
For this phase, implementing visible op style change control
is a no brainer.
As is getting into the cloud and bluegreen
deployment if you can.
In an ITIL driven operation phase, we deliver
services and managed delivery of services efficiently
and to required service levels.
The operation phase is greatly affected by all
aspects of cams.
Other key impacts are with the introduction of SRE, ICS,
Devs on Call, public static pages, and embedding ops
in Dev teams.
One example of what you can do to get started here to adapt
your ITIL driven shop for DevOps,
is to run a weekly Ops metrics meetings covering SLA's,
service level objectives, internal goals, and
customer facing targets for the purpose of fact based
continual improvements.
Then you do experiments to improve in agile sprints.
And use data from measurement to decide what to stop,
start, and continue doing.
In ITIL driven continual improvement we seek to continually
improve services, processes, technology, and management
architectures, tools, and measurement methods and metrics.
The biggest impact at the intersection of your ITIL
driven continual service improvement phase in DevOps
are the DevOps value of measurement, all the three ways,
lean and agile practices, the SRE role, and
blandeless post-mortems.
One key thing you can do at this intersection is to
amplify the feedback loops between BRM, strategy,
sprint planning, post-mortems, and continual improvement.
These interfaces have to exist and be effective
especially if run at a much greater pace than
prior to DevOps.