All too often, delivery of new software features is bogged down by things completely unrelated to creating value for a solution's customer. Others have noticed this trend and called it out as undifferentiated heavy lifting or accidental complexity. Rather than focusing the problem the app is designed to solve, delivery teams must figure out how to configure a lower level technology. If the solution is running on a cloud provider, it might be understanding how to ensure two services are working together to enable a backend API, or meeting requirements from operations and security teams.
In large enterprises this becomes even more of an issue, where teams re-solution solved problems due to communication silos and tight deadlines. This causes a massive sprawl of technologies, making it harder on the security team to have consistent controls. In general this impacts any team with a governance function (operations, privacy, audit, etc).
Having to focus on so many different approaches creates a gap in clear expectations regardless of the implementation. Without that, each engagement/review is from scratch, and solutioning takes longer (even if another unrelated team may have used the technology before).
To be clear, innovation is still important. However solving the same problem over and over and providing no additional value is wasteful. There will always be a need to push the status quo, but not every problem needs to be solved with the hot new tech stack of the week.
How do we go about solving this problem? A helpful mental model I've found is from the Security Perspective of the Cloud Adoption Framework from AWS. It defines the following components:
- Directive controls establish the governance, risk, and compliance models the environment will operate within.
- Preventive controls protect your workloads and mitigate threats and vulnerabilities.
- Detective controls provide full visibility and transparency over the operation of your deployments in AWS.
- Responsive controls drive remediation of potential deviations from your security baselines.
Directive controls are fundamental to the others, and where I recommend starting. As mentioned above, regardless of the how, a governance team removing the subjectivity of the what helps everyone. This helps scale compliance, as it serves as a reference library and does not require someone (reviewer or delivery team) to remember every rule about every technology. This helps make processes more self service, as delivery teams can start implementing without having to wait for a reviewers availability.
While that is a great start, preventative and detective controls offer more value by ensuring the directive controls are being followed. Preventative controls ensure no new instances of the violation are introduced. Detective controls help by identifying existing non-compliant instances. The implementation of these controls may take different forms, but platforms such as kubernetes, aws, azure, or gcp all offer great ways to interrogate (almost like a detective...) an environment. They also offer great mechanism around authorization to limit what actions can be taken in what scenarios. Through these mechanisms, the feedback loop to the delivery teams can be tightened. Once a rule is well understood, responsive controls can act as a backstop to ensure the environment remains in compliance.
So everything is rainbows and sunshine! Our job here is done, right? Not quite! These additional controls are another powerful step forward. However we're still letting teams trip over them as they deploy their solution, and expecting them to fix it when they do. They are still focused on a problem unrelated to the business domain they are trying to solve for. What else can we do to remove complexity from the system?
With these tighter feedback loops, delivery teams are empowered to create reference templates or reusable libraries. This can span the stack using different tools such terraform, ansible, or programming language specific libraries. These components can then be shared within an enterprise by teams trying to solve the same problems. This simplifies things a bit with the team only having to worry about the parameters specific to their instance, rather than some of the finer intricacies of the implementation. This greatly reduces time to delivery of features.
One final step we can take to simplify is to commoditize/productize the solution. Much like the diagram below we want to shift the delivery team as far to the right as possible if a different lower level is not providing differentiation.
Ultimately a delivery team should not have to worry about implementation details of the platform/product they are consuming. This significantly reduces the problem space they are trying to solve for. These platforms can be created in a such a way that a delivery team no longer has to engage with 10 different teams to create business value. This also benefits the governance teams, who's task is much easier when a platform is taking care of control enforcement. They now have more time to work with those introducing emerging technologies. From there, the process starts over again. As the list of platforms grow, there are opportunities to continue moving the line of abstraction further up to ensure it remains simple.
Although this may not be an overnight change, focusing on the unique value a team provides will keep a company competitive and generate opportunities that were previously unlikely. How many companies exist today built on top of the abstractions the major cloud providers offer? What would teams within your company be able to build with the extra capacity?
Simplicity - The art of maximizing the amount of work not done (Principles behind the Agile Manifesto)
Top comments (0)