Ask a dozen engineers, developers, testers or their managers what their definition of DevOps is and you will get likely very different answers from each of them. Some may say it’s primarily about culture, others may say it’s about accelerating or automating the release of software and infrastructure changes and some may use the mantra, “People, over process over tools.”
What no ones seems to be able to agree on though is how to define the boundaries and constituent parts of what DevOps is really all about. It is all-encompassing, it seems to cover topics as varied as continuous improvement, collaboration, a whole raft of processes from agile, through testing to operations procedures, audit, compliance and customer feedback to collaboration. It seems to be attempting to cover every facet of life in this small part of development and IT operations that we live in—and because it’s so broad no one can really agree on what it means.
My suggestion is that we should try to narrow the definition of what DevOps is in an attempt to create some boundaries so that it can be considered more of a discipline than a utopian goal. For this reason, let’s consider some of the core concepts—culture, communication, collaboration, continuous improvement—as things that are important to its implementation, but not the thing itself. These are aspects of high-performing teams and should use a different lexicon outside of the DevOps world.
So culture should not be considered part of DevOps?
Put simply, any initiative that fundamentally reshapes an industry through a fundamental change in its objectives, process and delivery mechanism implicitly needs the support, buy-in and leadership of those involved. Much of the cultural aspects of DevOps seems to be around these areas—but if you are attempting to radically change the way any industry works, then these are common goals that use management and leadership theory that are not restricted to change within a narrow segment of software development and IT operations. These leadership challenges exist not only within the teams responsible for the delivery of software and IT operations—but in many industries that undergo disruptive change.
Should culture be a primary factor in implementing a DevOps initiative?
Now, this may sounds like a contradiction to what’s been said above but the answer is, of course, yes. However, the culture of any organization should be at its core. The culture within a law firm is important, as it is in a research lab or within a retail organization. If we take retail as an example, when a retailer implements just-in-time (JIT) delivery, which is analogous to what certain aspects of DevOps is trying to achieve—the faster delivery of goods, automation, small batch, feedback loops, metrics, audit, collaboration of disperse part of the supply chain—how much priority is based on whether the employee’s need to be bought into the idea before the initiatives were started? I would suggest not much; it was a management decision, based on shareholder value and the competitive advantage it would provide over competitors. Now that DevOps has become much more mainstream, I think we should think about it in a similar fashion. Retailers that have not implemented JIT are either out of business or very niche. We should no longer be thinking we need to get staff buy-in; the world has moved on, it’s happening, it’s mainstream and if your not on board, then get a job elsewhere. If you work in a shop and put some goods in the store for sales that have not been delivered by JIT, then you get fired. Simple as that.
Is DevOps really the same as JIT Delivery?
No, of course it’s not. JIT was a top-down, strategic management decision to implement on its workforce. It did not come from the grass roots, it did not come from a philosophy and belief from those at the coal face that there is a better way to deliver goods to customers, it was not a revolution by checkout staff that demanded that no longer should their managers buy from suppliers on a golf course and return to the store and tell them to make it work. The DevOps culture, by which I mean the culture within the DevOps community, is so inspirational because they shunned the top-down approach to implement bloatware and chose to go off piste—collaborate with their piers and change the face of an industry in a revolutionary way. They demanded that they know best.
Too many Brents
For all the talk of culture however, this industry we work in has far too many Brents (as in the indispensable engineer in the Phoenix Project, who is the only person who can fix the problem, but is also the root cause of all the issues). I am often baffled at the irony of the no hero’s mantra that is all too often exposed in the DevOps world, but many of the most talented engineers I believe do crave a hero status. They derive a lot of their self worth from the work they produce and consider themselves a snowflake, even if their servers aren’t. They write complex scripting frameworks in Ruby or Python and are attracted toward complex and powerful tools that they enjoy using, engineering themselves into a position where they derive brent-like satisfaction and create some job security. I’m not necessarily being to critical of such an approach, but I do find it guiling that at the same time believe they are part of a cultural revolution.
But do the engineers know best?
I think it’s hard to argue that, certainly if compared to 10 years ago, that the broader influence of DevOps has not only made software delivery and IT operations a much more exciting and dynamic environment to be working in—but is also delivering huge business value and competitive advantage for those organizations that have embraced it. Was culture and philosophy a key driver to achieving this? Absolutely. But much as Ben Horowitz espouses in the “Hard Thing About Hard Things,” you need a team to take a business to a certain level, and once it has reached a certain level of success it needs to be taken forward by specialists, not generalists who brought it to that point. I believe we have reached that point.
DevOps is now becoming mainstream and may benefit from being subdivided into different areas of specialization. As a startup, there is fun, excitement and a belief that you can change the world. Individuals that thrive on that often enjoy the variety in the work, performing a variety of functions within the organization—maybe some software development, support, pre-sales and marketing. But as an organization grows, specialization is required, there is a marketing team, support team, pre-sales and engineering team. This is a reality of working in a growth organization. There is no longer one team that does everything, but they are split out into specialization, collectively bringing the whole organization to a stronger place. DevOps has grown up—and needs to demarcate specializations to take it to the next level.
So how should the boundaries of DevOps be defined?
I would propose one of two things. DevOps remains the overarching philosophy of how we make the world a better place, underneath it sitting some more defined disciplines which are less related to the philosophy. So we don’t have the concept of a DevOps engineer, but instead they are roles such as automation specialist. Or perhaps, if I’m honest the way I felt when I started writing this blog is that we (and I consider myself part of the DevOps engineering community), now it has become much more mainstream, allow it to be taken forward by specialists disciplines, of which engineering is one, but the cultural, philosophical and management practices are no longer in the startup realm but need to be taken forward by the “grown ups.”
The philosophy and implementation should be separated
Ultimately, I think there needs to be some separation from philosophy of what DevOps is and the constituents parts of it. My primary reason for writing this blog, if I’m honest, was I am becoming bored of the DevOps bandwagon. The whole DevOps concept is is meant to conjure exciting and positive ideas how we can make the world a better place … but spring turns to summer, turns to fall, and successful startups turn from dreamers with passion to having VC backers or being owned by private equity.
This is not meant to be a negative point though—anyone who creates a start up ultimately wants it to go on to become a grown up. And Patrick Debois may be the founder of the startup, but DevOps is now a publicly listed company.
About the Author / Dave Sayers
Dave Sayers is a co-founder and technical services director of MidVision, a provider of Release Automation and Continuous Delivery Software. He works closely with customers and partners on DevOps and Automation initiaitves throughout Europe and North America and is responsible for devising and managing the partner and channel strategy. Connect with him on LinkedIn.
Pingback: Defining DevOps: Not Theory, nor Implementation...()