DevOps might be easier defined by looking at what DevOps is not. DevOps isn’t tools or services that you download from the cloud, the title you give a newly hired engineer, or something you can purchase or find on a balance sheet. I can go on and on about what DevOps is not, but the three statements above are common myths and misconceptions, so it’s important to point them out early when trying to help others understand DevOps.
DevOps is better defined as an ideology, a culture of collaboration and sharing aimed at bringing the software development and operations teams together to help eliminate constraints and decrease time-to-market. But, there’s a clash happening inside of organizations today that is preventing the full adoption of this culture to be realized.
There’s a shift taking place within companies — a change that impacts IT. The culture of IT is moving in lock step with the changes happening in the larger workplace, but the discussions around this change are harder to find than those discussions about the overall transformation of the modern worker. The culture within IT is shifting dramatically, positively, and that has everything to do with DevOps.
Historically, lines of business (e.g. marketing, IT, operations, etc.) were siloed, not interacting with other business units until absolutely necessary. This separation was typically created by perceived responsibilities and the lack of a desire to work outside of these drawn lines. As a result, there have been naturally formed groups of people that don’t talk to each other yet are working toward the same goal – delivering a better product, creating value in their market, solving problems for people.
This is the culture in many businesses and it becomes even more noticeable when you start looking closely at IT departments. Traditionally, IT was an isolated group. Engineers write code and build the product and “throw it over the wall” to a different set of engineers for quality and testing, then it makes it’s way to a production environment managed by a team that has little-to-no knowledge about the code residing on their infrastructure. Marketing and sales then take over and start the promotion and selling side of the equation. Rarely do the groups collaborate with full transparency and respect for each other’s roles. They certainly interact, but it’s the collaboration piece that is often much more difficult.
We are now seeing the internal structure of businesses evolving. There are traditionalists happily working within boundaries of responsibilities and modernists that want to be plugged into what everyone is doing. Another way to look at this is generational — Gen Xers or Baby Boomers historically like well defined roles and responsibilities while millennials traditionally seek out roles that have more loosely defined responsibilities.
We are hearing more about DevOps because of this evolution. DevOps shifts the tradition of how IT is organized, how engineers interact. It brings a set of best practices that guides how engineers and IT works that is markedly different than a traditional set of principles. It’s a culture of automating, measuring, and sharing in the name of increased efficiencies throughout the software development life cycle.
One of the primary principles of DevOps is empathy. Empathy from developers toward the system administrators (i.e. Operations), Operations for the developers, and even empathy across non-technical teams of the company. In most organizations the mandate of a developer is merely to produce a piece of software that works — if it worked within an engineer’s development environment, then someone else must be able to make it work in production, right? Ideally, developers must care how secure their apps are, how hard they are to deploy, how hard they are to keep running, because our colleagues on the Ops side are typically paying the price for issues once the product is released to the public, not the developers who built it.
Having more empathy for each other’s role in delivering better products and solving problems is the destination DevOps is driving forward for organizations. Until that point, DevOps adoption faces real challenges. A cultural war of sorts.
DevOps represents cultural change. Whether it’s the change of resistant engineers that don’t want to be on-call or the change of Operations teams to have more empathy towards their counterparts writing code, to the willingness of executives to embrace a culture of automation, measurement and sharing. Organizations must overcome the culture war to be able to approach the agility and productivity that organizations following a DevOps model gain. The faster they can get there, the faster these organizations can take the competitive edge away from traditional enterprises.