Aligning security and delivery at a strategic level is one of the most complex challenges for executives. It starts with an understanding that risk-based thinking should not be perceived as an overhead or tax, but a value added component of creating a high-quality product or service.
One solution is balanced development automation, which is about aligning automated DevOps (development and IT operations) pipelines with business risk and compliance. To attain this, alignment must be achieved between risk and business teams at two different levels:
1. Strategic level (CEO, COO, CFO, CRO, CIO, DPO)
2. Operational level (DevOps engineers, risk engineers)
The strategic level is more focused on delivery of business value, customer needs, risk, regulations, compliance, and so on. The operational level is focused on aligning to governance protocols like risk thresholds, delivery timelines, and automation during the build phases of business value creation.
Achieving alignment at the strategic level
At the executive level, both sides of business and risk need to concentrate on quality first – only then does it make sense to go about balancing risk and speed. Otherwise, risk and speed wind up as the only concerns and that risks poor quality showing up in products and services at the end of the line.
The end of the line in any process is where the actual customer that receives the value from a product or service experiences the touchpoint with your portfolio of valued items. It is there that perceived value needs to have the appropriate operational indicators. Some refer to these as customer-driven metrics. These are the ones that can measure Operational Key Results in alignment with operational risk metrics.
Once executive alignment is achieved on quality, the next step is to measure against key strategic customer metrics like attrition and satisfaction. This gives an indication of the value customers receive from a product or service. Organizations should think about appropriate high level metrics and measurements at the end of the development lifecycle, risk thresholds, and how these map to their customer. I consider these as the “parent” metrics.
After that, consider “child” metrics in the plan, delivery, and operation of DevOps – from here, governance and speed will come into play. A key problem today is the self-attestation audit activity at the end of the line process, which is hard to validate. This just doesn’t integrate well with a DevOps process because the measurement is reactive and coming too far down the pipeline. Worse yet, going back and fixing risk issues later on gets perceived as getting in the way. What needs to happen is a shift to the left of the development process where risk is measured early and often.
As organizations evolve into a more digital set of processes, this shift left is critical to understanding those key measurements from the beginning of the lifecycle. Otherwise, junk at the beginning will just automate junk faster all the way down the line. Eventually, there will be a higher price to pay for poor quality.
Achieving alignment at the operational level
Operationally, challenges stem from misalignment in understanding who the end customer really is. Companies often design products and services for themselves and not for the end customer. Once an organization focuses on the end user and how they are going to use that product and service, the shift in thinking occurs. Now it’s about looking at what activities need to be done to provide value to that end customer.
Thinking this way, there will be features, functions, and processes never done before. In the words of Stephen Covey, “Keep the main thing the main thing”. What is the main thing? The customer. What features and functionality do you need for each of them from a value perspective? And you need to add governance to that.
Effective governance ensures delivery of a quality product or service that meets your objectives without monetary or punitive pain. The end customer benefits from that product or service having effective and efficient governance.
That said, heavy governance is also waste. There has to be a tension and a flow or a balance between Hierarchical Governance and Self Governance where the role of every person in the organization is clearly aligned in their understanding of value contributed to the end customer. With that, employees and contractors alike feel empowered and purposeful in their work and contributions.
Once the customer value proposition is clearly identified, organizations can identify how day to day operations contribute value to that end customer in an efficient way. This is where lean thinking helps, looking for ways to reduce waste in the value creation process. If something is not a part of the value proposition, is it necessary? If something is missing that would add significant value, how can we add it? This will lead to an alignment that drives value creation.
Conclusion
Delivering on DevOps speed is no longer good enough. Organizations also need to balance the need for speed against regulatory, compliance, and security concerns—and we need to do this fast and first. If a firm can’t get there fast through re-structure of an operating model and associated skills, it is best to have SCRUM Masters trained in LEAN and Six Sigma, TOGAF, and assorted Cybersecurity GRC Frameworks to helps you through iterations. I call that the big “Iterative, Fast and First” (IFF) principle of GRC by Design.
Are the activities an organization is conducting offering something of value to the business? Answering this question has implications for both strategic and operational teams. The business value context sets up alignment with the end customer and drives value at each stage through balanced development automation.