DevOps and ITIL are like oil and water to many pundits. Some people hold that the two cannot coexist in today’s modern-day IT shops, advising companies to move away from ITIL as they start embracing the DevOps movement. I argued against this recommendation in a post called Unicorns, Horses, ITIL, and Enterprise DevOps.
Before anyone recommends that a client throw out ITIL, we should understand what business benefits ITIL provides:
In my opinion, the only one of these benefits that mature ITIL shops struggle with is “Support business change at the speed your customer needs.” Instead of throwing out ITIL and losing all of these benefits at the expense of speed to market, why not fix the speed to market issues within ITIL?
I think the real problem people have with ITIL stems from their own personal experiences of ITIL’s having been poorly implemented within the organizations they have worked with. I have had some horrible experiences with agile implementations in my past life. That does not mean that agile is bad. It means that the companies I worked at that had implemented agile had no clue what agile really was. Poorly implemented process, whether it is based on ITIL or something else, will definitely hinder any DevOps initiative. But let’s not blame ITIL for that.
I am currently working with two large organizations that each have a very mature ITIL implementation. They are seeking our help regarding how to embrace DevOps. They both have what I consider a successful ITIL implementation and are extracting business value from it. The challenge before them is that their current implementation of ITIL gets in the way of their continuous integration and continuous delivery processes. Does that mean we should throw out ITIL? Heck, no. It means we should modernize our ITIL workflow to accommodate the new way IT is delivering software. ITIL is known for having gates, reviews, and decision points that can cause a software development life cycle to start and stop, often while waiting for meetings, reviews, approvals, etc. Now more than twenty-five years old, ITIL was originally designed when waterfall SDLCs were in style. What we are doing for our client is abstracting away those gates and handoffs and providing ITIL as a Service.
ITIL as a Service
Say what? No, there is no magic ITIL API, nor a blue pill to take. Instead, we have reviewed all of the manual gates and have figured out ways to automate them. Some of these gates are automated in our continuous integration (CI) and continuous delivery (CD) processes. We have built sophisticated logging and monitoring frameworks that integrate with many services within the service catalog (e.g., change management, problem management, incident management, release management, etc.) The build process runs code scans, security scans, and performance tests, and it automates many of the processes that formerly required meetings, reviews, and work stoppage. Areas like SLA management and performance management can become largely automated with the use of modern monitoring tools and automated event management tools. We are leveraging APIs from our monitoring, logging, event management, and dashboard technologies to feed our service desk software, so that our support staff can get a single view of the world from their existing tools and processes. We are automating onboarding processes that auto-approve requests where possible and provide visibility and escalation processes for the approvals that cannot be automated.
Self-Service
Self-service portals provide standard blueprints that developers can choose for launching VMs in non-production environments. This allows developers to experiment without getting held up by the process. Behind the scenes, we can automatically update the service desk, so that the creation of automated infrastructure can be tracked for auditing and billing purposes. Developers have logins to APM tools and central logging tools, and they can build their own dashboards with tools like Graphite once they are enabled with access to data about the systems. This can all be done without granting access to physical servers, which keeps the auditors, security team, and risk and compliance team happy.
Summary
Moving to a DevOps model should not require enterprises to throw out their existing processes. Instead, enterprises should look at how they can automate as much of their existing processes as possible, so they do not get in the way of modern-day software development practices such as CI/CD. If an enterprise has poorly implemented processes, then it may be worth looking at new approaches. But if its current processes are providing business value, the goal should be to continuously improve these processes in order to keep up with the modern development practices.