If there was such a thing as a “DevOps” or there is a “DevOps” business unit, the game is already lost.

If a “DevOps” is a person or job title, that person then belongs to some group or function in the organization.

If there is a “DevOps” business unit, that is yet another silo to interact with.

So what is “DevOps”?

DevOps is a description of culture and patterns for delivering business value through technology.  DevOps belongs to the business, not any one particular function.  

A key concept in DevOps is systems thinking, which includes applying business requirements to the technical challenges.  Systems thinking requires you to step past the servers and infrastructure (for us sysadmins), past our IDEs and product backlog for developers, past our remediation checklists for security personnel, and past the spreadsheets for the business folks.

DevOps helps transform organizations that buy into the concept that the success of the business relies on everyone working towards the same goal.

Why write this?

There’s an article in Gigaom about “Does DevOps Leave Security Out In The Cold” which I saw float by on Twitter.

The article gets down to a point about who owns the responsibility for applications and infrastructure being secure.  

The article quotes Brian McCallion as stating that the solutions architect should be responsible for security, not the “devops”.  The solutions architect should be part of the DevOps flow of the organization, not standing apart from it.  That’s antithetical to the purpose of DevOps.

In regards to the specific comment around security, security should be baked in as part of the workflow.  If you have an automated process for deployment, you should consider baking security testing into that process.  If you have automated infrastructure deployments, integrate some security baselining and make sure your deployments are pushing out patched systems.  Security is not some separate silo that needs to exist, it’s part of the ongoing workflow.