Those who talk a lot about DevOps, particularly those who talk a lot about culture change, sometimes gloss over or “think it is obvious” that some roles change more than others when moving from Dev and Ops to DevOps.
I was having a lighthearted chat with a friend who works for Compuware and realized that, even though several of us have mentioned it before, it bears repeating for those who have not yet dipped their toe into the DevOps pool too deeply.
The driver for DevOps is increased agility, and the belief is that Dev and Ops will merge. What is often left unclear is that they may well merge into one team, but every team member will not become an expert at every role. Pundits seem to think this self-evident. I’m not so certain it is, if you read a lot about DevOps.
By way of example, your Cisco ACI specialist (or ios specialist) will not suddenly become an expert in the intricacies of your development toolset and environment so they can contribute code. Granted, that is an extreme example, but there are two reasons why someone is a specialist in what they do: 1. They know/prefer it, and 2. The company had a need for their specialty. Don’t lose sight of those facts while moving to DevOps.
A better example is DBAs. They’re not going to become network engineers just because they were put on a DevOps team. They’re still going to be DBAs … because you need DBAs. You need network engineers also, but if you need them, you already have them.
Remember that increased communications and increased latitude are the social aspects of DevOps. The DBA is still a DBA, but faster access to queries and those people writing the queries means more optimization of some of the busiest sections of code. If your EMC specialist has access to the entire team, conversations along the lines of, “We’re running low on disk on LUN X, and it will cost us a billion dollars to upgrade, what are our options?” can happen quickly and include views from across the DevOps team (normally across the application or application portfolio).
One of the most thankless jobs in IT is being the single/small shop. Anyone who has been IT for an entire org—particularly one with in-house apps—knows the struggle. My time as a developer hired to work on list serv software but who also inherited the entirety of systems administration (the sys admin quit and changed all the root passwords the day before I started) was not optimal. I learned a ton, which was cool, and I never mastered most of it, which was not.
The goal of DevOps is not to re-create that environment in a team. It is to optimize team interaction, and make things go more smoothly. Make sure you are not on an implementation plan that leads to burnout or lack of accountability. Keep your eye on the real prize: increased responsiveness to business needs.
And as always, keep kicking it. I have yet to walk into an environment that wasn’t unique, or one that didn’t have cool stuff to learn about. And you keep that running.
