SPECIAL OFFER: ITIL® 4 Specialist: Monitor, Support & Fulfil (MSF) | 29 - 31 May 2024 | Live Virtual Class With Trainer | NOW £1395 + VAT (£100 OFF RRP) Learn more

ITIL® Vs. DevOps! 25 Influential Experts Share Their Insights (Is ITIL® Agile Enough?)

Posted by | Reviewed by | Last Updated on | Estimated Reading Time: 47 minutes

Over the years, and especially quite recently, there have been claims that ITIL® may have one foot in the grave and is rapidly becoming outdated, but how truthful are these allegations?

Technology is rapidly changing our world in unprecedented ways, and those who work in IT and other technology related fields have to keep pace with this rapid development. Are organisations who heavily invest in ITIL® in danger of becoming dinosaurs and losing the often essential agility that is required to keep pace nowadays?

Well, I contacted 25 experts involved in IT Service Management, DevOps, Agile and ITIL® to see what they thought on the subject, and what they believe the future of ITIL® and IT Service Management is.

The question I asked was this: Do you believe ITIL® and DevOps are compatible?

I received some great responses, all of which I detail later on in this article.

First, though, let's discuss whether new approaches to running IT services are making ITIL®, or certain aspects of it, obsolete and whether there's any scope to incorporate new practices and ways of working into your IT Service Management processes.

DevOps: The New Kid on the Block

So, as you probably already know, there's a new kid on the block in the IT world. That kid's name is DevOps. An often misunderstood little fella, DevOps is occasionally confused with something it's not.

You see, DevOps isn't a ‘thing'. It's not something physically tangible that you can grasp in your hands. It's not a set of tools or processes that you can use (though many excellent tools and methods have emerged out of the movement), and it's not a job title.

DevOps is a cultural movement and mindset. Its goal is to help bring teams together, traditionally development and operations, and break down the barriers that rigid compartmentalisation and a silo mentality produce. This type of cultural shift is helping to change the way in which we work together, bringing immense benefits to business.

I discuss what DevOps is and isn't, as well as its advantages in another article, but for now, let's just say:

DevOps: A movement by practitioners, for practitioners! Tweet This

Now, I have to be honest, and say that DevOps isn't really new. The concept has been about since at least 2008, but it's only in recent years that the movement has really started to become mainstream and gain traction, particularly in the enterprise IT world.

It's these shifts in thinking that have begun to raise, once again, the question of whether ITIL® is just too rigid a framework for modern IT operations. One that may possibly be on its last legs so to speak.

ITIL® vs. DevOps

There's a lot of planning and documenting involved in the various processes outlined throughout the ITIL® framework, with little mention, if any, of iterative or agile/lean thinking and approaches.

That said, the new ITIL® Practitioner offering from Axelos does reference DevOps and Agile approaches in a little more detail.

Some see the differences in how ITIL® and DevOps approach the managing of IT services as being at odds with each other, and while ITIL® has given much to the world of IT, it's time to move on and work faster and smarter.

However, there are others who believe that ITIL® can complement a DevOps approach, with the primary processes helping to improve and bolster such things as continuous delivery, deployment and automation. The same can be said for ITIL® helping to improve how DevOps practitioners work.

We'll get into the details of this later on in the post and as you'll see, many of our experts subscribe to this point of view.

If you think DevOps and ITIL® aren't compatible then you don't understand either. Tweet This

Another opinion is that depending on the particular needs of the business, both ITIL® and DevOps may have their place, albeit in separate working capacities, and it is up to the business to decide what approach is most appropriate for any given project.

With so much debate, how do you choose as a business which approaches to invest in, and how will you know you've made the right decision? Is it possible to combine the two?

Unfortunately, there's no straightforward solution to these problems, and with so many businesses and individuals already heavily invested in ITIL®, the move to something new may seem a little disconcerting.

Perhaps it's more appropriate, then, to help practitioners work in a more agile way, rather than completely replacing your ITSM investment. Something the new Certified Agile Service Manager (CASM) course from the DevOps Institute aims to address.

We'll discuss each position in further detail below, with the hope that you'll be able to make a more informed decision.

The problem many businesses will have, though, is the fact that in the fast paced world of IT and IT innovation, not moving with the times could be a disaster for your future operations, and you could end up becoming a bottleneck. Just look at Kodak for a case of not keeping pace with innovation!

Are ITIL® & DevOps Worlds Apart?

One view on the subject of ITIL® vs. DevOps is that they are at odds with each other.

