Shame on you!  Yes you, because there is a good chance you are thinking about DevOps all wrong.  If you are a developer you might be thinking DevOps means IT goes away and you control all the infrastructure.  If you are from IT you are thinking that DevOps is just automating what you already do, more.  You’re like a seagull from “Finding Nemo”, trying to claim ownership of this DevOps thing. “Mine!”.  And both of you are wrong.
There is one thing the experts agree on.  DevOps is not tools, it is not people, and it is not process.  It is all three.  However it’s easy to fall into a trap when you start talking about DevOps.  And to my disappointment a lot of the recent chatter has done so.  Many of the articles about DevOps reference it from a world view of either the developer, or the IT manager, but rarely both together.
Organizations who approach DevOps as simply the combination of two departments, will result in the same major struggles that DevOps is trying to prevent.  Developers will throw code over the fence to “DevOps” who is slightly closer to them than before but still IT.  And DevOps ( really just IT with a new name ) will maintain the budget control without feeling the developers pain. These are the same problems that got us into this mess to begin with.
Just read this article “Is DevOps Killing the Developer?” which highlights a very real risk of Developers being spread too thin, but in doing so implies that DevOps is a developer job.  Or the countless articles that compare DevOps to ITIL.  If you know what Information Technology Infrastructure Library (ITIL) is, I’m sorry. But what it is not, is an anchor for DevOps, because all ITIL practices do is encourage the divide between IT and Development, and bloated IT teams to manage it.
Simply put, if you end up referring to the developer or the sysadmin as independent units in a conversation about DevOps.  Your doing it wrong.  Because DevOps, is about blending the two onto a single spectrum.  Rather than creating more connections between the two separate units.  Just as some individuals in development teams are working on back-end vs front-end functionality.  Some of the individuals on the team are working to automate the delivery, testing, and measurement of the applications.  And while those individuals very often have  a deep understanding of infrastructure.  They are not IT.
I can offer some suggestions for organizations to do it right
- Change the reporting structure.  Do not give IT the budget authority for DevOps.  Nor should it belong solely with an R&D manager who has no control over infrastructure.  The Development team should have it’s own budget, a transparent way to allocated it to tools. While MANY of the DevOps tools out there are open-source there are some great ones that are not, and many reason to choose these.  So give the development team the ability to procure tools they need quickly without having to re-explain the need to five other department managers.
- Do not encourage fiefdoms. If you allow any team to build castles they will do what they can to protect them.  Even if it is not in the best interest of the organization.  One way to prevent this is to give everyone the same goals.
- Create a subset of individuals in the team that have full visibility. Visibility meaning they know all the people, the tools, and processes that are used to build the application. They will not tend to have detail on any one aspect, but know the current state of all components.  The challenge of the new heterogeneous organization is that with a whole bunch of people who specialize at individual tasks, it’s hard to have anyone who gets the whole picture.  But without the holistic point of view, it’s hard to be deliberate about any changes to the tooling, team, and processes. Organizations can, without over empowering, have a handful of individuals whose responsibility is to understand all aspects of the development at a high level, and current state of things. They should serve as facilitators for the rest of the team.
I like to think of the structure like an Atom. Â The Atom itself is a solitary unit. Â At it’s core is the nucleus power house, and around it are the electrons that are the team members. Â The number of which depends on the size and complexity of the application they are working on. Â Without the entire structure they would all go flying off and add no value.
DevOps is not something IT and development teams should be fighting for ownership of. DevOps is not about protecting anything but the quality of your applications.  It’s actually about the opposite.  Breaking down the walls.  Tactically this equates to flatter organizations of talented people.  And the talent is applied where it is needed, for example the orchestration expert does mostly orchestration, and the database expert does mostly databases.  When one of them benefits the application the whole group wins.
While future DevOps teams will consist of former IT, Development, or QA individuals.  Once they are on the team, they can no longer be branded as one of these.  For IT, DevOps is not a modern version of what you are already doing, and for developers it’s not a way to replace IT.  It’s actually a new set of tools, and a new group of people, everyone with the same goals. Imagine that!
