Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
From recent conversations I have been having, it is clear that DevOps is top of mind for many. Out of the 40 or so customers I have spoken with recently, the overwhelming majority brought up DevOps during our conversation. They believe they ought to do DevOps, but they wanted me to help them define it and point the best way to get started.
From my experience, many claim to be “doing DevOps,” but when you drill in, you’ll find wildly varying degrees of what this means. If a team is doing anything at all within the larger DevOps value chain, such as testing their software, they often believe they’re doing DevOps.
Our latest survey on the implementation of DevOps points out how easy it is for companies to say they’re doing DevOps but how difficult it is to do DevOps effectively. There’s widespread agreement among the respondents on all the different things that should get done, but very few people are making significant progress in most of them. If you ask about specific DevOps success factors, very few people are doing them.
Understanding, Then Doing DevOps
Why is DevOps so hard? In general:
- companies don’t know how to do it
- companies aren’t sure what it is
- it’s too hard given the existing organization and/or culture
- too many jobs and people identify with existing tools and technologies
- there may be regulatory issues
- there’s a lack of leadership on what needs to get accomplished and the direct impact on users/customers
The biggest issue usually is the organizational structure. People within IT are working in roles that have institutionalized the separation of dev and ops for 20 or 30 years, and suddenly this must change. Ops, in particular, has a process that is somewhat opaque, but now it has to be transparent, ops teams have to coordinate closely with the development teams, and they are being measured on totally different things. That’s a huge shift.
Going back to the results of the survey, if you told me 20 percent of companies are doing some element of DevOps exceptionally well, I would agree with that. If you tell me 20 percent of companies are doing DevOps end-to-end the way I think it ought to be done, I would say that number is probably closer to 5 percent.
The definition of DevOps makes all the difference. To me, DevOps focuses on the distance between the idea and the customer, whether that idea is a feature, an application or a business model. The purpose of DevOps is to optimize that distance.
I use the word “optimize” for a very particular reason, because there are several different dimensions beyond speed that we need to think about. We also need to optimize for reliability, or perhaps it is appropriate to think of that as quality. Efficiency is another dimension: How much does it cost to run that pipeline? Finally, agility: If I have to make a change based on the customer feedback or the market conditions, how rapidly can I change?
Based on your customers and what you’re trying to achieve in your business, you might optimize for those four dimensions differently than some other company. In some cases, a company might choose to emphasize speed, rolling out a new release every single day. In other cases, reliability, efficiency or agility might be given more weight.
The purpose of DevOps is to make speed, reliability, efficiency and agility a given so companies can focus on digital disruption and serving their customers better—we can see that in the survey results. If we also look at the 20 percent that are farthest along in implementing DevOps, we see their most important metrics are customer-facing metrics. In other words, it is clear that with the emergence of companies focused on business insight analytics, more organizations want to know if their application is meeting the needs of the customers as it was intended.
This is where the cultural and organizational challenges of DevOps come into play. If the ops team owns ops-related metrics, and the dev team owns dev-related metrics, then the organization is probably losing its focus on the customers. Those internal, traditional metrics are not going to get organizations to the Promised Land. You may have developed a bunch of code faster because you’re agile—and that’s great—but it’s only the first step. Instead, if we turn this around and say, “We expect this application to generate a million dollars of new revenue every four hours,” that’s a totally different mindset, and you have a much better chance of DevOps success. The app is either generating the revenue or not, and it’s the feedback you get based on the usage of the application that tells you what else you need to do.
ING is a great example of a company that has a group of people who are focused on metrics that track the distance between the idea and the customers, and they wake up every day with a focus on how to optimize that distance. The rest of the company is then organized and culturally aligned to deliver against that.
When you talk to most companies, you’ll find that there are elements of agile development, code pipelining or release automation that they do very well. These companies are taking a vertical or functional slice—such as test automation or release automation—and concentrating on optimizing there. That just gets us back to where we started our discussion, with everybody saying they are doing DevOps but no one doing it successfully. A better way would be to take an application and optimize all of the delivery metrics around that application. Take it all the way, end-to-end, and focus on solving a customer problem. Once that end-to-end distance is optimized, then you can apply what you’ve learned to other applications.