The fundamental approaches, processes and terminology between the two are so different some believe, that they are not compatible and that ITIL®, while contributing significantly to the world of IT, is becoming outdated.

The main bulk of ITIL®'s framework was developed around 20 years ago, and the way we work and the ideas we have now are almost unrecognisable when compared to how we worked and the ideas and thoughts we had 20 plus years ago.

Many who believe that ITIL® and DevOps are virtually the antithesis of each other, point to specific ITIL® processes and procedures that appear, at least on the surface, to contradict each other.

For example, some state that the continual service improvement process is located at the end of a set of stages consisting of service strategy, service design, service transition and service operation. Some argue that such a waterfall-style approach does not fit well with today's fast paced IT operations that focus on lean, agile practices.

Another example that's pointed to is ITIL®'s key underlying narrative of planning, documentation and control. ITIL®'s reliance on well-defined, documented processes and procedures, with a focus on thorough planning and oversight mechanisms, seems to restrict its practical applications when comparing it with the more agile and experimental approach of DevOps practitioners.

Charles Betz has indicated that while configuration is important, and ITIL®'s insistence that it plays a central role is to be considered a good thing, the way that work often gets done nowadays (the use of source control and package management), coupled with large-scale infrastructure automation, does not align very well with how ITIL® views the problem.

The structured Configuration Management Database (CMDB) that traditionally underpins Service Management processes (something which is seen as “best practice” and somewhat of an industry consensus), is actually an unsettlingly complex, fast-evolving problem.

To some, there appears to be a stark contrast to the key tenants and terminology used within each approach, for example:

  • Planned
  • Process Based
  • Procedure Based
  • Documented
  • Waterfall/Sequenced
  • Iterative
  • Incremental
  • Collaborative
  • Experimental
  • Lean/Agile

The glaring differences in terminology and approach appear to raise legitimate questions when it comes to things like speed to market, minimum viable product and the ability to test the market as quickly as possible, especially when considering the ever rapid rate of innovation and new product offerings that frequently come to market.

Advocates of this position believe that it is an almost impossible task to retrofit ITIL® with newer methods and approaches such as DevOps, Lean and Agile, without an improvement to the core ITIL® structural model. Unfortunately, a rewrite seems unlikely, even though there are those who believe that ITIL® does require a significant rethink.

Are ITIL® & DevOps Complementary?

So, can ITIL® and DevOps complement each other? Is it possible to combine the two to produce something better than they would both be otherwise?

Well, many believe that this is a distinct and viable possibility and that DevOps has the ability to strengthen and expand upon the ITIL® framework to achieve better business outcomes.

By listing your key ITIL® processes and identifying where things break down, or where bottlenecks occur, you can obtain a better understanding of where DevOps might fit in best.

Methods and practices such as automation, closer collaboration and continuous delivery can be implemented to help alleviate the issues you may be facing and contribute to improving the release, change and configuration management ITSM process areas.

Closer collaboration between IT operations and development teams will enable the open exchange and transparency of vital information such as infrastructure and application data, improving on event management processes.

On the flip side, ITIL® already has some very well understood processes that could help strengthen how people approach and implement a DevOps cultural mindset and set of approaches.

ITSM practitioners can help with the transition to a more transparent and collaborative working environment by ensuring process areas such as event management, incident management, problem management and knowledge management are sufficiently modified to incorporate development.

(Click this link if you want to learn about our monitoring and event management course).

Those in support of this position point out that when customised and applied pragmatically, ITIL® processes can have a meaningful influence, not only on the business in general but on how you approach DevOps.

Others argue that the view that ITIL® is rigid and inflexible is either a misinterpretation of how the key processes work or indeed, the poor design and implementation of them.

A lot of businesses design and implement the ITIL® processes, never to revisit them, meaning they become unwieldy, or no longer meet the needs of the business.

In reality, some argue, ITIL® is very flexible and lends itself to an Agile environment. It's often terribly misunderstood, even by some so-called 'experts'. It's all down to a perception that ITIL® is rigid and uncompromising. They argue that you should adopt and adapt ITIL® to meet changing business needs.

There's an argument that ITIL® is iterative and on-going, despite often being misinterpreted. That as part of your adaptation and adoption of ITIL®, you have the flexibility to tackle and improve all areas of concern at once, if you have the required resource. You can also take an approach where you address specific pain points first.

These ideas seem to contradict the view that ITIL® is a phased, waterfall-style approach, and that it's the adaptation and implementation of the framework that is the key to its overall agility.

The Best Tool for the Job

As with numerous things in life, there are several ways to accomplish a task or approach a problem, often, though, it's about choosing the right tool for the job at hand.

