Once in every ten years, you see a transformation of sorts in technology – from a career perspective. A tsunami tends to hit most IT professionals every decade to drag them deep into the ocean and leave them for survival prospects. There are numerous examples of what once ruled the roost is now at the mercy of the laggards. Mainframes were the toast of the IT world and the numero uno choice of all banks, but now it is slowly and steadily making way for SAP and other technologies to take its space. Likewise, .net and and core java too are sparse when it comes to core development today.
If you want to directly get into the crux of getting into DevOps from ITIL, jump to the section: Switching to DevOps.
Not only is this limited to technologies but also to management frameworks. Waterfall project management methodology in IT is like a dinosaur. We know it’s extinct and when we dig up our old project archives, the artifacts seem like the bones in a natural history museum.
ITIL too is not spared. Ten years back, it was hot in the market, and people who mastered it were moguls of the IT operations world. Today its a different matter altogether. Although the new version (V4) has been introduced for the digital age, it has not found favor in leaps and bounds. I penned a book (Reinventing ITIL in the Age of DevOps) around the same time where the yesteryear ITIL could still have some life left in it, if it was to adapt and change its outlook.
With my name leaning on one side towards ITIL and my recent love DevOps, a number of IT professionals frequently message me on LinkedIn on how they can get off the sinking ship and reach safety – read ITIL to DevOps. Well, I made this exact move about four years back and am not looking back.
I was at the peak of my ITIL career when I made the switch to DevOps. At the time, I had worked several years in ITIL, in designing, implementing and leading engagements that had ITIL written all over it. I had even developed a few adaptations of the ITIL frameworks, the most popular one was a SIAM framework which tried to gain popularity by riding on ITIL’s swollen back. In about four years time, I made the switch from being a service architect to a DevOps architect. The journey was arduous with hours and hours of reading, listening, thinking, discussing and head scratching. But it was fully worth it. Thanks to my background in waterfall project management through PMP, I have seamlessly taken over the mantle of being an Agile Coach as well.
Enough of the long introduction and now let me tell you how to jump into DevOps with both your feet.
Switching to DevOps
Remember that half of DevOps is operations. And operations is defined by ITIL. But the question is, whether this is a good argument and justification for moving over easily from one management framework to another. Oh by the way, DevOps is not considered as a framework per se but a culture. But for me, it is built on certain objectives, and achieving those objectives require a framework, whether that framework is consistent or not is a different different discussion altogether.
Read: Why DevOps and ITIL are Not on Opposing Sides?
So with DevOps consisting of operations and ITIL offering service management professionals, can we assume that all that we did in service management projects, we do it here as well?
Absolutely not. DevOps may have half its letters indicating operations but in no way does it correlate to the size and breadth of operations. DevOps is about speed and quality. When quality goes up, the dependence on good service management practices bears down. With Agile coming in the way, the insistence of set processes and adherence to it is like a guidance document rather than a policy handbook.
An ITIL professional switching over to DevOps has to reinvent himself/herself just like the way the technologies and frameworks have changed its flavor and religion. So what reinventions can happen with a person who is mostly oriented with processes, KPIs and workflows.
The Choices
There could be a number of roles in DevOps led product management projects. I am going to touch base on the generic roles that ITIL professionals can pick up.
DevOps Engineer
Role Description: A DevOps engineer as the name suggests is a technical role. He/she is capable of configuring and integrating tools. The primary job of a DevOps engineer is to configure the toolsets as per the DevOps architecture and to keep it alive and kicking at all times.
Skillsets Needed: Technically oriented and good scripting skills. In my experience, Power Shell and Python are perhaps the most popular scripting languages that DevOps engineers employ. ITIL professionals who have technical leanings can jump into the bandwagon of DevOps engineers.
Recommended Certifications: AWS Developer, Azure Certifications (there are multiple relevant ones)
Tools to Target (to start with apart from AWS and Azure stacks): Jenkins, Kubernetes, Azure DevOps, Jira
Scrum Master
Role Description: A scrum master is a watered down project manager who gets to work with people rather than with data and numbers. He/she plays the role of a facilitator and leads the team into achieving the project’s goals without the burden of commanding and conquering.
Skillsets Needed: Project management skills coupled with people skills. An ITIL professional who has a taste for project management and a people’s person can be a perfect fit. Some knowledge around understanding SDLC would be highly beneficial.
Recommended Certifications: Certified Scrum Master (CSM), Safe Agilist (SA)
Tools to Target: Azure DevOps, Jira
Operations Manager
Role Description: An operations manager is an open role that I mention here. It could be either be somebody in charge of entire operations, or somebody playing the roles of an incident manager, a problem manager and a change manager for one or multiple DevOps teams. The role that I am envisaging here is somebody responsible for operations in the truest sense.
Skillsets Needed: An operations manager needs to be meticulous and should have fried his brains in ITIL and other processes. People management skills are necessary and not absolute. He needs to know how to read and represent data. Also he must have the experience to foresee operational risks.
Recommended Certifications: ITIL Foundation
