Shifting left was a term created by Larry Smith in 2001. It referred to the software engineering lifecycle. At the time, it was normal to build everything, then test everything and then release everything. Larry Smith argued that it is best to bring testing to an earlier point in the project pipeline, hence shifting left.
From here, things started to get interesting. In 2007, DevOps came together as a movement. A clear consequence of DevOps was bringing deployment earlier in the project pipeline, in other words, shifting left. Around 2015, security got into the fray, which gave birth to DevSecOps.
The trend is clear. More and more items were taken out of the hands of specialists, who were turned into enablers (more on this in a moment) and were put into the hands of engineers, who had to rapidly become generalists.
So, Why is This a Problem?
Let’s first consider a traditional approach to software engineering. The developers build the entire iteration. The testers test it and find bugs. There is a lot of back and forth. Then the security team analyzes and the databases team builds queries and stores procedures before the ops team pushes it to production. This has the massive drawback of big batch engineering.
Smaller batches equal better flow, and better flow equals more predictable software delivery. Therefore, we need to break down our work into much smaller increments. However, now, instead of the testing team dealing with one large request, they are inundated with dozens of requests from every application team that builds a different component of the system. This in turn will rapidly become a bottleneck.
The Bottleneck Problem of Specialists
When there is only one person who knows how to complete a task, as an organization scales, that person will become the main constraint on productivity. They are known as single points of failure (SPOF). They need to be in every review, present for every release and are a key part of any design session.
Specialists are crucial to an organization, but their inability to scale themselves is a huge problem, which is driving organizations to focus on generalists for the cost-saving potential (one person can do five things) and the promise of flexibility and therefore a lack of hard constraints. This isn’t a bad strategy, provided you don’t have any specialist requirements. But as the saying goes, you don’t know you need a plumber until your house is flooded.
From Specialist to Enabler
Team Topologies outlines four different types of teams, one of which is the enabling team. This team removes blockers and makes it possible for teams to go live. How they do it can be broken down into a few options: Facilitation, collaboration or ‘X as a service’. In this, we can see the fertile ground-for-a-platform mindset.
Without a platform, we are a group of individuals with specialist knowledge, all seeking to collaborate and, therefore, constrained to the pace of our slowest link. With a platform, we are each building solutions to force multiply our presence in the organization. Our goal is to amplify the impact that our knowledge has. What does this look like?
From Operations to SRE
Rather than an operations team that knows the quirks of deployment and handles it all personally, an SRE team builds solutions that make it possible for teams to deploy safely. They implement guard rails, deploy testing strategies, build self-healing mechanisms and more. All these things make it as if they were in every team at once.
From InfoSec to SecOps
Instead of an army of clipboard-wielding employees, whose job it is to police the activities of the teams, it would be more effective to have a collection of compliance and engineering-minded folks, who are constantly looking for vulnerabilities, consulting in teams, building features and contributing into the shared platform. This, again, greatly increases the team’s reach and cuts down on the number of meetings necessary to ship a product into production.
A Classic Example
Let’s picture an organization that runs Kubernetes. There are security professionals, operations professionals, engineers and more. Rather than working in a silo, demanding meetings of one another to ensure compliance with a framework, they collaborate on creating a pipeline. This pipeline ensures a few things:
- All code has a minimum test coverage (typically 80%)
- All dependencies are free of known CVEs
- The code itself does not have any known vulnerabilities, like an SQL injection attack
- The container file does not contain any CVEs or it is an image from a pre-scanned
Then the application is deployed using a shared helm chart, which has another set of responsibilities:
- Network policies ensure that only the necessary ports are open
- Taints, cordons, affinities and node selectors are defined to ensure this workload runs on the correct server
- The application has a health check that is used for liveness checks
- The application has a HorizontalPodAutoscaler to ensure it can scale to meet
Rather than endless meetings to ensure compliance for every release, each stakeholder team must build confidence in the helm chart. This confidence translates into trust, and that trust unlocks a whole new level of collaboration.
Shifting Left Needs Force Multiplication
If you want to shift your processes left, reducing batch sizes and improving flow — then the challenge you need to maintain is this: How do you keep the rigor of specialists when things are being run by generalists? The answer is a platform.
Platform thinking transforms a thousand meetings into a few hundred lines of code, and if you wish to shift left without sacrificing the insight and wisdom of your specialists, it is the only way to ensure that every team benefits from their knowledge without undue constraints on their ability to deliver software.
