Introducing DevOps where ITIL rules - The Enterprise
October 16, 2017
4 minute read
Those of us who haven't worked in the Enterprise probably don't know a lot about ITIL (Information Technology Infrastructure Library). ITIL may even be a source of amusement for them. C'mon, they would say, how much practical use can you get from a methodology that is defined through a set of books that is actually referred to as a "library"?
Those of us who have experience working in the Enterprise know that ITIL is a necessary "evil." When applied in a pragmatic and customised manner, ITIL processes make a significant impact on the quality and speed of technology and software delivery in large companies. Just as importantly as improving productivity, ITIL helps lower the likelihood of incidents and can improve your cyber resilience.
To the generation of developers and administrators who align themselves to DevOps, ITIL processes can still appear draconian, more the enemy of efficiency than its enabler. To argue flatly for one approach or the other in any situation, though, is ridiculous. More ridiculous still would be attempting to force DevOps methodologies into a large Enterprise in the same way that ITIL processes were forced in over the last 5 - 10 years. Putting in ITIL where before it was the Wild West is one thing, applying DevOps principles where the order and structure of ITIL reigns is an entirely different, and far more risky, proposition.
Can Enterprises benefit from DevOps and ITIL methodologies? Of course they can. They simply need to be judicious in these methodologies are used to ensure that they truly lower cyber risk and improve efficiency. The following is a simple, yet effective, approach to identify and prioritize your DevOps initiative in an Enterprise where ITIL rules. The key is to identify the areas where you will get the most bang for buck through improved collaboration and automation.
1. List out your top/key ITIL processes
There are many ITIL processes; if you have actually defined how each one of them should work in your organization, you're doing well. That comprehensiveness, however, is not helpful for bridging the gap to DevOps. Pick out the three that are used most (most instances per week), involve the most teams (cross functional) and whose failure/inefficiencies cause the highest impact (money/time). Based on my last Enterprise role would choose Change, Release and Configuration Management.
2. Gather representatives from each relevant team to review them
I know, I know. No more meetings, right? Well, this one is important. Make it a single workshop, not a weekly get together. Give it a set time and don't go over. Getting something out is what matters, not making things perfect.
3. Identify the points in each process where things break down
Where is time wasted? Where are the handovers? What costs the business the most money when things go wrong? What parts of the processes create more risk than you're comfortable with? Everyone has opinions on how the business could be run better, and revisiting processes is a great way both to benefit from those ideas and to get stakeholder buy-in.
4. Ask how/if improved collaboration or automation could help
This is the key. Stop thinking about "DevOps" as a high level concept or methodology and focus on what it means. It may be a simplification but thinking of it in terms of collaboration and automation gives instant clarity. Could automated testing be applied where the same errors are being introduced constantly? Should operations staff be introduced earlier than release night to the SDLC? Can we use Continuous Delivery? Can we do Build Automation?
5. Prioritize based on effort and reward
Getting developers and operations staff working in perfect harmony may not be easy but getting them talking is relatively cheap and can have immediate impact if done right. Implementing continuous delivery for a legacy banking system is neither easy nor cheap. This is not an exact science but do your best to list each "DevOps" opportunity and prioritize them in terms of likely ROI.
6. Start at #1
That's it. Don't fret any more about what DevOps is and isn't. You have a prioritized list of DevOps initiatives. Treat them like you'd treat any other work but don't let them get buried. You'll never learn what works for your organization until you get started. If you have buy in from each team from the start though your chances of success are greatly improved.
If you're still interested, try downloading our eBook The ITIL Guide to DevOps.