SD Elements | 
Training
Research
Upcoming Events
Resources
Historically, teams in the DevOps space have focused largely on automating their pipelines and technical activities. But the idea of balancing development pipelines with the business needs of risk and security is beginning to emerge. The challenge is how to implement this shift from an almost exclusively technical automation-for-speed perspective to a more business centric perspective of automation-for-balance, which includes perspectives of risk and security teams.
Constructing a balanced development automation program
There are a few things that you have to think about when constructing a program around this idea of a balanced development program. You have to consider the different layers, a focus on business objectives, and establishing the right governance controls.
First line of defense
The mandate of a development team is to create a clean build fast. Automation helps to achieve this speed. For example, developers can spin up a virtual container and start building applications within minutes in a cloud environment. They can provision a test lab and a test space and start using it quickly. Thousands and thousands of automated tests can be run to make sure the build is clean.
The challenge emerges when you only consider one perspective — speed. Did the code pass? Is it clean? Is the functionality doing what is intended? If so, then we’re done. But there is also an operational concern. Are we addressing any risks that we know about? Is the data going to flow smoothly through production systems? And so, you introduce this complexity around what has been built and tested in a purified environment and transfer that build into an operational environment. The result is often that you end up with break fix and emergency changes. Then the code developed in the first place isn’t synchronized with production. How do you fix it? The first thing the operations team has to do is clearly state the limitations. These are identified as controls or guardrails.
Now, this meets your needs from a production point of view. Security, similarly, has to equip the development team with an awareness of what’s required from a security controls point of view. The same goes for risk and compliance. There are certain guardrails, and we have to put in place and then teach the developers that developing with the guardrails is part of their job.
Second line of defense
The second line of defense is your security, risk teams that can look in and say, “Do we have adequate controls?” As the first line of defense is executing, this line of defense examines the metrics based on existing controls as well as new and emerging risks. The result may be the creation of new controls in the first line of defense. These new controls need to be injected with an understanding of impact. This impact will be based on cost and business exposure. Ultimately, it is a business decision to determine the right risk threshold.
Third line of defense
The third line of defense is our traditional audit and senior management boards. They look in from a governance perspective and say, “Let’s make sure that the business is protected and we have strong assurance.” Metrics collected from the first and second lines of defense roll up into the third line of defense. The KPIs measured at this level are based on core business concerns — compliance, resiliency, reputation, cost, and so on.
Achieving alignment
Having the three lines of defense helps you construct a program that is aligned with business objectives while constructing appropriate guardrails that govern the execution and delivery of the software. This alignment is what enables build and operations teams to execute in a balanced way to both enable the business while managing their risk.
Implementing a shifted program
Implementing a program that shifts from “speed first” to a “balanced development automation” approach that manages the right tradeoffs between speed and risk implies the following:
- Gradually start combining different perspectives. You’re going to have natural dynamic tension.
Operations teams are thinking, “Don’t mess up my approach and floor.”
The business is thinking, “I have to get stuff out the door that I must have in order to make sales happen.”
Development teams are thinking, “I’m going to build this new stuff and keep moving things forward.”
- Bring people together and focus on a common outcome. What’s the result you really want? It must be something that’s working for the business need or the organizational need.
- Recognize that sometimes you may need to sacrifice speed of delivery for a business reason. You may build it today and six days, six months, or six years from now, there’s an issue in the business that’s highly visible and the regulatory body comes down saying, “How could you let this happen?” This flow is not detected because everybody has their own narrow perspective until we start focusing on a common business objective.
Implementing this shift from an almost exclusively technical automation-for-speed perspective to a more business centric perspective of automation-for-balance, will lead to development pipelines aligned with the business needs.
