Speaking recently at an event in Europe, I was approached by a developer who explained that ITIL was ‘killing’ innovation in their company. I asked him how they were continuing to deliver innovation and he said they “implemented a methodology called “NoOps!” I immediately felt my governance senses tingling, but rather than rush to judge, I waited for further details. I asked him what the difference was between DevOps and his NoOps, and he replied “not much, but we feel better believing there is no operations involved.”
But there is a difference. Let me explain.
The rush to increase the pace of change and release automation, especially with the rise of mobile computing, is accentuating the popularity of continuous release or DevOps. Agile development methodologies that help better align IT with business expectations have been further accelerated by the acceptance of mobility and apps for business.
Think about it for a moment. The app that you are using on your smartphone or tablet is rapidly developed, tested and released to production (and in many cases today, immediately updated) with no human interaction. It stands to reason that, as releases become more frequent and the changes within them smaller, we should automate the processes across development, test and production. And should we need to back out a change, we can even automate a backup before the change is applied.
Now in the old-school ITIL world, the change process encumbers the developer moving code to production. Why wait for the next Change Advisory Board meeting (CAB) when the risk and impact of the change to the business is low?
Enter DevOps.
DevOps is not a standard or a framework; it is a philosophy of merging development and operations, something that we have been attempting for years. DevOps extends agile from methodologies long practised in development to achieve continuous operations.
When implemented effectively, DevOps completes the continuous integration and release process across the testing and pre-production environments into the operational realm. This has the advantage of giving the whole cycle of development and transition to production complete transparency, from the approval of the work request to delivery and use. Unlike in the traditional ITIL world where a completed change is thrown over the fence to the operations function, a key DevOps advantage is that code is promoted as soon as it’s developed, verified and tested. And since deployments don’t pile up, complexity and risk of failure are minimized. The smaller the change, should it fail, the more likely the area of impact is known and can be resolved or backed out and service restored.
An all-to-frequent implementation error with IT Service Management is the assumption that all change is created equal. But all change is NOT created equal.
For example, a major ERP system upgrade that will impact the very core of your business is a change that would be deemed an extreme risk to the organization. It requires more diligence and a meeting of all concerned, including impacted stakeholders, prior to production (the Change Advisory Board) might be a great idea!
Compare that scenario to changes for new and innovative services such as updates to mobile apps that happen on a regular basis, or the implementation of innovative solutions or experiments.
The difference between those two scenarios illustrates that there are multiple channels to production, with different levels of risk and varying degrees of impact from the changes involved. In some cases DevOps is the best approach (continuous change), in others a traditional Waterfall approach makes sense.
Within the service management world, many strive to implement all changes with 100% success, but the reality is that some change will fail for a variety of reasons. A key tenant of service management has been continual improvement, and this is where we have an opportunity – based on our experience we can learn from these failures that occur from time to time. A small number of steps in any process are easier to deliver with quality and within a DevOps cadence; start small and you should be able to deliver a higher rate of throughput and, more importantly, success.
Many development organizations are leveraging a DevOps philosophy, yet operations have been slow to do so. In my opinion, DevOps offers operations a significant opportunity to rapidly remove work and activities that they should not be focusing on, and instead allow them to focus on what really matter.
More importantly, the removal of the age-old boundaries between operations and development is essential to help the business thrive in the application economy – a core objective for most businesses today. That said, it’s not about removing rigour or returning to times of IT being consistently unavailable. DevOps executed effectively should increase rigour and structure, typically around process automation, while enhancing compliance at the same time. For instance a given change can be automatically populated, its risk determined, and the automated audit checkpoints written to the automated backup of the production environment before the change is actually pushed to production.
So as you think about your current investment in good service management practices, DevOps doesn’t necessarily mean the death of ITIL, but it does signal a change in how operations operates. Implementation of a DevOps philosophy will require organizations to review their ITIL change and release management processes at a minimum, leveraging automation to streamline process while at the same time delivering the compliance required in many industries today, such as healthcare, finance and insurance.
A common complaint I hear about is resistance from some in the current Service Management organization. In working with those who are resistant, you should communicate the value of their roles to the business as they transition to focus on value – adding process such as proactive problem management or paying more attention to traditional organizational change where the risk and impact to the business are high.
DevOps adoption is not signaling the end of ITIL, nor is it about abandoning current investment in process. Rather, it is more akin to upgrading your approach in a way that drives enhanced value to your organization.
Remember – as I say to myself everyday – IT serves the business, and those are the people who pay our salaries. In short, if IT can’t deliver, the business will go elsewhere!
Robert Stroud
A recognized industry thought leader, speaker and contributor to multiple best practices and standards, consistently thinking "outside-the-box" to communicate and drive business transformation for organizations globally. Currently leading the research on DevOps to fuel Business Transformation delivering industry-leading research leveraged by organizations globally.
