Kit Wai Chan - Fotolia
How to get DevOps into compliance, and vice versa
IT organizations that are serious about DevOps, especially with integrated release pipelines, need compliance and governance workflows that dovetail with the app delivery approach.
It's easy to think of compliance as restrictive. If you're a developer or tester, compliance is far from the most interesting aspect of your job, but it is a fact of life.
When a DevOps team wants to release a code change, it must meet compliance standards -- even if it delays release. Whether they like it or not, IT professionals must wrangle with governance processes and rules.
Compliance proves that an IT organization governs its processes in a way that meets specific standards. Compliance, in a DevOps cadence, can cause some friction, but it is a necessary endeavor.
"Compliance can sometimes feel as though it's the sheriff," said Guy Herbert, a risk futurist at Atlassian, a collaboration tool vendor. "Risk and compliance people don't often like to be like that, but they tend to get people with some of that mindset."
DevOps teams should understand the relationship between compliance and governance -- and IT management. "Governance is not management; governance is an additional control mechanism that helps keep an overall organization aligned and on track," said Charles Betz, an analyst at Forrester, speaking in a webinar, From Chaos to Compliance: The New Digital Governance for DevOps, hosted by application release orchestration vendor XebiaLabs.
There is a great need for IT organizations to change how they approach governance to enable DevOps. "The older, traditional compliance processes are incompatible with the newer continuous delivery tooling, which leads to slower delivery from all unexpected remediation work," said Dan Beauregard, VP of cloud and DevOps evangelist at XebiaLabs, in the same webinar.
Audits are painful time sinks, Beauregard said, as people must set aside their existing responsibilities to gather evidence for auditors -- sometimes delaying DevOps adoption itself out of fear of compliance control clashes.
Atlassian's Herbert advocates for an approach to auditability and standards compliance that's well-suited for an integrated, end-to-end release pipeline. In that approach, risk and compliance people don't play the role of the sheriff -- they provide advice, not mandates.
Well-performing DevOps teams should hone comprehensive compliance workflows, he added. At Atlassian, he helped the DevOps and risk and compliance sides effectively communicate and collaborate to ensure compliant code changes.
Why communication is a pivotal factor
Good governance in a DevOps setting starts with communication; compliance folks, auditors and the DevOps staff need to be talking to each other. This sentiment applies to questions about how the pipeline works, getting everyone to understand some process, and how the DevOps team obtains permission for a particular approach.
Clearly communicating the nature of -- and the ways to navigate -- existing processes can positively affect software delivery performance, according to the DevOps Research & Assessment (DORA) in their 2019 Accelerate State of DevOps Report. "Survey respondents with a clear change process were 1.8 times more likely to be in elite performers," the authors of the report said. When team members better understand how to get changes approved, such as for assessments of compliance obligations, it smooths the change management process.
The manner in which a DevOps team assesses compliance, called a control activity, determines whether or not it achieves a control objective. Risk and compliance teams should map compliance obligations to control objectives, thus meeting a shared understanding of and adherence to regulations.
Here, communication helps both parties clear up compliance issues. These should be face-to-face discussions, Herbert said. Risk and compliance teams should use terminology that the DevOps team easily understands.
Traditionally, compliance professionals like to tick items off a checklist prior to release, but they should let go of this mentality, Herbert said. It's more efficient and constructive to entrust DevOps teams with compliance responsibilities for their code changes. Risk and compliance teams should provide guidance and intervene when a DevOps team calls upon them. DevOps teams want a boiled-down description of exactly what they can or can't build and deploy. But IT people should feel like they have freedom.
"IT people [say,] 'Just tell me what to do,' and the risk and compliance people are going, 'Well, there's lots of different way you can do it," Herbert said. "The risk and compliance people, often they don't like to come in and say, 'You have to do it this way' -- the auditors absolutely don't. They like to go, 'Tell us how you're doing it, and then we will tell you what's wrong with that.'"
Betz, of Forrester, envisions a future where IT organizations automate any binary yes or no compliance checks. "And then what I think is left for [auditors] to do, it's going to have to be more advisory -- more consultative," he said.
Code ownership and peer reviews
If risk and compliance professionals take an advisory role in DevOps, IT organizations might want to foster code ownership among individual development teams. If a dev team is responsible for a service, team members should review changes to its code, as well as completely manage all related tickets and their descriptions.
In many IT organizations, change advisory boards perform these sorts of code checks -- yet they can actually do more harm than good when it comes to code quality, Herbert said. With change advisory boards in place, developers don't feel ownership of the code, and the board likely won't understand code-level changes as well as the team itself.
"We often drive it down to the individual teams," he said, referring to Atlassian's internal compliance audits. These teams know the code and what the service does, and should use that knowledge for peer reviews. "Consider yourself to be a co-author on the peer review," he advised.
The DORA report supports this idea. It found no evidence to support that formal approval processes lead to higher quality software. Quite the opposite -- it states that the introduction of more approval steps results in slower delivery, less frequent and larger release batches, as well as more risks for production systems.
"We recommend that organizations move away from external change approval because of the negative effects on performance," the State of DevOps Report asserts. "Instead, organizations should 'shift left' to peer review-based approval during the development process." With shift left, developers perform tasks, such as security or QA checks, early in the SDLC, rather than hand off those duties.
Segregation of duties
An IT control that breaks a task down into separate parts and then assigns a different individual to each component is known as a segregation of duties. In a change management context, that means code changes should be approved by a person who is not the author -- an arrangement often mandated by regulatory frameworks, according to DORA.
Also, governance models that hinge on practices like biweekly reviews and an overabundance of stage gates might be outdated, Betz said. However, he believes change advisory boards can still be useful. They can follow practices such as change credit ratings, which are metrics that capture a team's track record with change requests. A team that sees its changes regularly fail will earn a poor credit rating, Betz said. Conversely, a team earns some autonomy when changes never cause problems.
Each peer review's degree of scrutiny depends on how much risk the IT organization is willing to take with that team's service or app, Herbert said. Some teams want fast approvals, while others rely on deliberate, experienced reviewers. Determine the appropriate peer review scrutiny level on a case-by-case basis, according to the application and its compliance obligations.
Role of an integrated, end-to-end release pipeline
The payoff from a fully integrated, end-to-end release pipeline for governance processes and compliance is information, XebiaLab's Beauregard said. Pipelines collect all kinds of info, from all places in the software delivery process, for use in predictive insights and data analytics.
DevOps teams can codify and design compliance controls right into the pipeline, and automate as many processes as possible. Risk and compliance professionals want to know how code release pipelines work, Herbert said. At the same time, DevOps professionals want to know how compliance can work in one. He tells both sides to talk more.
