When I look at the future of DevOps adoption and acceleration I contrast it with what I feel was the failure of ITIL to really move beyond large enterprise IT shops. I am of the firm belief that DevOps has the legs to succeed and soar where ITIL sort of crashed and burned. OK if not crashed and burned, at least sputtered out. To understand why I feel this way, let me share a little personal history with you.
ITIL demands you to come to IT
I remember my first ITIL project. I was working at a large retailer and I was asked to help our IT department understand what this ITIL thing was and to help drive adoption of some of ITIL’s basic concepts. First on the list was to get a service catalog up and running. In the space of just a few weeks, I realized the main barriers to adoption and helped our IT executive team understand that getting IT consumers to understand, much less embrace an IT-centric taxonomy such as ITIL was not going to be an easy task.
This scenario points directly at one of the big reasons ITIL failed to achieve critical mass (i.e., adoption of the model outside of large enterprise IT) and also reveals why DevOps has a much better chance of success of achieving critical mass (as long as we ourselves don’t mess it up).
Mind you I’m not saying that ITIL is dead or that it has nothing to teach IT shops. I am saying that ITIL alone has not really changed much of anything inside of IT shops, let alone improved the reputation of IT with it’s consumers and customers.
When you contrast ITIL and DevOps several things really set the two approaches apart:
- ITIL makes it easy to blame the business for not talking IT’s language while DevOps continuously seeks to meet people on whatever terms they are capable of communicating in. DevOps inspires, while ITIL deflates
- DevOps is centered around improving the lives of IT workers everywhere while also improving bottom lines at the companies they work for. ITIL is centered around improving stability in the most efficient manner possible. I don’t know about you, but I just don’t see a room full of people, much less an entire organization getting excited or inspired by the concept of efficient stability. The only people likely to get sustainably excited by “efficient stability” are the accountants who can now start to push cost (i.e., people) out the door.
- ITIL at its core is reductive (or at least allows for reductive methods and approaches to grow unchecked). For those uninitiated in philosophy or how language influences our ideas and behavior, reductionism is when people essentially believe that a complex system is nothing more than the sum of its parts. This reductive approach at the core of the ITIL movement is what reinforced the division between Dev and Ops – because the concept of team chemistry has no place in ITIL given that the organization is nothing more than a collection of faceless workers who play out a prescribed role.
Reductive goals and processes, essentially reduce people and their efforts to numbers. The act of using quantitative targets as goals in large initiatives is a dangerous practice in general and grows more dangerous in larger groups and organizations – case in point the recent GM ignition failures that resulted in 13 deaths in an effort to save .57 cents per car affected by a defect.
Before you get excited, I’m not proposing that ITIL will kill people. I am stating that allowing an organization to be led by reductive philosophy allows a whole bunch of unintended consequences to come into play and often leads to holding dollars as singularly more important than anything else; sometimes even human life.
Whether or not you agree with my point that efficiency driven quantitative metrics are not inspiring, it’s kind of hard to argue with 40 years of scientifically proven fact that when “a measure becomes a target, it ceases to be a good measure”.
DevOps shops “live to serve”, while ITIL shops “serve to live”
DevOps contains a concept of craft that extends beyond efficiency. When a problem arrives in a DevOps shop (or at least one that really embraces the cultural ethos), the staff looks at the real resolution of that defect as a matter of personal pride. This pride is not a statement of “pride in self” however, but a statement in “pride in craft”. To hammer this contrast home, does ITIL by itself even have a deep cultural bias at all, much less an ethos?
This perspective is what allows DevOps shops to act in a manner that transcends the checkbox approaches that pervade formalist driven shops that believe in “adherence to process” above all rather than the “results the process is intended to achieve”. If you think I’m wrong, go ask your business clients how they feel about the DMV-like experiences they get when trying to get a problem solved.
This perspective is also why DevOps forms strategic pillars in automation and performance. Performance and automation efforts are not only about the manufacturing of time. Automation isn’t only a method of driving towards error free processes, or even a liberator of individuals from mundane tedium. Driving highly performant code and infrastructure isn’t only about conservation of compute resources.
Well implemented automation routines and highly performant applications are also a deeply creative expression of both development and operations practitioners. The same sense of artistry and elegance that was once reserved for just the software developer has been opened up to all IT practitioners. With the arrival of DevOps, being a great IT professional is not out of reach of any IT practitioner no matter their discipline.
We just can’t afford to mess this one up. In order not to, here is some practical advice:
As you go forth in creating or playing your part in your organization’s DevOps journey, look out for these pitfalls and pivot back to the center.
- Reductionism – Don’t let numbers be the mission. This doesn’t mean don’t have numbers in your goals. It only means to make sure that your number oriented goals have a basis in making things better for people. When you hear someone say “We need to get this deployment routine under 4 hours!”, make sure that someone reminds everyone that the reason to get it under 4 hours is to allow employees to have a reasonably well balanced life outside of work. Off hours deployments that last four hours, when things go right, should not be a target that anyone is proud of. Getting people home to their families and allowing people to be able to keep a healthy sleep schedule is goal worth shooting for.
- Formalism – Worshipping the shovel rather than the hole it digs is an easy trap to fall into for people whose jobs revolve around buiding and using tools. Remember that processes and tools are mechanisms intended to guide novices and intermediates through decisions. When you see someone turning a process or a tool into a sword and shield for working with others, make sure you remind them that results are better than processes.
People Over Process
Neither processes nor tools solve problems; People do. Processes and tools don’t create business opportunities by themselves; People do. Isn’t that why we chose this profession in the first place? To be useful in solving problems and to create opportunities to make things better while allowing people (ourselves included) to have a good standard of living.
Now go DevOps practitioners! Go kick some ass and make the internet awesome!
