Let’s get this straight. ITIL is not about implementing dozens of processes, or about establishing a CAB to review every change request, or about the never-ending story of creating a CMDB. The ITIL framework has been designed to help IT organizations to move from being a black box technology provider – often viewed as a disposable cost centre – to becoming a service provider, and a true partner for the rest of the business. We know – we own the framework. Unless your customer can achieve their objectives with the technology you run, and can get assistance when needed, no-one cares whether your architecture is built on a monolith, uses microservices, or can brag about being serverless. Agile as a mind-set covers the whole value chain, but common practices are limited to development only. DevOps as a philosophy covers the whole value chain, but common practices are limited to the deployment-focused intersection of development and operations only. Understanding the organisation's strategy, developing the product strategy, and dealing with customer issues are expected to be taken care of by someone else, as if by magic. Because of this, DevOps faces a risk of becoming the largest local optimisation exercise ever undertaken for way too many organisations In tens of thousands of companies around the world, ITIL has helped to develop an organizational capability that has provided them with a competitive advantage. More than three million people have been certified, and ten times as many trained over the years. Yet, we have all heard the horror stories, too. So what is it that separates a successful adoption of ITIL from an unsuccessful attempt at implementing the framework? What are the common problematic practices and anti-patterns we have seen in the wild, and what does the guidance in ITIL really say? How can you move from a broken approach to IT Service Management to one that delivers value. Can you still use ITIL in the DevOps world? Do you even need to? Or, perhaps, the questions is whether DevOps can survive (in the enterprise) without embracing the service mind-set.

1. ITIL. You keep using that word.
I don’t think it means what you think it means.
Kaimar Karu
Head of Product Strategy
and Development, AXELOS
@kaimarkaru

2. 何不食肉糜？
A P P R EC I AT E T H E C O N T E X T
@kaimarkaru

3. A P P R EC I AT E T H E J O U R N E Y
@kaimarkaru

4. P R O C E S S M A N AG E M E N T
@kaimarkaru

5. C U STO M E R VA LU E
?
@kaimarkaru

6. L AC K O F C O L L A B O R AT I O N
No!
@kaimarkaru

7. C O M M O N A N T I - PAT T E R N S
» By-the-book ITIL ‘implementations’
» Ideal world process documentation
» Expensive ‘Level 5’ maturity projects
» ‘Watermelon’ SLAs
» CAB used as ‘Change Approval Board’
» Search for the silver bullet
@kaimarkaru

8. D E F I N I N G S E R V I C E S
„A means of delivering value to customers by
facilitating outcomes customers want to achieve
without the ownership of specific costs and risks.“
@kaimarkaru

9. T H E F LO W O F S E R V I C E M A N AG E M E N T
» Strategy: who are the customers
and what services they require to
solve their problems
» Design: how should the services
look and feel like, and what
capabilities are needed to provide
them
» Transition: how to develop, test,
integrate, and release services
» Operation: how to support live
services, and how to provide a great
customer and user experience
@kaimarkaru

10. S E R V I C E M A N AG E M E N T
$
@kaimarkaru

11. S E R V I C E M A N AG E M E N T A N D D E V O P S ( T R A D . )
Service
Design
Service
Transition
Service
Operation
Service
Strategy
Product
Architecture
Deploy
Product
Strategy
Continual Service Improvement
Prioritize and
Develop
Build and Test
Service
Management
Software
Development
Delivering
value
rapidly
and
continuall
y
Continuous Integration Continuous Deployment
Considered to be missing
More harm than good
@kaimarkaru

12. I T I L A N D T H E T H R E E WAY S O F D E V O P S
@kaimarkaru
Service Strategy
Service Design
Service Transition
Service Operation
Business Relationship Management
Demand Management
Service Portfolio Management
Service Level Management
Availability Management
Capacity Management
Change Management
Release & Deployment Management
Configuration Management
Incident Management
Problem Management
Request Fulfilment
» Flow
» Feedback
» Experimentation and learning

13. O P E R AT I O N S AS A P L AT FO R M
Service
Design
Service
Transition
Service
Operation
Service
Strategy
Product
Architecture
Deploy
Product
Strategy
Prioritize and
Develop
Build and Test
Continuous Integration Continuous Deployment
PLATFORM SERVICES
Security
Quality
Continual Service Improvement
@kaimarkaru

14. I T I L G U I D I N G P R I N C I P L E # 1
» All activities must deliver customer value
» The customer determines what is of value
» Not all ‘improvements’ deliver value
FOCUS ON VALUE
$
@kaimarkaru

15. I T I L G U I D I N G P R I N C I P L E # 2
» Understand the interactions
» Walk a mile in your customer’s shoes
» Empathy is the key
DESIGN FOR EXPERIENCE
@kaimarkaru

16. I T I L G U I D I N G P R I N C I P L E # 3
@kaimarkaru
» Understand the vision and the direction
» Seek out the value in what you have
» Leverage what already exists
START WHERE YOU ARE

17. I T I L G U I D I N G P R I N C I P L E # 4
» Organizations are complex systems
» Value is co-created through interactions
» Local optimization != value
WORK HOLISTICALLY
@kaimarkaru

18. I T I L G U I D I N G P R I N C I P L E # 5
» Avoid ‘big bang’ change initiatives
» Keep each improvement manageable
» Keep delivering value, continually
PROGRESS ITERATIVELY
@kaimarkaru

19. I T I L G U I D I N G P R I N C I P L E # 6
» Understanding context is important
» Direct observations trump reports
» Going to the source kills assumptions
OBSERVE DIRECTLY
@kaimarkaru

20. I T I L G U I D I N G P R I N C I P L E # 7
» The unknown is scary
» Missing information is replaced by myths
» Transparency creates supporters
BE TRANSPARENT
@kaimarkaru

21. I T I L G U I D I N G P R I N C I P L E # 8
» Understand the end-to-end flow
» Work with your customers and users
» Manage your stakeholders
COLLABORATE
@kaimarkaru

22. I T I L G U I D I N G P R I N C I P L E # 9
» Minimum Valuable Process
» Minimum Valuable Procedure
» Minimum Valuable Reporting
KEEP IT SIMPLE
@kaimarkaru

23. I T I L G U I D I N G P R I N C I P L E S
@kaimarkaru

24. W W W . A X E L O S . C O M@kaimarkaru
Thank you!