It is interesting to me how quickly the hype cycle of a good thing can turn it into a monster that will inevitably eat itself, leaving a much smaller – and much more useful – concept or toolset behind. It has happened over and over in high tech, one need only say “XML” to understand what I mean. It is definitely a useful tool for some jobs, but the “XML Everywhere” craze was insane. People declaring such patently false ideas as “It will end the need for programmers.”

Thankfully for those of us using it, XML in the enterprise is largely a data-at-rest tool for small datasets (including serialization) and a diminishing communication tool at this point. That gets the confusion of XML everything somewhat out of the way, while we try to find answers to important questions in the areas where it is actually used.

This same process is unfolding in the hype cycle of DevOps. The term no longer has any meaning, and we need to consider the implications of that fact.

Note to vendors that have invested a ton of marketing dollars in the term DevOps: Sorry you’re upset by even the premise of this post, but in the long run, this concept would work out better for you also. Read on.

Let’s just do a limited-subset recap to explain what I mean. If I say “The problem here is the need for DevOps” to you, I could mean:

• Continuous Integration
• Continuous Delivery
• Application Deployment Automation
• Server/Provisioning Automation
• Cloud Services Automation
• Enhanced Build Tools (without an eye to CI)
• Security Automation
• Full Culture Change

Or more. Or any combination thereof.

Not only are these concepts supported by wildly differing technologies, many of these categories involve completely different groups within IT.

There are not very many people out there who fail to acknowledge the usefulness of at least some of these areas, but to lump them all together seems like a massive pile of mostly not relevant ideas. For example, in my day job I use Enhanced Build Tools, and the Engineering team uses CD – while the company is focused in the server provisioning (see: Stacki) and warehouse grade configuration (see: Boss) spaces. In my side job, I use CI, CD, and Automated Testing (see: D20PRO).

The easiest task to take, and the one that seems to be happening naturally, is to take the above pre-existing categories and talk about them, adding the completely new ones like Culture Change. This is an okay solution, but we still have way too much being dumped under the “DevOps” moniker.

Perhaps a more formal approach would be useful to enterprise IT staff who are just trying to solve their problems. It could take the same view as above, but get passed around instead of wandered to at leisure.

What started me thinking about this topic was looking at Xebia Labs’ Table of DevOps Tools. While I disagree with several portions of this chart (most notably the absence of Stacki in the provisioning category ;-)), it is a better attempt than I’ve seen anyone else make.

Things that occurred to me while looking this over:

• I’ve used all of these categories at one time or another.
• Some of them don’t rightly qualify as DevOps tools, IMO (Databases, for example), though I understand why they’re in there.
• Some are accurate but poorly cast.
• But it’s an excellent list of tools. Emphasis added to avoid the bolts of flame about to be directed at me by those who’ve invested their career in the “Culture Change” part of DevOps.

The Message: STOP USING THE TERM DEVOPS
These terms are much more applicable to direct usage than the term DevOps. If you are blogging, reach your target market by saying what you are actually talking about instead of listing the primordial stew that the phrase “DevOps” has become.

The point is to get IT folks the information they need in a rapid manner. Go ahead and pick a tool category from Xebia Labs’ graphic, okay, got one? Now search on “DevOps” in your preferred search engine, and try to find an article relevant to it. We’ll wait the couple hours, go ahead, try it.

And that’s bad for everyone. Of course some small percentage of people will find what they’re looking for at the top of the search results, which people greatly depends on which part of DevOps is getting buzz this week. A few weeks ago it was CI/CD, when I just did the search now, it looks like all those people trying to define DevOps to be inclusive of 50 categories are at the top.

So stop trying to make it 50 categories. Call what you’re doing what it is. Use DevOps to refer only to culture change, which could then use the other categories. While some enterprises have a DevOps Team, increasingly you will see a subset of the Ops team using CD, or a subset of the Dev team using CD, or a mixed bag of the two using CD. So why not talk about CD and leave DevOps out of it, if that’s what you’re addressing?

I do this for StackIQ. We fit into the “DevOps” moniker, and sometimes I reference it to mention larger efforts. But StackIQ products are largely provisioning and application configuration, so that’s what I call it. Just as I wouldn’t call a cat “Mammal” unless I was trying to make a point larger than felines.

Some will be against this idea because they believe you have to do it all. I (and the available empirical evidence) respectfully disagree with this view, but calling it by different names doesn’t put a halt to execution. You can still do it all, we’re only talking about words here.

So let’s clean up the terminology, and help IT find the products/vendors/methodologies they need without having to paw through dozens they’re not interested in right now – or at all.