Complexity Management and Security Compliance: 7 Deadly Diseases of DevOps

In the final segment of our blog series, we explore the remaining DevOps Diseases, “Managing Complexity” and “Security and Compliance Theater” and how they hinder IT organizational success.
Dealing with complexity management within an organization is a tricky business and can be approached differently to better serve security compliance standards. What might result in the best outcome is returning to the fundamentals instead of over-engineering a solution to address complexity management. John Willis (CloudBees advisor and co-author of The DevOps Handbook) pulls out examples in hopes of helping companies uncover room for improvement.

Willis and Anders Wallgren (CloudBees CTO) share their past experiences while presenting a potential solution for the 7th disease -- Security and Compliance Theater. Calling out a company based on its current organizational structure can be a touchy subject but will eventually be beneficial for the industry in the long run. Audit requirements are difficult to achieve or maintain and it’s hard for companies to prove they have adopted procedures. Many enterprise companies have limited visibility on security compliance standards. To the surprise of no one, it is almost certainly not a continuous process.
Before we dive further into the last two topics in our series, watch the full DevOps.com webinar on the “7 Deadly Diseases of DevOps“ . For those that missed previous topics in this blog series, check out these quick recaps of each of the seven DevOps “diseases”.
1) Invisible Work
2) Management System Toil
3) Tribal Knowledge
4) Misalignment of Incentives
5) Incongruent Organizational Design
6) Managing Complexity
7) Security and Compliance Theater

Deadly DevOps Disease #6: Managing Complexity

Mike Ross’s Toyota Kata book is the reference point that Willis uses as an example of complexity management and uncovering room for improvement. “My weapon of choice here is the improvement in Kata mostly coming out of Toyota and specifically from Mike Ross’s Toyota Kata book. However you deal with complexity management - whether that's blamelessness or complex systems that have all emergent properties - this is very simplistic because we’re running out of time. It’s implying the kind of meta-skills of scientific thinking or a scientific process.”
Diving into the steps to make this happen, Willis calls out the Deming Cycle as a reference uncovering the main insight for complexity management. “It’s best described by the Deming Cycle (also known as PDCA Cycle), which entails; plan, do, check (study), and act (adjust). If you treat everything as a plan, you can have strategic actions moving forward. Everything will turn into an experiment and that allows you to kind of uncouple blame and the fear of failure.”

Deadly DevOps Disease #7: Security and Compliance Theater

Willis also shared his past experiences when consulting enterprises on complexity management and specifically, security and compliance. “Now, I’m able to go through what I’m loosely calling organizational forensics. The number one disease, is not capturing work. And, bookended by the number seven disease, which is where I’m able to show the CIO that what they’re doing in security compliance, risk, GRC, governance risk compliance is just flat-out theater.”
Diving deeper, Willis explains, “At this point, there is a 50-50 chance I’m not going to get any follow-on work. They’re furious and mad because I’ve uncoupled the way they work. I tell them, you can bring risk assessment teams in or just go talk to the edge for about two or three weeks and you will find that the edge thinks he or she is attesting to internal auditors and the external auditors are disconnected. I called this edge to audit.”
Willis finds that a lot of companies he works with cannot accept the truth that he uncovers, “The thing I hear most often is, ‘I believe everything else you uncovered in the study is accurate. I know we’ve got a lot of work to do but, I can’t accept this as truth.” That is when one of the executives explained that they don’t tell auditors things they don’t already know.
Exploring his main point more thoroughly, Willis ruminates on why looking internally is important to achieving DevOps success. The main point being that many leaders are just not asking the lower-level because that seems redundant. “A hypothesis where I’ve started gathering some evidence points to the idea that unless an organization goes deeper in the discovery process, there is a brick wall somewhere that you won’t be able to get over in order to unravel some institutionalized aspects of knowledge work in an organization.
He further emphasizes the importance of having insight into your company for future success. “No handbook is going to describe this scenario of one team saying it takes eight hours and the other team that says one hour. Put these teams in the same room and discover that all the obscure downstream dependencies of certain scenarios in the organization actually had to be manually implemented for the automation pipeline to work, but nobody originally understood that.”
Wrapping up the discussion and the series as a whole, Willis offers a final piece of advice to industry experts in hopes that it will continue to move the DevOps needle forward. “What we’ve got to be able to do as ‘experts’ is to challenge ourselves. There are these kinds of archetype problems that go way deeper than anyone actually can describe because all the challenges we face generally as an industry are also so very unique to a specific environment or organization.”
For more insights into the Seven Deadly Diseases of DevOps, watch the full webinar .
CloudBees is now part of the CloudBees family! Learn more about why CI/CD and Release Orchestration is better under one roof.