Cult of the Bolt-On Job Functions

DevOps is taking the world by storm, and has spun off a multitude of marketing buzzword imitators which ride this new wave of portmanteaus. DevOps gave way to ArchOps, TestOps, DataOps, WinOps, DevSecOps, DevTestOps, and more. The problem is that all of these are pointless and a giant red flag that managers do not understand DevOps let alone Dev and Ops and how they relate to managing IT systems.

In the beginning...

Development was operations. Circa 1950, the people building the program were the same people supporting the program. As programs became more useful and left the gilded halls of academia and government, businesses needed people to run the programs that were built and purchased. Very few businesses were in the market to support massive R&D departments with massive computers costing $100,000s, as well as the team of programmers to support them.

This is the schism that separated development from operations, and justifiably so. System operators didn't need advanced degrees in logic and electronics (before computer science was even a term), they just needed documentation and a phone number to call to bring in the cavalry when they hit a brick wall. It was a wild time that continued through the 80s. Buying software was more cost effective then finding and paying for programmers. But the 80s and 90s brought in a wave of programming languages with the commoditization of the internet and the ability for ambitious youth to learn programming and computer systems without massive university or corporate mainframes. This was the world of the waterfall...

And along came DevOps

The Agile manifesto was written in 2001 pulling in ideas from business operations like lean manufacturing and Kaizen into software development. 2003: Ben Treynor Sloss was hired, and eventually started the SRE movement within Google. 2009 came and went with the first conference named devopsdays and separately at O'Reilly's Velocity Conference, Allspaw and Hammonds gave their now-famous talk "10+ Deploys per Day: Dev and Ops Cooperation at Flickr." Waterfall was out, and agile was in, and now technologists and builders were seeing the logic in merging development teams with operations teams and cross-pollinating the knowledge sets. Of course many in management completely misread the situation and thought they could build DevOps teams and hire one person to be a developer and operations. Twice the work for half the price. We see this disconnect today in outrageous job postings for full-stack engineers with mastery of each job function for a team of 1 to 3 people total. Or we see slim (some would try and call them "lean") DevOps teams, that are understaffed, and overworked with no hope of a healthy deployment cadence and mounting tech debt

The buzzword of DevOps took off and not long after, others started looking at portmanteaus as a way to carve out their own fame and genius. DevSecOps came into existence around 2015 as a way to shoe horn Security into the process, and more recently DevTestOps is starting to show it's ugly head.

Bolt on job functions

The problem with this train of thought, which is a perpetual problem with how businesses have been thinking about security in general, is that if you are adding security, testing, etc. after the fact, then you are doing development wrong. Security is already in development whether you are aware of it or not. If you are unaware, then you are doing security badly; a performance score of zero (0). Your software will be deployed insecurely, with a ton of bugs, and just courting disaster. If you are developing without already doing testing, then you are doing testing wrong. All of these job functions go hand in hand in order to build the best software. The idea that these functions are separate is a misunderstanding of the job functions, and the old way of thinking that you need a separate team, in their own silo, doing that job function. As we have seen with DevOps, expecting developers to manage and operate their own solutions exposes many of the problems in programs and encourages the developers to prioritize those changes. Teaching Ops to contribute to the solution and write their own code to solve their problems adds new features and functionality without waiting, and introduces a different mindset when looking at problems.

DevOps done badly

There are way too many companies that just throw the dev team and the ops team under the same manager and call that DevOps. DevOps is not about management hierarchy, it is about a shared knowledge set and shared processes. It is about teaching developers operations and operators development. What was originally separated by cost restrictions, is finally being re-joined with better technology and techniques. Individually each DevOps engineer will have their own focus to excel at. You will still have your rockstar developer, and your grizzled operator, but now they are aware of the other side, and able to perform the other's job function adequately. Not masterfully, but enough to understand the problem spaces of both, and to contribute when needed. DevOps is about finally tearing down these artificial walls that were erected in the 60's and 70's, and becoming an actual team that can accomplish great things, not doubling the workload for one person, and expecting excellence in both areas.

And then there is security

Security teams had their own evolution in business. Before the 80's, real security was seen as the domain of the government. As computers became commoditized, more people could afford to experiment and found security lacking in a huge way. The first hackers to break into the business world reveled in their outsider appeal. Eschewing business norms for black hoodies and a puck rock mentality. The emphasis on breaking instead of building was solidified into the zeitgeist of security professionals, the disservice of which still vibrates throughout the entire industry with a rockstar appeal on penetration testers and red teams, while exclaiming how everything is utterly broken.

Security is not a separate team. They are very much apart of ops. Just as the function of testing is very much apart of development. Automating testing is not anything different, just the continuous evolution of the function of testing. Your security team uses the same logs that the ops team uses; uses the same authentication mechanisms; same network; same databases. Automating your security is also nothing new, but the continued evolution of security. Separating your security team from operations is a grave disservice to the operation of your environment and sews distrust and entrenches silos of power between teams.

Put away childish things

The way forward is to unite towards a common goal.  To build requires one person. To build the best requires teamwork. Security, quality, scalability are best when planned from the beginning. Failing to plan is a plan to fail, and this industry has had enough of that already.