Why is it Difficult to Come to a Common Definition of DevOps?

 

Recently we published a blog which provided a Definition for Disciplined DevOps.  In that posting we worked through the potential scope of DevOps to help gain a better understanding of what DevOps is all about.  One point that we made was that there was no consistent definition of DevOps in the industry due to various reasons.  In this posting we explore those reasons.

We see several key forces in the current marketplace which makes it difficult to settle on a common definition:

1. Specialized IT practitioners.  Many IT professionals still tend to specialize – someone will choose to focus on being a programmer, an operations engineer, an enterprise architect, a database administrator (DBA) and so on.  As a result they tend to see the world through the lens of their speciality.  Programmers will focus on the software development aspects of DevOps, operations engineers the operations aspects of DevOps, enterprise architects on the long-term planning and modelling aspects, and DBAs on the data management aspects.  Few people are looking at the overall “big picture”.
2. Agilists are focused on continuous delivery.  Right now agile and lean developers are investing a lot of effort to figure out continuous delivery practices so as to streamline the regular deployment of value into production.  Advanced teams are releasing daily if not several times a day due to adoption of practices such as automated regression testing, continuous integration (CI), and continuous delivery (CD).  As a result most of the DevOps discussion in these communities focuses on these topics, sometimes straying into other practices such as canary testing, feature toggles, and production monitoring frameworks.  Clearly important techniques, but still not covering the full potential range of DevOps.  These practices and more are described later in this article.
3. Operations professionals are often frustrated.  Many operations groups are overwhelmed already with the rate of updates being foisted upon them by development teams.  This is often exacerbated by the inconsistent use of technologies – the impact of the lack of enterprise awareness within undisciplined development teams is largely felt by the operations group who needs to support the plethora of technology platforms used by the full range of development teams.  Worse yet, the internal operations processes are often based on heavy implementations of ITIL or ITSM and have yet to be streamlined so that operations engineers are in a better position to collaborate with development teams.
4. Tool vendors have limited offerings.  As a result of this the DevOps messaging from tool vendors will focus on just the aspects of DevOps supported by their tools, narrowing the discussion to what they have on offer.  Yes, tools are important, but they are only part of the DevOps picture.  Even if there was a vendor with a full range of tools, and if they actually interoperated smoothly (yes ALM vendors, we’re referring to you), you would still need to understand how to use those tools effectively.  To paraphrase an old saying – A fool with a DevOps tool is still a fool.
5. Service vendors have limited offerings.  Similar to the issues surrounding tool vendors, service vendors are also making great claims about their deep expertise in DevOps.   Upon examination you will often find, like the tool vendors, their definition of DevOps will focus on whatever they can currently support.
6. Tool vendors treat DevOps as a marketing buzzword.  To be blunt, many vendors have taken their existing products, and started marketing them as DevOps products (regardless of how well those products actually support DevOps practices).  Granted, these products may have been very good at supporting traditional ways of working, but when it comes to supporting DevOps they prove to be rather clunky even though they may have added a few new features.
7. The DevOps=Cloud vision.  There is a lot of rhetoric, particularly coming from Cloud vendors, about how cloud-based tooling and deployment environments are critical to success in DevOps.  Yes, having a cloud-based infrastructure clearly enables many DevOps practices and given the choice we prefer to work in an environment which leverages cloud-based technologies whenever appropriate.  But, that doesn’t mean that the cloud is a prerequisite for doing DevOps.

The point is that there are several contributing factors to the lack of agreement within our industry as to what DevOps means in practice.  The implication is that when someone is giving you advice about DevOps that you need to understand the scope of what they’re actually discussing.   Another way to understand what DevOps is and how it may apply to your organization is to explore the various DevOps strategies and practices available to you, which we’re doing in other blog postings.  Please see our first post in that series which overviews General DevOps Strategies.