Some thought leaders believe that, while ITIL® and DevOps are fundamentally opposed, it does not mean that an organisation cannot use both. It all comes down to the distinct requirements of the business and the project at hand.

On one hand you may require rapid speed to market and constant feedback, favouring a more agile approach, on the other, you may need to enhance stability and employ tighter controls, preferring the processes outlined within the ITIL® framework.

There's no one size fits all approach, and this actually does make a lot of sense when you think about it. As with anything in life, a single approach, cultural mindset or methodology will not work well in every situation.

So, look at what your organisation's business needs are and choose the approach which suits those needs best, even if that means combining several different frameworks and ideas.

What the Experts Have to Say

So, now it's time to present the expert insights on that simple question I posed:

Do you believe that ITIL® and DevOps are compatible?

Stephen Nelson-Smith

Stephen Nelson-Smith - Co-founder at Summerhouse Sounds

One of the main observations made by those who suggest that DevOps and ITIL are seen to be in opposition is that ITIL is optimised for safety and stability, at the cost of speed, whereas DevOps prefers to prioritise speed of delivery and rapid response, seeking to remove heavyweight processes that might impact velocity. However, I think that’s a radical simplification.

ITIL places a firm focus on the business of planning, documentation and control. Let’s look at how these interests are handled from a DevOps perspective.

Anyone running an operations team, and adhering to DevOps principles, is also committed to control, documentation, and planning. Complex IT infrastructures can only be maintained and improved with careful planning. However, that planning tends to be carried out with a focus - what is the minimum viable amount of planning we can do, so as to maintain confidence and security in the stability of our systems, yet also, make progress quickly.

Agile principles certainly tell us to favour working software over comprehensive documentation, and a DevOps-inspired operations group will tend to agree, but that’s not the same as rejecting documentation. In teams that I have run, I’ve introduced two principles of documentation. Firstly, the tests and the infrastructure code are the documentation. Looking at well-written Chef cookbooks, and a comprehensive server spec test suite should be more that sufficient to document ‘what’ and ‘how’. Secondly, documentation should exist to specify ‘why’. Why does the system work this way? Why does the system exist? I’ve found a combination of versioned, live infrastructure code, and versioned, live commentary on that code amply provides sufficient documentation.

Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s called a Chef server. Similarly, ITIL places a strong emphasis on configuration. Teams I have built do the same. All changes to the system are made in code, go through a peer review process, are automatically tested, and rolled out in a recordable, repeatable, and auditable manner. I encourage tracking of all changes that are made to the system. To do that, I use git and I track problems and resolution in a ticketing system. That could be Jira or Zendesk. When it comes to risk management, compliance, and security, again, I turn to the Chef ecosystem. Chef Compliance, as part of the Chef automation system, provides ways to specify compliance requirements as testable specification, which can then be used for audit and management.

So with respect to these ITIL principles, people I have trained, mentored or coached, and people who have worked for me, all have in common that they exercise iron control over their systems, maintain a responsibly minimal, but sufficient level of executable documentation, maintain their systems using configuration management software, and plan work to those systems in a focused but effective manner.

ITIL is also deeply concerned with continual service improvement processes. From a DevOps perspective, we implement that too. We call it Kaizen. Teams I have run operate to a cadence which permits regular weekly or fortnightly retrospectives. Any incidents are always responded to with honest and open retrospectives, and improvement actions are captured and tracked to completion.

So yes, I believe DevOps, done correctly, embraces the same interests that ITIL wants to protect. I believe a visionary, determined, and diplomatic leader can run their systems with a DevOps approach, informed by ITIL. I would suggest that anyone who claims to be ‘doing DevOps’, but who does not embrace the same interests as ITIL doesn’t really understand or embrace the interests of either.

DevOps, done correctly, embraces the same interests that ITIL wants to protect. Tweet This
Aale Roos

Aale Roos - Founder and Consultant at Pohjoisviitta

The need for new management concepts like DevOps and SIAM comes from deficiencies in current ITSM thinking. The ITIL® processes have no mechanism for inter-process coordination. ITIL® is very process oriented, value is not really understood, which can be easily seen when one looks at a list of recommended metrics for ITSM.

DevOps tries to bring better cooperation between development and production. The ITIL® framework can be seen as an obstacle course designed to prevent any development. If you doubt this, calculate how many processes there are between a customer requirement and its implementation. ITIL® fans keep saying that ITIL® needs to be adapted and adopted. If that means scrapping twenty processes, then it could work.

