Introducing DevOps Where ITIL Rules - The Enterprise
Introducing DevOps where ITIL rules– The EnterpriseThose of us who haven’t worked in the Enterprise probably don’t know a lot about ITIL.ITIL may even be a great source of amusement for them. Show them a picture of theITIL books and they may well even laugh out loud. C’mon, they would say, how muchpractical use can you get from a methodology that is defined through a set of books thatis actually referred to as a “library”?Those of us who do, or have, worked in the Enterprise, know that ITIL is a necessary“evil”. When applied in a pragmatic, and customized, manner ITIL processes make asignificant impact on the quality and speed of technology and software delivery in largecompanies. The pre and post difference of an ITIL implementation can be truly amazing.To the generation of IT professionals who align themselves to DevOps ITIL processescan still appear draconian, more the enemy of efficiency than its enabler. To argue flatlyfor one approach or the other in any situation though is ridiculous. More ridiculous stillwould be attempting to force DevOps methodologies into a large Enterprise in the sameway that ITIL processes were forced in over the last 5 – 10 years. Putting in ITIL wherebefore it was the Wild West is one thing, applying DevOps principles where the orderand structure of ITIL reigns is an entirely different, and far more risky, proposition.
Can Enterprises benefit from DevOps methodologies? Of course they can. They simplyneed to be judicious in the way that they implement them. The following is a simple, yeteffective, approach to identify and prioritize your DevOps initiative in an Enterprisewhere ITIL rules. The key is to identify the areas where you will get the most bang forbuck through improved collaboration and automation.1. List out your top/key ITIL processesThere are a lot of ITIL processes and if you have defined how each one of them shouldwork in your organization then that’s no mean feat. It’s not helpful here though. Pick outthe three that are used most (most instances per week), involve the most teams (crossfunctional) and whose failure/inefficiencies cause the highest impact (money/time).Based on my last Enterprise role would choose Change, Release and ConfigurationManagement.2. Gather representatives from each relevant team to review themI know, I know. No more meetings, right? Well, this one is important. Make it a singleworkshop, not a weekly get together. Give it a set time and don’t go over. Gettingsomething out is what matters, not making things perfect.3. Identify the points in each process where things break downWhere is time wasted? Where are the handovers? What costs the business the mostmoney when things go wrong?4. Ask how/if improved collaboration or automation could help?This is the key. Stop thinking about “DevOps” as a high level concept or methodologyand focus on what it means. It may be a simplification but thinking of it in termsof collaboration and automation gives instant clarity. Could automated testing be appliedwhere the same errors are being introduced constantly? Should operations staff beintroduced 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 butgetting 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 andprioritize them in terms of likely ROI.6. Start at #1That’s it. Don’t fret any more about what DevOps is and isn’t. You have a prioritized listof DevOps initiatives. Treat them like you’d treat any other work but don’t let them getburied. You’ll never learn what works for your organization until you get started. If youhave buy in from each team from the start though your chances of success are greatlyimproved.