DevOps is (not) a job title (maybe)
The battle for DevOps is raging. It is a fight for the definition of the word. We crammed Development and Operations together and we all did it differently. We look different and act different. For whatever reason, there’s only room for one of us to be right.
One crowd argues that DevOps is a methodology like ITIL, PMBOK, TOGAF, and Waterfall. Therefore, it will go the way of these methodologies and be productized with best practice handbooks, certifications, and maturity assessments. The camp pushing for this approach is leading the industry to this inevitable conclusion. DevOps will be defined, wrapped in a box, and sold in seminars.
Another crowd sees DevOps as a function. It is some combination of development and operations and can be placed on an org chart as such. Most likely, this approach is secretly a cost savings exercise justified by an attractive ROI. We shall merge these two groups and capture the benefits of our new streamlined structure. When done well, this is DevOps as organizational change.
A third crowd sees DevOps as technology. The best example of this is Azure DevOps which was previously known as Microsoft Visual Studio Team Services (VSTS). You get to buy a product versatile enough to let you continue with whatever development methodology you were already using. Even a suite of products and services isn't enough. You'll want to embrace additional tools like Puppet, Nagios, and Splunk to make sure that your DevOps peers really respect your approach.
The commonality between all of these competing groups is that they argue that you really aren’t DevOps until you embrace their approach. You can’t achieve “real” change just by embracing a methodology, changing an org chart, or installing a new tool. This sounds very familiar to previous buzzword battles like cloud and big data.
Next time you see the word DevOps, ask yourself which of these three camps the message is coming from. What do they gain from winning you over to their point of view? Do they leave room for any other position?
As someone with DevOps in my title, an unforgivable faux pas for many, I’d like to leave you with the idea that there is room for more than one of us to be right.
Part of the problem is (as the name implies) your dealing with a smash up of development and operations. After all where in “Brangelina” did Brad end and Angelina begin? Seriously though, for me it’s a discipline or a focus at the intersection of two separate concerns. As such the definition will inevitably remain fluid, based on the definition and the need of the organization in which you operate.