Sometimes it is important to call out missteps even when there is good intent. Feedback is critical, and an important part of DevOps after all…
The authors, brilliant knowledge workers, amazing researchers, and well known marketers of the DevOps movement did not [originally] overload the already loaded term trying to capture acronyms for every element of the various bodies of knowledge and system of systems. Kim, Humble, Debois, and Willis did not call their book the “DevSecOps Handbook.” I wonder why?
Many of us were doing “Dev+Ops” in the early 2000’s. My teams were for the USAF and other DoD agencies. We didn’t need a name. We just wanted to lean out our systems and keep our customers happy. We were also doing lots of other things, like running security tools and following OPSEC processes. The lean movement had already crashed our party working in the logistics centers and manufacturing of airframes and engines.
There are many important parts in DevOps. The Three Ways. The toolchain and automation. The culture. A bit of Goldratt, Lean, Measurement, Recoverability. Did I mention Lean Thinking? What about Systems Thinking?
Let us say that you are in an environment that uses DevOps and are determined to point out and optimize one part of the system of systems, perhaps, “security,” in this case. In that environment security is really important. So much so that it overrides and clouds the vision of the entire system. In an effort to differentiate or otherwise mark the importance of security, the term DevOps is overloaded by including another acronym in the mix.
The problem here is the logic of this inclusion breaks one of the core values of DevOps by raising one element [local optimization] of the system unnecessarily and obscuring and diminishing other important elements of the system of systems. Quite frankly, in an organization that invests heavily in security, but ignores or under-invests in other critical elements of the system of systems they would run the risk of de-optimizing the whole. And ultimately increase OPSEC risks. Makes you wonder whether there really is a commitment to Lean and Systems Thinking or just the vanity of bifurcating [unnecessarily] an existing concept for credit?
Mark my words, the “DevSecOps” marketing movement will go down in history as a mistake and fallacy that fails to understand lean and systems thinking along with unnecessarily inflating the original concept.-Marshall Guillory
The venn diagram is wrong. DevOps occurs at the intersection of Development and Operations. We are not adding new silos and complexity, unnecessarily, to the mix.
Optimizing the whole is the best way to achieve the goals of a secure operating environment. An organization should focus on shifting everything in the traditional “V” to the left. Optimizing batch sizes. Use economic prioritization. Focus on business agility (even DevOps misses key elements of the value stream and system of systems). Break assumption based thinking and planning and get back to science.
“The DevOps Handbook is for everyone who performs or influences work in the technology value stream (which typically includes Product Management, Development, QA, IT Operations, and Information Security), as well as for business and marketing leadership, where most technology initiatives originate.”
Kim, Gene. The DevOps Handbook: . IT Revolution Press. Kindle Edition.
#devops Report this
also posted on LinkedIn. https://www.linkedin.com/pulse/devsecops-bungling-marshall-guillory