The term DevOps is well known by now. It was initially introduced by Patrick Dubois a Belgian IT consultant who organized an agile oriented event in October 2009 and named it DevOpsDays, targeting not only developers but also systems administrators, managers, and toolsmiths from all over the world. After the meeting, the discussions continued on Twitter with the hashtag #DevOps.
DevOps and the growth of the combinations and derivatives
With the rising acceptance of DevOps, more people jump to give their definition of DevOps. The various definitions of DevOps that go around can vary, depending on what aspect(s) of DevOps you want to concentrate.
In the last article, I wrote about how to describe DevOps in 5 letters – CALMR or CALMS i.e. CALMS framework for DevOps CALMS model some other definitions tend to concentrate primarily on the automation aspect, ignoring the Agile foundation.
As a value, you get the first combination of DevOps, named BusDevOps or BizDevOps. There are various interpretations of what BizDevOps really means.
“BizDevOps, also called as DevOps 2.0, is a technique to software development that inspires developers, business teams and operations staff to work together so the company can create software more quickly, be more approachable to user request and ultimately maximize revenue.”
This definition accepts that DevOps is basically technology-driven creativity that hardly involves business people. But as described earlier, the base of DevOps is culture, which goes back to the agile practices. And we all understand that agile without business is only indicative.
Furthermore, DevOps is concentrating on a single system or application whereas BizDevOps is concentrating on the total enterprise with all its difficult processes and the combination of applications and systems that support these difficult processes.
Considering this article, BizDevOps offers an answer to dealing with:
These aspects can be tackled by defining proper value streams and Agile Release Trains that deal with all the links and dependencies between these systems and applications. I don’t see the need to come up with a different term.
I think you recognize by now that I am not a big fan of the BizDevOps term and the misperception it makes. But it can get worse. It was expected astute tool vendors that came up with the term DevSecOps. And if it is not the tool vendors that created it, at least they were so talented to jump on the cart to support the need for more security awareness in DevOps.
Currently, big tool vendors using the term DevSecOps as a replacement for of DevOps. Here is my thinking on this: security should be an essential part of DevOps. It should be a part of the culture: Don’t only think about what something functionally should do, but also what can go wrong (think Abuse or Misuse cases). It is also a part of the automation.
All security associated tests should be automated as much as probable. Think about scanning vulnerabilities in your own source code, vulnerabilities in external libraries that you use, scanning your container images for vulnerabilities, or even – up to some extent – automated penetration testing.
It is also a kind of Lean principles: when a security test in your build structure fails (e.g. Cast an eye over your source code discovers a complex vulnerability), you stop the line. So again, this is no cause why the term DevSecOps should exist at all.
Now that we have security and business covered, we can go further and see who else could feel unused to or at least ignored? Maybe DBA’s? Or any other person involved in data management? Maybe, that is the purpose why we also have DevDataOps currently. I could go ahead for a while like this. But you get the point by now: it is useless