DevOps Enterprise Summit 2020 – Notes on Compliance

Last month, I was lucky enough to attend the London edition of the DevOps Enterprise Summit 2020. Like most events this year, I got to watch the presentations from the comfort of my living room even though I was planning to go to London for it. The reason this conference is particularly interesting to me is two-fold; first, because it is addressing DevOps challenges in large enterprise and secondly because it has dedicated track to compliance governance. As someone working on a compliance service in a big company, this was a perfect event for me to have a look at the industry’s trends.

So here are my notes on 3 presentations I attended, with the focus on handling compliance in DevOps.

Bureaucracy and DevOps by Mark Schwartz (AWS)

When hearing the word “bureaucracy” most of us get a bit anxious and irritated. In his presentation, Mark Schwartz highlighted the benefits of setting up rules to be followed by everyone and how DevOps help that these rules don’t get in the way of the actual work that needs to be done.

He then proceeded to make the bold claim,

DevOps is a kind of bureaucracy.

He backed it up, by noting that DevOps principles like automating repetitive tasks, align with bureaucratic benefits like: fairness – the rules are the same for everyone, predictability – if you do what you are required, you get what you need, consistency – everyone uses things the same way.

DevOps also help remove some of the burdens that come with bureaucracy, for example by getting fast feedback on the process, it is easier to adjust the rules. By creating “minimal viable bureaucracy” when automating compliance rules, we remove waste and reduce “red tape” instances.

Bureaucracy is a value stream and the product is compliance.

In summary, his message was to take our bureaucracy, automate it and make it enabling.

Low Context DevOps: 3 Ways to End Knowledge Frustration by Thomas Limoncelli (Stack Overflow)

Thomas Limoncelli framed his presentation around high and low-context cultures, an anthropology concept. You are in a high-context environment when you are supposed to know how things work just because you do, for example in family gatherings. On the other hand, in low-context environments all the rules are explicitly set out for you.

He proposed that a DevOps environment should strive to be low-context and suggested three ways to achieve this.

The defaults are how you expect most people to work, so defining them and supporting them “out-of-the-box” is something to go for. His second point was to embody and “standardise” the recommended practices for all of our tools, from the CI/CD pipelines to our bug ticketing systems. Or simply put:

The lazy path guides you to the right way.

The final point was to provide information exactly where people need to see it. Adding a URL pointing to a meaningful explanation is cheap, so why not use it? It also implies that information needs to be documented along with development, so that knowledge is shared and the context is reduced.

I believe compliance is a good candidate to lower its context. The defaults should address the company’s main risks. They should be machine readable and easy to check against. And finally, they should be easy to explain and versioned so that they are always up to date.

DevOps and Internal Audit: A Great Partnership by Rusty Lewis & Clarissa Lucas  (Nationwide Insurance)

In their presentation, Clarissa Lucas and Rusty Lewis set out to answer the question that many teams dread to ask:

How can we pass an audit when we are moving to a DevOps operating model?

Using the example of the risks that accompany the change management process, they walked us through how controls such as Approvals and Segregation of Duties can be evaluated from a DevOps perspective.

When thinking about Segregation of Duties what we usually have in mind is one human handing over to another, for example one developer writes the code and a different one reviews it. To shorten the time and efficiency of the control, we can implement some automated checks that we deem necessary for a review and leave only the critical thinking part to the reviewer. And we can go further, by logging any deployed changes and verify if they belong in a pre-approved low-risk list. In both cases, we mitigate the change management risk by automating some of the steps, thus enabling fast deliveries in a compliant way.

They summarised their findings in the slide below:

For me, the biggest takeaway and the biggest challenge is to enable the collaboration between development and audit teams. Development teams need to understand the risks to the enterprise and find efficient ways to implement controls while the audit teams need to look beyond their existing checklist and be open to evaluate them.

Some conclusions

Whether we like it or not, there are always some rules we use to build our software. Some we choose to follow and some we must. But all three presentations mentioned here made the point that having such rules is not something inherently bad. Automating what makes sense to automate, allows for more time to invest in “custom” quality for a product, which brings even more value to its users. The “DevOps Automated Governance Reference Architecture” paper (access to Forum papers), provides invaluable information on how to achieve that technically. But in the end, it’s up to all of us – developers, auditors or management- to find ways to uphold the rules in a sustainable way. And we can do that only by working closely and honestly together.