Those 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 the ITIL books and they may well even laugh out loud. 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”?
To the generation of IT professionals 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 methodologies? Of course they can. They simply need to be judicious in the way that they implement them. 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.
There are a lot of ITIL processes and if you have defined how each one of them should work in your organization then that’s no mean feat. It’s not helpful here though. 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.
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.
Where is time wasted? Where are the handovers? What costs the business the most money when things go wrong?
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 automatio
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.
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.