DevOps can be very useful if the business requires agile development of business systems.

DevOps can be very useful if the business requires Agile development of business systems. Tweet This

Kaimar Karu

Kaimar Karu – Head of ITSM at Axelos

The short answer is “yes”, the philosophical answer is “this is the wrong question to ask” and the long answer is “yes, and …”.

ITIL® is a framework for Service Management, covering the key organisational capabilities needed to deliver value to the organisation and its customers through fit-for-purpose and fit-for-use services. Many of the underpinning activities follow a similar (or same) model every time when executed, which is why these have been described as processes – to standardise and, when technology supports it, automate as much as possible, so that people can focus on value-adding activities.

Customer is at the centre of Service Management, and built-in continual service improvement ensures the Service Management capabilities keep up with the changing needs of the organisation.

DevOps as a movement and a philosophy looks at the flow of effort in the organisation in delivering the aforementioned value, with a focus on enabling collaboration across and beyond the organisation, and leveraging technology to make it real.

DevOps directly addresses the inefficiencies (non-communicating silos, missing focus on the customer, missing collaboration between teams, etc.) that have emerged, layer by layer, over time as a response to increasing complexity of the technological component of IT Service Management, and dissolves them to reveal skilled people who now – finally! – have the opportunity to do what they have wanted to do for decades. This is where the technology side of DevOps comes in handy – while most of the improvements required are about organisational culture and collaboration, the hardware being a commodity and the software supporting automating what needs to be automated allow people to focus on the human side of the equation.

The trick with getting the most out of ITIL® is to make sure the Service Management mind-set is adopted, and the guidance itself is adapted to the specific needs of the organisation. DevOps helps to make it happen and provides additional support for the “how” on the core concepts of Service Management – creating value through collaboration, with a focus on the customer.

DevOps as a movement looks at the flow of effort in an organisation in delivering value. Tweet This
Karen Ferris

Karen Ferris – Director and IT Service Management Expert at Macanta Consulting

I absolutely believe that ITIL® and DevOps are compatible. Since day one of conception, ITIL® has stated that it needs to be 'adopted and adapted' and in the world of DevOps that is still the case. The language used may be different but the outcomes are the same - delivering value to the business where it is needed. ING are an excellent example of how they have adopted ITIL® in a DevOps environment. 'Problems' equate to 'user stories'.

ITIL® has a strong focus on Continual Service Improvement which equates to the feedback loops of DevOps. The speed of those loops may need to be increased in the world of DevOps but the intent is once again the same.

I absolutely believe that ITIL® and DevOps are compatible! Tweet This
Jon Hendren

Jon Hendren – DevOps Thought Lord at JohnHendren.com

Being that ITIL® is a process framework and DevOps is a philosophy (with some nudging toward particular new technologies like infrastructure automation, etc.), there's nothing about ITIL® to make it inherently incompatible with DevOps and vice versa. But the idea that they're at odds is like an old wives' tale or a bad rumour in an email forward that resurfaces every so often. (By the way, Mars will be as big as the full moon in the sky tomorrow night, have you heard?)

ITIL® doesn't need to be ripped out of an org for DevOps to take hold. In fact, taking a good honest look at the bottlenecks in your org's current process is a great way for a lumbering enterprise to know where to get started. Tracking and monitoring everything-- project timelines, deploys, configurations-- will paint a huge red X on where to focus improving first. Then the cultural bits (destruction of silos, blameless post-mortems, shared responsibility) lead naturally into resolving those bottlenecks and even into getting started with automation tools.

I work at UpGuard (formerly ScriptRock; we monitor configurations and integrate with automation tools) and we see enterprises struggling to get started with automation every day. They've been sold on the prospect that automation is the alpha and omega of DevOps and attempt to jump directly to the end ideal state without examining their current infrastructures and processes first, and it more often than not winds up being a mess.

ITIL® is a framework and DevOps is a philosophy, nothing about them makes them inherently incompatible. Tweet This
James Turnbull

James Turnbull - Author, CTO at Kickstarter & Advisor at Docker - Karter.net

I'm too far removed from ITIL® these days. I suspect that the sort of companies who implement ITIL®, often do it for the wrong reasons and do it poorly. As a result, DevOps will always be in opposition to it. Actually, that might be a better thought: “If you think DevOps and ITIL® aren't compatible then you don't understand either.”

If you think DevOps and ITIL® aren't compatible then you don't understand either. Tweet This
Iam M. Clayton

Ian M Clayton - C-Level Strategist - Customer Centricity at Service Management 101 - Service Management University

