Unicorns, Horses, ITIL, and Enterprise DevOps

“DevOps” is one of those buzzwords that means everything and nothing at the same time. It is like the words “cloud,” “architecture,” and “Internet of Things”—terms so vague they lead to endless debates between IT people. DevOps seems to take this verbal sparring to a new level. On top of arguing over what it means, people also debate the proper method for delivering DevOps. Notice that “method” is singular, as if there were only one way to do it. 

The following three topics are heavily debated amongst DevOps practitioners, evangelists, pundits, and wannabees:

All Unicorns Were Once Horses

Most examples of successful DevOps in practice come from web companies like Etsy, Netflix, Facebook, Twitter, and the like. Many people in large enterprises call these web companies “unicorns,” because the things they are able to accomplish appear to have as much chance of happening in a large enterprise as the Cubs have of winning the World Series in a given year. The DevOps thought leaders will argue that companies like Netflix and Etsy did not start out with successful DevOps practices like they have today. They argue that these unicorns were once horses, meaning they were as messed up as most enterprises at one point.

I have to disagree with that statement. None of these web companies can claim anywhere near the number of complexities that most global large enterprises have to contend with. Web companies typically have a very focused business model. For example, Netflix is focused on delivering streaming content, Etsy is focused on eCommerce, Twitter and Facebook are focused on social media, and so on. Sure, these companies have lots of features and are branching out into new areas, but at the end of the day, all of that feeds into a common delivery model of some form of content over the web. From inception, they have always focused on scalability and constant deployments, because every web company needs to constantly update content to stay relevant to its end users.

Now let’s look at modern enterprises. Many of these companies are conglomerates of many different businesses, each bigger than Netflix and Etsy combined. Take General Electric, for example. GE Capital is a $44B business unit, one of many multi-billion-dollar business units within GE. In fact, within any given GE business unit are a number of large acquisitions. On top of that, large organizations have legacy technologies in place from every generation of computing, from mainframes and minis to client-server and cloud. Heck, many of these companies have more SAP implementations than Etsy has system administrators.

Culture is another major differentiator between web companies and large corporations. Companies that were born in a fast-paced web environment need a lot less coercion to adopt lean and agile principles than companies that have been supporting mainframes and SAP implementations and leveraging Oracle RAC and old WebSphere technologies. Companies that deal with point of sale (POS) solutions have been conditioned to change software as infrequently as possible, due to the risk of disrupting a piece of hardware that often generates a million dollars a minute in large retailers. Sure, the DevOps purists will argue that frequent, smaller changes mitigate the risk, but try to convince retailers to implement any change to their POS before Thanksgiving and Christmas, when they make or break their annual numbers, and they will show you the door quicker than you can run your continuous integration build process.

So, although these unicorns may have been horses at one time in their life, there is a huge difference between a racehorse and a plow horse. Web companies do not have even close to the level of complexity that large enterprises have, so let’s stop assuming that processes that work well for web companies will also work well for large enterprises. Yes, we should observe the lessons learned from these companies, but let’s tailor our solutions to fit within the constraints and challenges of the enterprise.

Does ITIL Have a Place in DevOps?

This argument gets as heated as a Sean Hannity interview with a guest from the left. Everybody is yelling, and nobody is listening. A lot of people do not like ITIL and see it as the equivalent of making teams run knee deep in the mud. ITIL is a collection of very sound practices that help ensure that software is delivered in a repeatable, managed, and auditable fashion. Many companies have implemented it in a very waterfall, manually gated series of processes. “Manual” and “waterfall” are two of the most hated words in the world of DevOps.

Again, if we try to insist that large enterprises implement what web companies implement, then we conclude that DevOps does not work with ITIL. However, tell that to a large, global financial institution for which regulation and security are more important than agility. These companies must make ITIL work. The way to do that is to automate as much of the ITIL process as possible. This includes approvals. How do we automate approvals? We determine what the rules are for approving various use cases, and then we architect systems that output the necessary artifacts and metrics required to automate the decision-making processes (where applicable). We also build many of the security and audit constraints into the continuous build process. We invite the security team, the GRC (governance, risk, compliance) team, and the architecture teams to sprint zero to get all of the necessary technical requirements into user stories up front.

Large enterprises may never be able to do one hundred deploys a day like Amazon, but they probably don’t need to anyway. There is no reason why they can’t tune their ITIL processes to get to the point of delivering daily. They also may decide that certain applications fit a high-risk profile and are not allowed to be released every day. After all, not all applications are web apps. Use a hammer when you have nails; use a screwdriver when you have screws. Tighten controls when the applications are high risk; loosen the controls when they are not.

A handful of DevOps practitioners had a long Twitter fight about this the other day. One camp said to throw out these old ITIL processes because they are too rigid. If a company is starting from scratch, I would agree with not using ITIL. However, for companies in which ITIL is embedded into the culture (and successfully implemented), why throw out something that is adding value? The easiest way to derail a DevOps initiative is to create resistance to change. The easiest way to create resistance to change is to throw out something in which an organization sees value. If you want to get rid of ITIL in a large company that has been practicing ITIL forever, doing it in a big bang is the fastest way to fail. If you must get rid of it, do it over the course of many small iterations over time. But if ITIL is working, adjust it so that it flows in a more agile fashion.

Is There Such a Thing as a DevOps Engineer?

I wrote a post called “No, You Are Not a DevOps Engineer” a while back. My argument was that DevOps is not a role, a person, or a group. It is a way of building software quickly and with quality and reliability by encouraging greater communication and collaboration. Therefore, having a role called “DevOps engineer” makes about as much sense to me as having an ITIL engineer, an agile engineer, or a waterfall engineer.

However, as long as a company is delivering on the promise of DevOps, I couldn’t care less what you call the people who do it. Some would argue that the title of DevOps engineer brings focus, pride, and visibility to DevOps within a culture. Whatever works, I guess. But if you use that title, make sure the job description is not the same as one for a systems admin who happens to work in the cloud. That is a systems admin or an infrastructure engineer.

Summary

We tend to waste a lot of energy arguing about DevOps. I don’t think anyone disagrees that building software faster with higher quality and more reliability is what IT needs to be doing. But we spend more time arguing about it and less time actually doing it. So let’s move on from all these religious battles. There is no one way to do DevOps. Web companies will have different implementations than large enterprises, and we should stop expecting them to use the exact same processes. Unicorns may have once been horses, but they were thoroughbreds and never dragged a plow across the field for hours at a time. And finally, create any title you want for your engineers, but realize that DevOps is more than an infrastructure engineer and more than a full stack engineer. DevOps means getting the infrastructure engineers and the application engineers working together with the common goal of building software faster, more reliably, and with higher quality.