patternMajor
Is DevOps compatible with ITIL?
Viewed 0 times
withdevopsitilcompatible
Problem
In my career, I have been both a software developer and ITIL practitioner in an operations role. Thus DevOps was a natural progression for me.
However, I have always struggled with the highly specialised language that ITIL introduces and making that "Developer Friendly" enough to not be a complete turn off to developers.
ITIL is an internationally recognised IT Service Management framework that has been developed over 30 years as a set of practices that have a proven benefit to the operational stability and maturity of an organization.
Is DevOps truly compatible with ITIL, or in essence do we need to take the spirit of ITIL and "translate" it to language that is better understood by development teams:
However, I have always struggled with the highly specialised language that ITIL introduces and making that "Developer Friendly" enough to not be a complete turn off to developers.
ITIL is an internationally recognised IT Service Management framework that has been developed over 30 years as a set of practices that have a proven benefit to the operational stability and maturity of an organization.
Is DevOps truly compatible with ITIL, or in essence do we need to take the spirit of ITIL and "translate" it to language that is better understood by development teams:
- Incident & Problem Management → Production Defects, Bugs or Issues
- Change & Release Management → Continuous Delivery
- Event Management → Logging, Telemetry, Instrumentation and Alerting
Solution
In my opinion, the DevOps culture come along with a methodology change toward Agile process management.
ITIL is heavily aimed at a clear formalism of the process and the results and thus more adapted to a Waterfall model.
This doesn't mean ITIL is incompatible with Devops, but usually this will be two separate process with different timelines.
I mean that the inclusion of a new product within ITIL referential will usually be delayed until the product/application has been released in production for a while, where early pitfalls and some documentation needed to integrate ITIL has been done and adapted after the product is "live".
One of the thing in ITIL is the Service Design, which is assumed to be defined before any development task, an agile process will/may review the design in each iteration, breaking the formalism needed in an ITIL process.
The main goal of ITIL is, as you said, to provide a framework to ensure nothing is omitted between the design/conception and maintenance phase (Build/Run). In a devops culture, the whole team is responsible of all phases on long term, hence why the formalism is reducted.
That doesn't mean we have to forget ITIL, the core principles are absolutely good and, in my opinion, should be used as a checklist to build the initial backlog of a product.
It's just that following the ITIL principle with all its formalism goes against the time to market reduction goal of a quick iterative software development and sometimes is not even applicable as there's less transmission of information needed between teams, as the tasks are done by the same team.
ITIL is heavily aimed at a clear formalism of the process and the results and thus more adapted to a Waterfall model.
This doesn't mean ITIL is incompatible with Devops, but usually this will be two separate process with different timelines.
I mean that the inclusion of a new product within ITIL referential will usually be delayed until the product/application has been released in production for a while, where early pitfalls and some documentation needed to integrate ITIL has been done and adapted after the product is "live".
One of the thing in ITIL is the Service Design, which is assumed to be defined before any development task, an agile process will/may review the design in each iteration, breaking the formalism needed in an ITIL process.
The main goal of ITIL is, as you said, to provide a framework to ensure nothing is omitted between the design/conception and maintenance phase (Build/Run). In a devops culture, the whole team is responsible of all phases on long term, hence why the formalism is reducted.
That doesn't mean we have to forget ITIL, the core principles are absolutely good and, in my opinion, should be used as a checklist to build the initial backlog of a product.
It's just that following the ITIL principle with all its formalism goes against the time to market reduction goal of a quick iterative software development and sometimes is not even applicable as there's less transmission of information needed between teams, as the tasks are done by the same team.
Context
StackExchange DevOps Q#213, answer score: 26
Revisions (0)
No revisions yet.