5 Challenges in Implementing Enterprise DevOps
Building a business is like trying to perfect a machine, such that when you put a dollar in on one side, two come out the other. Once all the dials and inner mechanisms are set correctly, the idea of going into the machine to change something becomes very daunting. Business relies on stability, and the notion of database DevOps in the enterprise is so fraught with change that it can be seen as more disruptive than beneficial for the company to pursue.
But DevOps is more than a fashionable trend. Some of the reported numbers on high-performing IT organizations who practice DevOps are an order of magnitude improvement over current state, like the statistic that DevOps organizations are deploying code 30 times more frequently than their counterparts – see the Puppet 2014 State of DevOps Report for more.
The benefits in IT are also translating into benefits that are meaningful to the business, affecting market share and profitability figures. Couple that with unsteady macroeconomic trends, and the shortening of business cycles enabled by technology, and DevOps represents a sustainable competitive advantage for those organizations willing to adopt it now.
But the order of magnitude improvement in code delivery also represents something else – DevOps is a discontinuous innovation in the way organizations develop and deliver software. And as with any new discontinuous innovation, the implication is that creative destruction will follow. Companies that hold on to legacy business and technology models, without pursuing the ever-growing number of digital market opportunities, will wither in the coming decades, supplanted by those companies which have adopted new ways of thinking and operating.
It’s not all gloom and doom, though. Many IT professionals are investigating DevOps, trying to think through how the concepts might fit in their organizations. Information is being shared. Best practices are being developed, and software vendors like Datical are building tools to enable collaboration and support the workflows between development and operations. DevOps is becoming less something that only startups practice, and more something the enterprise views as worth investigating.
Implementing DevOps in the enterprise carries a number of challenges, however, which is the subject of an article on the New Relic blog yesterday (see article here). Most of the challenges discussed center around affecting change within your existing culture, often seen as one of the largest obstacles to enterprise adoption of DevOps. While this list isn’t exhaustive, it’s a good primer to start thinking through the potential obstacles in implementing DevOps in the enterprise.
Breaking down language barriers
Development and operations view the world from different perspectives. Although they are both concerned with the same outcomes, their approaches are different, like two sides of the same coin (in my opinion this same dichotomy exists between finance and accounting). These different views have led to subtle but important differences in terminology, like the definition of a “full stack.” Take the time to tease out these differences and establish a standard lexicon for all of IT.
Overcoming the developer vs. operations mentality
Selling DevOps to developers isn’t too difficult – for development it’s easy to see the benefits to creativity and innovation made possible through DevOps. Operations, on the other hand, views DevOps with suspicion, believing it is an attempted development coup to enable developers to continually dump buggy, untested software into production. This is at least somewhat warranted, as Ops are the folks who have to deal with outages and service disruptions on a regular basis. They see change as the enemy, but according to New Relic, “The trick is to show operations pros that faster deployment cycles, with significantly fewer changes per cycle, means that problems are fewer and thus much easier to identify and rollback if necessary.” Fewer changes per release means more control for operations, even if those releases happen more frequently. Fewer changes also make it vastly less complex to perform root cause analysis and troubleshooting when issues do occur.
Learning new skills
There is a popular sports adage that goes, “There is no comfort in the growth zone, and there is no growth in the comfort zone.” DevOps requires change. Change requires adaptation. Adaptation requires learning new skills. Whether it’s a sysadmin learning to build new tools, or developers breaking out of a Waterfall existence, rest assured that DevOps will firmly place your organization into the “growth zone.”
DevOps will require new workflows, which if implemented will cause a trickle-down effect throughout the organization. Current tools will become obsolete, and investment in new tools will be necessary to support new workflows. New and more complex workflows will have implications for regulatory compliance and security issues. It’s important that the DevOps implementation team has a broad and deep skill set, and that all stakeholder interests are represented during planning. It will require a holistic view of the entire value chain for software delivery, from conception to monitoring in production. A good exercise for the implementation team is to perform value-stream mapping for current and proposed processes, and to overlap those maps to identify areas which will cause friction.
DevOps will shift the power balance in the organization, in some way or another. It’s inevitable, but not necessarily insidious. What’s important is understanding who will have final authority over decisions, and installing the checks-and-balances necessary to ensure that the voices of each stakeholder constituency are represented and heard in the decision making process. Trust is of critical importance among the management team, borne out of a shared belief that DevOps will improve the lives of all involved.
Is your IT organization contemplating a move towards DevOps? Read more about how DevOps benefits the business in our white paper, The Business Case for DevOps.