The modern workforce spans five generations from ‘Baby Boomer', to ‘Generations X, Y, Z', and Google's new Generation C, representing what they call the ‘YouTube Generation'.

Each generation brings with it a certain culture and set of needs and expectations. Both ITIL® and DevOps are powerful and important movements borne out of the needs of these generations.

ITIL is largely a result of the post-war ‘Baby Boomers', and the need for predictable production rates. It has historically been used to establish and refine the processes and mechanics required to manufacture (deliver) a product – a service. It is predominantly ‘inside-out' and macro, infrastructure-centric in its thinking and approach, and grounded in the partitioning of responsibility and work effort around ‘processes'.

DevOps has emerged to meet the needs of more recent generations, where the focus has shifted to the modern enterprise and the digital consumer. It is the high-speed ‘autobahn' to production, and when adopted offers a ‘just enough', highly automated approach to the mechanics, using organic team structures, and matching the pace of delivery with the speed of business. To survive and make meaningful development decisions, DevOps has adopted a predominantly micro, ‘outside-in' or customer centric view.

Frankly, the DevOps movement doesn't need ITIL to succeed. The same can't be said for ITIL. ITIL needs to be perceived as useful to the DevOps movement for its relevance to be sustained, and where DevOps is a management imperative, for its supporters and adopters to succeed.

Many are asking if these two movements are ‘compatible' and able to co-exist and co-operate without conflict, given today's management imperatives.

Well yes, they are, or rather should be, but this may well depend heavily upon what bridgework is offered as part of the new ITIL Practitioner course and certification. DevOps is a fast moving phenomena. ITIL has a tendency to move at a glacial pace. The gap between the two is expanding.

Although it's not a primary focus, I'm hoping the ITIL Practitioner recognizes the specific gaps between the movements and sets of thinking, their contrary imperatives (speed versus stability), and closes these with practical guidance. Else, I suspect the perception of conflict and incompatibility will become more tangible, and grow.

One last point, both ITIL and DevOps suffer from the lack of specificity around key organizational considerations, and how the need for needs based collaboration is established and sustained. For many agile thinking folks, ITIL introduces unnecessary friction and the demand is for a ‘lite' version. For ITIL followers, DevOps de-emphasizes internal rigor and the importance of processes, process ownership and the work partitioning ITIL prefers.

Whether they are compatible or not, or enough, may well rest on how the next wave of ITIL learning is presented, and absorbed.

ITIL and DevOps compatibility will rest on how the next wave of ITIL learning is presented/absorbed. Tweet This
Liz Keogh

Liz Keogh - Independent Lean and Agile Consultant

One of the original principles of the Agile Manifesto was that “working software is the primary measure of progress”. For small teams who owned their own servers, that was easy enough. For the enterprise, though, it's harder. Developers don't have as much autonomy, which means they're less motivated to build out their skills. Budgets are allocated between different functional silos, which means it's hard to even get the servers in the first place; there are all kinds of gates in the way.

DevOps is a really great start. It puts all the technical members of the team together, and it means that the business isn't just learning to trust development; they're learning to trust IT. They're learning that not only can they steer the direction of progress, but they can get that progress earlier, and get feedback from real users. We tend to think of DevOps as bringing huge technical benefits, but it's the business benefits and the increase in trust that really matter, as always.

It's only a start, though. Ops aren't the only silo in an enterprise organisation. To be truly Agile, all the fences have to go - between Dev and Ops, of course, but also between the business and IT; between IT and the people responsible for compliance; between Support, R&D, HR, Marketing, senior leadership... all of it. To bring those fences down all at once would invite chaos (which might be a good thing if the change is urgent and the business is small enough), but otherwise, you have to work out what fences to bring down first. That's the real key to successful Agile adoption. Here's the thing; it might not be the one between Dev and Ops. I've become known in the DevOps space, but it's only because I was trying to bring down fences, and that's an easy one. It isn't necessarily the most important. So if you've got DevOps, great! Start looking for the next fence. You're not done yet.

I think DevOps is an amazing movement, and I'm glad to see others jumping on the bandwagon. It's pretty much always a good thing. It's about relationships and people, though, and not about Jenkins or Puppet or any other tool... unless those tools are there to support those relationships. That's still the most important part of DevOps, and always will be.

I think DevOps is an amazing movement, and I'm glad to see others jumping on the bandwagon. Tweet This
Andrew Clay Shafer

Andrew Clay Shafer - Senior Director of Technology at Pivotal

ITIL® the ideological framework could be, ITIL® the vendor-driven codification of practice most probably is not.

