We hear a lot in the industry about the importance of automation in DevOps to enable speed. However, there is another element that is often missing in the discussion – risk, compliance and security. Traditionally we have a zero-sum approach, where we need to either go fast or be safe and secure. It’s one or the other. Or, maybe not! There is an 80%-80% middle ground to consider. Balanced development automation is a natural evolution of DevOps; it is not just about the technical side anymore, but also includes the risk and the compliance side, as well.
Aligning Executives
How do we get business executives and risk executives, at the strategy level, to align on this idea of balanced development automation? First, it is important to realize that what represents a risk for businesspeople is different than the risk that’s perceived by the development group.
For example, let’s say there is an urgent requirement for some sort of additional business functionality in response to competitive action, or even in response to a pandemic. From a business standpoint, risk might represent a failure to deliver an effective solution within the particular timeframe required. From an IT standpoint, concerns about risk are likely going to be different from the business risk.
That being said, it’s a futile exercise to convince business management to think in terms of perceived IT risk as opposed to business risk. IT must be able to translate the risks of their development work into business risk, or management may not see the potential impact of that risk. And so, pressure remains to “Get this thing done as quickly as possible!”
Even at the executive levels, there is a discrepancy in identifying what risk really is. That is true at similar management levels at different organizations, even within the same industry. Let’s look, for example, at the whole issue of security and how much effort we should be paying to validate the security of a system that we’re putting in place, or that we already have in place. If an organization has experienced a breach, they are much more likely to have a management team that is concerned about security. In a different organization that has not seen any security breaches, they may not be paying as much attention or making the appropriate investments to make sure systems are secure.
Aligning DevOps and Security
We also need DevOps engineers and security engineers to align at the tactical level. So how can these teams, that are typically at the program or project levels, integrate and think about balancing development speed with risk and security? Operational teams are very important in achieving balanced development automation. If we look at the risks from the perspective of the development team, it doesn’t matter what technology you’re using to develop an application, or even if you’re implementing someone else’s application.
From an IT standpoint, one of the most likely risks is failure to deliver functionality of the particular project that you’re doing. That is an example of delivery risk, which senior management is very concerned about. The way that tends to manifest is in delayed delivery or allowing the business to change their mind during the particular project. The risk of not delivering the functionality that’s required is increased. The process is just going to crack simply because the project has not been managed effectively, requirements were not stabilized or adequate testing was not done.
That is an extremely high risk that development groups need to be aware of. A development group needs to apply some type of balanced methodology and minimize the likelihood of a gap between the expected outcome of the project and the actual outcome.
Demand for Balanced Development Automation
Today’s business context demands both speed and some awareness of risk from development teams. This will only be achieved through alignment at the executive level and at the tactical level. Focusing on areas of business risk are essential to achieving this alignment.