I recently learned that Lewis Carroll first coined the term portmanteau to describe “two meanings packed into one word.” DevOps is a current example which has also become a popular topic in the world of IT. If you’ve been reading about it online however, you’d be forgiven for thinking DevOps is only about accelerating application deployment into production. For some, it seems, it’s easy to forget that DevOps has a much broader meaning, and that it’s about building a culture of collaboration, communication and cooperation between development and operations.
Writing about one aspect in isolation isn’t really writing about DevOps. Yet, much of what is written about DevOps seems to focus on development, effectively making DevOps synonymous with continuous delivery or continuous deployment. But this is only one aspect of DevOps.
DevOps is an alternative model where development and operations work collaboratively toward achieving the shared goal of creating business value. And while it is common for an organization with a DevOps culture to use automation and continuous delivery, the fact that they do is not what makes them DevOps.
In many cases, DevOps means an entirely new mindset that requires both development and operations teams to collaboratively pay attention to the full life cycle of an application or service. And not only until it is deployed into production, but from inception to retirement, recognizing the tremendous value of communication, experimentation and rapid, bi-directional feedback that ultimately makes the whole process more nimble and more adaptive.
Much of the confusion around DevOps stems from a handful of vendors who describe their application development, testing or release automation point products as “DevOps tools.” Rather than referring to their tools as what they are, these vendors are latching onto DevOps and reshaping or reducing it to match their own capabilities.
There is absolutely a place for talking about foundational development and operations capabilities or processes that facilitate or accelerate DevOps culture, but the scope of the conversation needs to be much broader than application development, testing or release automation tools.
The confusion isn’t limited to Dev, either. For example, unifying your infrastructure management tools and breaking down the domain silos within Ops so you can better focus on the customer experience and prevent, reduce, or speed the resolution of operational outages is NOT DevOps. But, it’s definitely an operational process maturity improvement and tool rationalization undertaking that can be just as critical to a successful journey towards DevOps as improving application release velocity and quality.
With DevOps rapidly gaining traction, it’s important that we remember what it is and not allow ourselves to become victims of “DevOps reduction” or “DevOps washing”.
Figuring out where to start with DevOps can be a challenge. My advice would be to take a holistic view of all of your foundational Dev and Ops people, processes and technologies in order to understand how they’re creating business value or improving customer experience. Then determine if those are capable of delivering and handling an increase in app release velocity while improving the customer experience, and if not, figure out what needs to change. Finally, look for specific ways to increase or improve the communication, interaction and collaboration within and across these teams, processes and technologies.
Cameron van Orman is Vice President of Strategy for Infrastructure Management & Service Assurance at CA Technologies.