DevOps may fit with ITIL's ideological framework, the vendor-driven codification of practice may not. Tweet This
Matthew Skelton

Matthew Skelton - Co-founder and Principal Consultant, Skelton Thatcher Consulting

In short, yes – there are many areas of overlap for DevOps and ITIL®. However, I think we need to recognise that there are many versions of ‘DevOps' in use and many incarnations of ITIL®.

At its heart, ITIL® has many essential practices and approaches for managing IT services, particularly the concept of Continual Service Improvement (CSI) via learning and feedback from each aspect of Service Management; sadly, too many organisations – including some “doing DevOps” fail to build in opportunities for learning and instead see software delivery as a one-way process, and even harm feedback by not setting up the service desk team to identify repeating problems.

In an effective DevOps organisation, we also see continual improvement of software services from feedback, but with the timescales radically shortened compared to more traditional IT shops; again, sadly some organisations have come to see DevOps as essentially just modern SysAdmins or infrastructure engineers rather than a holistic approach to building and running better software systems, failing to apply decades of learning from IT Service Management.

Done well, DevOps and ITIL® have much in common; people doing DevOps can learn important lessons from ITIL® (service dependencies, SLAs, service strategy, etc.) and people running ITIL® for Service Management can learn a huge amount from DevOps (modern monitoring & metrics, logging, incident response, team collaboration, etc.). The crucial thing is for people to understand why they are using DevOps and/or ITIL® within the organisation and which aspects they need to improve.

Done well, DevOps and ITIL® have much in common Tweet This
Jayne Groll

Jayne Groll - President of ITSM Academy and Board Member of the DevOps Institute (DOI)

Since DevOps came on the radar, there has been much debate about ITIL’s ongoing relevance in a DevOps environment. Some suggest that ITIL has passed its prime and is an out dated framework designed for waterfall service lifecycles. The modern IT environment expects processes that support transformational initiatives and enable rapid agile development, continuous delivery and stable operations.

I strongly believe that the core ITIL and ITSM guidance and processes are and will remain relevant. Customers will always require services and services will always need to be managed. However, how services are managed in an “app mentality” world will require a more modern approach to service management. One that takes the basic spirit of ITIL and instills agile thinking so that processes are more adaptive and fluid under different circumstances. Nowhere in 2000 pages of the ITIL library is there a single suggestion that ITSM processes should be difficult to follow and bureaucratic.

ITSM should therefore take a lesson from Dev and evolve service management into agile service management. What does that mean? It means cross-breeding ITIL with Agile and Lean concepts so that we learn to prize the outcomes more than the artifacts. To focus as much on the value stream as on the service lifecycle.

DevOps does not diminish the value of ITIL – it validates and matures it. Most importantly, DevOps finally connects the dots between ITIL, Agile, Lean and a host of other IT methods, frameworks and automation across the IT spectrum. It’s been a long time coming.

DevOps does not diminish the value of ITIL – it validates and matures it. Tweet This
Matt Beran

Matt Beran – Thought Hacker at Kinetic Data

Innovative professionals look for best practice guidance in many forms and from many places.

Don't go all-in on any framework or any wisdom without a clear understanding of your goals, measurements toward those goals, a roll back plan and a culture that will support the members.

Only then will you find what works for your business, and what best practice to keep.

Once you find what works, keep those measures going and perform a regular review of what best practices are coming and which are losing value (for you).

Don't go all-in on any framework or any wisdom without a clear understanding of your goals. Tweet This
Rob England

Rob EnglandThe IT Skeptic and Managing Director at Two Hills Ltd

I'm old and stubborn: I'm sure the message has been staring me in the face. Never mind, I make no apologies here. Strong ideas survive and thrive in the face of opposition: they grow stronger fighting the headwind. There are more bad ideas than good ones - we should always test. I arm-wrestled DevOps and DevOps won. No, that doesn't mean I have embraced DevOps as the answer to all the world's ills. It means I have seen that DevOps stands up to tough interrogation, it has substance. DevOps and ITSM intersect, they fit one model, they can be reconciled - we need to find the common ground. Not the same thing.

DevOps stands up to tough interrogation, it has substance. DevOps and ITSM intersect. Tweet This
Althea Champagnie

Althea Champagnie – Senior Content Developer at Microsoft - About Althea

I do believe ITIL and DevOps are compatible - the language both use to define the change management and release processes may be different, but the goals are the same. ITIL may seem slower and rigorous, but it's really just a framework that can be modified as needed to fit a faster DevOps culture. We need ambassadors to connect the two distant cousins, but compatible? Yes, definitely.

