One of the most frequent questions I get when speaking at conferences or with other industry folks is, “How do I get DevOps going at my company?” Always a great question, but not always easy to answer. Obviously, there are a lot of factors and issues to consider. So a lot of the time I give the “consultant” answer, “It depends.” Culture, employee skills, business needs and drivers, all affect how a company adopts DevOps into their way of working.
If you remember from an earlier post, I wrote that DevOps is primarily about doing operations stuff using development techniques. Secondarily, but importantly, DevOps is also a mindset shift toward Lean and Agile development approaches. (In fact, in its early days, Andrew Schafer called it “agile infrastructure” and other folks called it agile ops.) DevOps attempts, with practices and mindset, to streamline the whole value stream to enable the business to deliver value to the customer. Therefore, DevOps better enables the business to flow value all the way through operations.
These practices and mindset shift can be such a dramatic shift for an organization, especially the “classic” operations group. The typical enterprise operations group has evolved over the years to “operate” the IT infrastructure of the business. The mentality, which was born from the early years where everyone purchased IT infrastructure and applications, meant that it really was about operating the hardware and software and keeping it going. The internet changed that when companies started delivering applications and services via a browser, aka software as a service or SaaS. Now businesses were not only writing the product, but they also delivered it, and operated it on behalf of their customer. Quite a shift!
Some well-known internet companies like Google and Amazon figured this out early and changed their operations model a long time ago. They are regarded as unicorns among herds of horses. Netflix is an example of a company that became a unicorn. Ancestry.com is in the middle of the same transformation. Werner Vogels, CTO of Amazon commented:
“The best way to completely automate operations is to have to developers be responsible for running the software they develop. It is painful at times, but also means considerable creativity gets applied to a very important aspect of the software stack. It also brings developers into direct contact with customers and a very effective feedback loop starts. There is no separate operations department at Amazon: you build it; you run it.”
So, back to the original idea of this post. How do you get to DevOps? Because the shift to DevOps is fundamentalsy a new way of doing ops, I view it as a disruptive innovation. It is literally a mindset, set of practices, and tooling that “disrupts” the classic operations model and paradigm. Clayton Christensen, in his book The Innovators Dilemma, describes why businesses have a tough time adopting certain innovations, even when they know they are good. Fundamentally, adopting new innovations requires money, time, and resources. Many businesses are viewing things with a short-term perspective and view the innovation as not giving enough ROI. They will not allocate resources to the innovation because it steals resources from their current cash cow. This creates an opportunity for another company to “disrupt” them because they are burdened with an existing value network that doesn’t allow them to pursue the innovation, which ultimately leads to their demise.
The way to allow disruptive innovation to happen in a company is to set it up as its own entity outside of the normal “rules” and “constraints” imposed by the existing business. This allows the innovation to grow and thrive, and become established to the point where it can stand on its own and, if successful, likely cannibalize the existing business. The innovation becomes the new norm. It sounds gruesome, but think of it this way: if you don’t do it, someone else will.
Martin Fowler, noted software architect and thought leader, similarly explains it through a design pattern he calls, “Strangulation.” Originally devised to explain how to choke out an old application, it also works in myriad other situations, like innovation. He suggests, “Gradually create a new system around the edges of the old, letting it grow slowly until the old system is strangled.”
To sum it up, here is my recipe for adopting the disruptive innovation DevOps:
- Drive the Lean-Agile mindset throughout the organization. Implement agile practices. Create an environment where the frequent and rapid flow of value is enabled. This creates the foundation for DevOps to take root and flourish.
- Start an independent DevOps venture. Have it led by a senior leader with confidence, influence, and a vision to drive it to maturity. He will have to protect it, nurture it, and get others to adopt it.
- See the venture through with a core team of experts. Hire from outside the company, if necessary, and mix with qualified folks from inside the company. Exempt them from current standards and ways of working so they can freely innovate.
- Grow the venture to the point the “old” is strangled.
Now, go and make it happen.
About John Esser
John is currently the Director of Engineering Productivity and Agile Development at Ancestry.com. His team’s mission is to accelerate engineering’s ability to deliver value to the customer. He is the architect of Ancestry’s transformation to Agile development and continuous delivery. John has more than 25 years software development experience working for such companies as IBM, Corel, Callware Technologies, and Control4. His spare time is gobbled up by his beautiful wife, four teenage sons, reading lots of books, and fly-fishing for trout on the Provo River.