8 Real-World Reasons To Adopt Platform Engineering
There’s a clean, academic version of platform engineering. When we detect an increase in burnout as we scale and trace it back to cognitive load caused by software delivery and infrastructure complexity — bingo! — it’s time to add platform engineering.
But this neat and tidy path to adoption doesn’t match reality. The reasons for adoption rarely fit the cognitive load category, and understanding motivations for platform engineering in the wild will help those considering its adoption.
This topic is under active investigation, and I’ll outline what we’ve learned so far. Please also consider joining in by submitting a response to our short questionnaire.
Who Drives Platform Adoption?
An internal developer platform (IDP) may serve the needs of many business units. You might find ways to streamline governance, risk and compliance requirements, or help finance with cost control. However, the drive for IDP adoption almost always comes from developers and technology leaders within the organization.
The Top Drivers for Development Teams
Tool Consolidation
Your tool chain is more likely to become fragmented the further you scale your development organization. With many teams, discovering the needs that trigger tool selection can happen at different times, and without the knowledge that other teams have already solved the problem. Capturing and sharing decisions with other teams is hard in a large organization. You might also add teams as part of an acquisition, and they often bring their unique tools into the mix.
Whatever the reason, the need to reduce the number of tools that solve the same problem is often an inciting factor when development teams look to platform engineering.
Sharing Good Practices
Converging on a set of good practices is another popular reason internal developer platforms are built. Most development teams will share a set of requirements around security, compliance and cost control that can be solved by an internal developer platform. There is also the opportunity to create blueprints for good practices around source control and deployment pipelines.
As these practices become table stakes for professional software development, developers are keen to use platforms that make it easier to achieve them.
Reducing Duplication
Developers often find that other teams are inventing solutions to problems that they have already solved. They want to spend less time reinventing the wheel and more time working on feature development.
The nontechnical aspects of these solutions may be the crucial area of platform engineering. Creating golden paths simply adds another solution to the existing pile, so communicating the benefits will be as important as creating a great developer experience.
Shipping Early and Often
Though continuous delivery has many benefits, developers love it because it makes their work more satisfying. It feels good to get your changes to users quickly and safely. When you never have a large-scale merge, work in small, understandable batches, and can perform stress-free deployments, you no longer dread coming to work on a Monday (or deploying on a Friday!)
The Top Business Drivers
Process Consolidation
The theme of consolidation continues when business leaders look to platforms to reduce process differences across development teams. This subtly differs from standardization, as it’s not about forcing teams to adopt identical working practices. Instead, platforms can ensure that crucial process elements are achieved.
To illustrate, it wouldn’t matter if one team used scrum while another used kanban: The internal developer platform would ensure the same policies were applied to changes as part of the deployment pipeline.
Speed to Market
Business leaders are also looking to platforms to improve speed to market. But while developers like shipping early, often because it increases job satisfaction, business leaders like responsive software delivery for different reasons. Features can be tested with users sooner, and fixes can be applied without a special process to expedite them.
Solving Problems Once
A large organization is likely to have solved the same problems many times in different ways. If you could put a monetary value on these efforts, the platform would likely pay for itself by eliminating that duplication. When every team is tasked with solving deployment pipelines, infrastructure automation and other shared concerns, it can add up to years of lost feature development.
That’s why business leaders want to create a future where these problems are solved well — and solved once.
Improve Reliability
One of the challenges for modern tech leaders is recognizing when things go well. In the past, individual skill in resolving critical situations was well rewarded, but we should now be rewarding setups that don’t require heroic behavior. If your deployments are stress-free and your application doesn’t regularly collapse, this might be your reminder to recognize the team’s efforts.
However, reliability is also a key reason business leaders are considering platform engineering.
Familiar-Sounding Needs
The business and technical motivations for platform engineering echo the same needs. Everyone wants to deliver software sooner and consolidate tools and practices. A platform that considers these needs will likely achieve further benefits, even if it was motivated by other factors.
You’ll need to normalize your technology stack before automation and self-service will be successful. By reducing the landscape, you reduce the complexity of improving and automating what remains. If you skip past the normalization stage, you simply shift the burden from the development teams to the platform team.
The forced standardization approaches of the past never stuck, and may be responsible for some of the chaos we see today. When the approved tool chain doesn’t work and there’s no easy way to challenge standards, developers are faced with the impossible choice of either delivering less or subverting the system.
Platform engineering encourages a more responsive collaborative approach, where golden paths encourage alignment but developers are never forced to choose between evils.
The Convergence of Opinion, Research and Practice
We are firmly in the research-backed era of software delivery. We’ve grown used to drawing inspiration from practitioners and expert authors, but we now have the opportunity to build and validate models — both as an industry and inside our own organizations.
It’s crucial to prevent this from becoming a purely academic pursuit. We have to ground the research in real-world experience. That means developing the grit to overcome survey fatigue and participate in valuable research programs like Google’s Accelerate State of DevOps survey.
Our platform engineering research needs your input. While we’re finding commonality between the business and technical teams on the reasons to adopt platform engineering, we’re also picking up signals such as process standardization that will create future trip hazards if we don’t address them early.
You can help us develop insights by answering our short questionnaire.