ITIL is a framework that can be modified as needed to fit a faster DevOps culture. Tweet This
Dave van Herpen

Dave van Herpen – Management Consultant at Sogeti - Dave's Blog

Although ITIL® is something very different (a framework) from what DevOps is (a mindset), I strongly believe they share a lot of values and principles.

Given the recent additions to ITIL®, using the 9 Guiding Principles in ITIL® Practitioner, I believe that the traditional ITSM toolbox (which ITIL® definitely belongs to) is slowly moving towards the end-to-end agile mindset which the DevOps philosophy aims to deliver. Both ITIL® and DevOps promise to deliver optimal value to customers, it's all a matter of applying the available practices with (common) sense.

ITIL® is something very different from what DevOps is, I strongly believe they share a lot of values. Tweet This
Andrew Hay

Andrew Hay – CISO at DataGravity, Inc.

In my opinion, the organisations adopting ITIL® are typically mature and extremely organised entities whereas the DevOps mindset tends to flourish in smaller, leaner, and more recent organisations. There are obvious exceptions, but in my experience, I've seen DevOps-leaning organisations be less concerned with process, procedures, and measurement of actions and far more concerned with speed, agility, and scale.

ITIL® organisations are usually mature, while a DevOps mindset tends to flourish in smaller teams. Tweet This
Sean Hull

Sean Hull - Scalability & Performance Consultant at AppNexus - Scalable Startups

For me DevOps is at once about two things. Technically it involves infrastructure as code, configuration management and automated tooling, deploys and continuous integration. On that front, I do see organisations adopting DevOps to become more agile and responsive to the market.

The other half of DevOps is a collaborative approach in your process, allowing development and operations to collaborate more easily, without the siloing you see in traditional organisations. This part seems to have a slower learning curve. I still see a lot of "we don't need operations" and many startups where it's all about features and dev.

I do see organisations adopting DevOps to become more agile and responsive to the market. Tweet This
Vagelis Tzellas

Vagelis Tzellas - Project Manager T&T UKI & NORDIC & DACH

Yes, I believe they are compatible when used for a specific purpose, on a case by case basis.

I believe ITIL & DevOps are compatible! Tweet This
Christopher Isak

Christopher Isak – Founder, TechAcute

These methodologies are definitely compatible. They have different focuses and objectives, so I think they are no competition to each other.

I also believe that there should be an additional focus on the management of projects next to managing operations and services. Of course, every organisation is different and the implementation details may vary, but there is a great potential value add when leveraging more than one methodology.

Regardless of which and how many practices you want to adopt, make sure to work on culture and awareness, not only on strategy. The best methodology won't help you, if nobody adheres to it.

Work on culture and awareness, not just strategy. Methodology won't help if not adhered to. Tweet This
Joe McKendrick

Joe McKendrick - Author, Independent Researcher and Speaker - Service Oriented

I see no fundamental contradiction or issue between ITIL® and DevOps.

ITIL® is designed to introduce service-thinking within IT development and deployment in a methodological and disciplined way. If anything, IT managers and professionals with ITIL® certification are better equipped for the rapid iteration and delivery of IT assets in a collaborative way.

Every business is becoming a software business, and thus will be looking to move solutions, updates and capabilities to internal and external customers quickly and with the highest possible quality. DevOps paves the way, but it takes a radical re-thinking of IT workflows and management. ITIL® opened the doors to such a re-alignment.

DevOps paves the way for a radical re-thinking of IT workflows. ITIL® opened the doors. Tweet This
Roy Atkinson

Roy Atkinson - Support and Service Industry Analyst, Writer, Speaker - HDI

First, let's be clear: ITIL®, a Service Management framework, is not the same as Agile, the methodology applied in software development, project management, and increasingly in other areas of business.

If we go back to the Agile Manifesto, some elements appear to completely contradict tenets of ITIL®, such as valuing, “responding to change over following a plan”.

What needs to be said, though, is that Agile methodologies do not advocate for knee-jerk responses and “Wild West” behavior; the goal is always to produce value through iteration and focus. A well-tended Service Management road—levelled, for example, by responsive change management practices—can help to expedite the goals of Agile methods.

In practice, however, many organisations that believe they are ITIL®-focused value process over individuals and rules over responding; there are also some “Wild West” Agile behaviours.

DevOps and ITIL®-based Service Management can dwell in the same house, but the commitment must be to producing value, not advancing an adopted philosophy. Too often, we see organisations wrap themselves in the name but follow neither the spirit nor the letter.

