Despite seemingly never-ending arguments to the contrary, DevOps has firmly arrived in the enterprise. No, the question is no longer if DevOps is appropriate for the enterprise anymore – the more appropriate question is to what extent has DevOps made its impact on the typical enterprise.
But the enterprise move to DevOps isn’t a straight line. One of the steepest, and also most common, challenges for enterprises moving toward DevOps is how diverse the IT environments in large organizations tend to be. Yet, for continuous integration, continuous delivery, and DevOps to thrive – architects, developers, test, QA and other teams all need to be operating on uniform systems – but in most enterprises that not the case.
Yet, as the 2014 State of DevOps Report from Puppet Labs found, DevOps enterprise adoption is increasing, and that DevOps adoption was accelerating, and that high-performing IT organizations that embrace DevOps are typically more agile and reliable, deploying code 30 times more frequently and with half as many failures as non-DevOps enterprises.
However, it’s this enterprise IT inconsistency that is one of the main reasons why DevOps gets entrenched in certain departments within large enterprises, but is then slow to expand outward throughout the rest of the organization.
“This is a huge problem in larger enterprises, especially as DevOps practices grow beyond just isolated departmental applications. Architects have one system for prototyping; developers have a different system to code on; test and QA have their own unique ‘standard’ systems; while operations have untouchable systems for production,” Andi Mann, a VP at CA Technologies wrote in this post, Making DevOps Work in Complex Enterprise Environments, for DevOps.com.
In this roundtable, DevOps Summit Power Panel | Is DevOps Changing Enterprise IT?, both JP Morgenthal, director of cloud computing practice at Perficient, Inc., and Gordon Haff, cloud evangelist at Red Hat agree that DevOps is still in its early days and that enterprise DevOps adoption will be relatively slow, as enterprises build more consistency in their IT environments. “I think enterprise needs to mold DevOps to its needs and understand the differentiation for how to deploy that in a large multi-faceted IT department,” says Morgenthal.
This is why DevOps in the enterprise doesn’t typically move quickly. There’s so much variance between department and team languages they use, as well as methodologies, tools, and procedures they have in place that all need to be normalized. This inconsistency across the enterprise is the enemy of broad, enterprise-wide DevOps success.
Justin Arbuckle, former chief architect at GE Capital (currently, vice president of Europe and chief enterprise architect for Chef) created an adept analogy for the enterprise journey to DevOps and consistency with Herman Melville’s classic work Moby Dick. “The whale isn’t DevOps. In my opinion, every organization has a whale called consistency. Consistency of environments, whether it be the consistency of the images running on your service. Whether it be the consistency of the IT environments, consistency of the processes, or whatever the thing happens to be: consistency is at the center of many of the organizational challenges that we have today. So driving that consistency message, in our experience, has been absolutely critical to delivering the message as to why we need to go to sea,” he says.
That doesn’t mean there aren’t many places where DevOps can succeed, and succeed swiftly. As Arbuckle points out, regardless of the size of the enterprise you will find there will be shared problems among groups, and in shared problems there is the shared motivation to solve these problems. “It’s about getting a bunch of people who want to work on a common set of problems and together you start showing results,” says Arbuckle.
For instance, most every large team has security, compliance, QA and other challenges. What GE Capital did, to help solve them better, was to provide regular weekly demonstrations where everyone in the organization was invited to watch and learn how applications and systems were developed being developed. And dozens of employees from throughout the organization have attended some of the larger demos, with one hitting 80 attendees, Arbuckle says.
“We’ve evolved this process in GE Capital called “compliance by demonstration.” Compliance by demonstration means essentially instead of waiting for some form to be filled out, and we then have to spend three months explaining to people why the answers we put down are correct, we involve everyone from the beginning. And you know what happened? The amount of support that we’re getting from that is now amazing,” says Arbuckle. “They [different teams] want to do the right thing. They don’t want to get in the way of business value. So any way that we can help them see what we’re doing is awesome,” he says.
The key to finding those shared set of problems, teams need solved is to get everyone involved in the process early. “That’s when it becomes real. What is real is not DevOps or using a new process, rather it’s a whole bunch of people around the organization saying, “Wow, they’re moving really, really quickly and we had an interesting discussion about data portability between two geographies and they [these other teams] have a really good plan for that.”
When it comes to moving a large enterprise to DevOps, as David Mortman, contributing analyst at Securosis puts it, there’s no right or wrong. “If your enterprise is collaborating and the teams are working together on how to improve processes, or automate what can be automated, share lessons learned and just collaborate more effectively then you are essentially practicing DevOps. And there are many ways to get down this path,” says Mortman.
That increased level of collaboration and sharing is one of the great ways that IT, dev and ops can stop being seen as part of the enterprise bottleneck, and “start being part of the story where other parts of the organization begin to see how they can change and become better,” says Arbuckle.
The whale isn’t DevOps. The whale is the elusive goal of getting enterprises to do things consistently, and through that consistency, add value more quickly back into the enterprise – and while that storyline may never become an American classic – it’s certainly a modern narrative worth chasing.