DevOps and ITIL®-based Service Management can dwell in the same house... Tweet This
Julian Simpson

Julian Simpson - Software Engineer at Neo Technology - Build Doctor

I'm not an expert on ITIL®, and ITIL® is broad and deep in scope, so any answer is going to be a massive generalisation, but I have a few observations to make:

Religiously following the prescriptions of a methodology may or may not help you depending on your experience, team and context. If you were to stick to chapter and verse on ITIL®, you might find things that don't fit well with a DevOps mindset, or you could try to find common ground.

Not following ITIL® at all would have very few consequences in a 2-person start-up that write mobile apps. That same decision could have terrible consequences for a 1000-person insurance company.

What matters is that the organisation is designed in such a way that all the departments and groups have aligned goals (e.g. both dev and ops have responsibility for uptime, or cross-functional teams do dev and ops work), and that there's trust between people.

To reiterate what Jez Humble and Dave Farley discovered, you can pre-approve changes so that a team can deploy code fixes without going through the Change Advisory Board. Just saying.

What matters is that an organisation is designed in such a way that all groups have aligned goals. Tweet This
Charles T. Betz

Charles T. Betz - Digital Thought Leader - Lean4IT

They are not incompatible per se. The industry needs a more comprehensive way of thinking about product, process, and project.

The industry needs a more comprehensive way of thinking about product, process, and project. Tweet This
Steve Whelan

Steve Whelan – ITIL® Expert & Trainer - Purple Griffon

Obsolete, no. It is impossible for it to become obsolete as the processes are universal and timeless (that is not to say that they are described well though). Outdated - yes, it is such a big undertaking that it is pretty well outdated as soon as the books are published.

There basically isn't anything in DevOps which isn't in ITIL®. DevOps is basically more about how-to-do, ITIL® more about what-to-do. It is impossible for them not to work together, they're both saying the same things.

I'm hoping that we can stop talking about IT Service Management and just talk about Service Management, which is universal and timeless.

As far as processes go DevOps is really a subset of ITIL®, so which processes map well - all of them that DevOps actually talks about.

Well ITIL® would have to improve itself first really. e.g. recognise that it is Service Management and not IT Service Management, the Government would need to recognise that they can't "own" these processes.

Hopefully the buzz that is in DevOps due to its community involvement can spread into ITIL®.

As far as processes go DevOps is really a subset of ITIL®! Tweet This
Andreas Grabner

Andreas Grabner – Technology Strategist at Dynatrace

DevOps for me is the Continued Revolution that Agile Development started years ago - but now gets applied and extended throughout the whole organisation and into the complete Value Delivery Pipeline. For me DevOps is about empowering individuals, fostering collaboration, automation of tasks along the delivery process and eliminating obstacles and road blocks such as rigid, old established processes and artificial organisational hierarchies.

The key to all of this is to apply this with “common sense” - such as ITIL® was initially intended when Don Page said “Document Common Sense”.

I can see that there is a co-existence where necessary. The ultimate goal is to deliver better service to your end users in a reliable way. As every IT organisation is different I believe that we will not only see the “DevOps Purists” but also see “Best of both worlds adoptions” to achieve that goal.

The key to all of this is to apply this with “common sense” - such as ITIL® was initially intended! Tweet This


As you can see from the expert opinions detailed in this article, there is overwhelming support for the idea that, while different in what they are, ITIL® & DevOps are very much compatible, and if you find that they aren't compatible then you haven't deployed them correctly.

I'd like to thank everyone that took the time to contribute to this article with their expert insights, we had some amazing contributions. These insights are an essential part of the overall conversation, so let's help get them out there even more by sharing them.

More importantly, though, what do you think? Are ITIL® & DevOps compatible? I would love to hear what you have to say in the comments below.

About The Author

Steve Lawless

Steve Lawless

I've worked in IT for over forty years and spent the last twenty in training and consultancy roles. Since starting Purple Griffon in 2002 I've taught over three thousand individuals in a variety of subjects. I hold qualifications in all four versions of ITIL®, ITAM, UX, BRM, SLM, SIAM, VeriSM, and AI, and co-authored the BCS AI Foundation book. Outside of work, I enjoy skiing (or rather falling over at high speed), reading, science and technology, and spending time with my loved ones.

Tel: +44 (0)1539 736 828

Did You Find This Post Useful?

Sign up to our newsletter to receive news about sales, discounts, new blogs and the latest IT industry updates.

(We will never share your data, and will never spam your inbox).

* Fields Required