Summary of a transcription from https://www.youtube.com/watch?v=tvU9A6hfuKM
Platform engineering aims to scale DevOps principles, enabling developer velocity and a better developer experience. However, a common focus on the platform's internal tooling and workflows might overlook a crucial aspect: the provision of business-centric APIs that unlock broader organizational value and innovation. This guide explores potential blind spots and how to address them.
The conversation around platform engineering often centers on the efficiency of building and deploying software. But a critical question arises:
"My question to you was whether platform engineering as it is mostly portrayed today might have a little bit of a blind spot because there's not so much a focus on which APIs to provide throughout the organization to provide these options that new interesting things can happen." This sets the stage for exploring how platform engineering can better align with creating tangible business value through composable capabilities.
Platform engineering is commonly understood as scaling DevOps by building reusable tools and processes into a platform. A formal definition offered is:
Platform Engineering: "the discipline of designing and building tool chains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era." While this definition captures the technical essence, it can be perceived as primarily code-centric, engineering-centric, and IT-centric. This perspective might not fully encompass the "why"—the strategic business objectives the platform is meant to serve.
Business stakeholders often have a different, more intuitive understanding of "platform." For them:
"The business people that I've talked to actually understand the value of composable architectures... their picture of what it means to have a business as a platform is I've got all these digital building blocks that are my business functionality and I'm able to use those in different ways to solve new problems to open up new channels to exploit new markets..." Bridging the gap between this business-centric view and the IT-centric view of platform engineering is crucial. If platform engineering focuses solely on how things are built quickly, without addressing what is being built and why, it risks missing an opportunity to deliver on broader business goals.
The term "platform" itself can be ambiguous, referring to various concepts like IT platforms, Internal Developer Platforms (IDPs), API platforms, business platforms, or even platform business models. In platform engineering discussions, "platform" often implicitly means an IDP, designed for development efficiency. The risk here is clear:
"If you invest too much into platform engineering in that narrow sense and you don't invest into building up this optionality with APIs and good building blocks then it's not a good balance between being able to build stuff fast but maybe not the valuable stuff that you really would want to build?" Ensuring clarity on the type of platform being discussed is vital for aligned efforts.
"Optionality" refers to the valuable, though often unmeasured, property of having choices and flexibility within an enterprise's digital landscape. Platforms should be designed to build in this optionality. A key principle for fostering optionality is:
"...it should be the default assumption that if you build something you build it so that it can be reused that it provides options and if you don't do that there has to be a reason for that." This means the platform should encourage or even enforce the creation of reusable API-based building blocks. Furthermore, the platform should provide facilities, like a catalog of existing assets, so developers can easily discover and leverage these building blocks, rather than reinventing them.
Technology movements (like SOA, microservices, and now platform engineering) often follow a pattern: successful practices are observed, principles are extracted and generalized, but sometimes vital context is lost in reapplication. This can lead to focusing on specific implementations (e.g., "SOA equals SOAP," "microservices means splitting everything into Docker containers") rather than the underlying principles. When looking at archetypal examples like Amazon or Netflix:
"You can't just extract one piece of it out and say that's going to work everywhere you have to consider the whole context of what's going on." Their platform engineering success is intertwined with broader organizational structures, API strategies, and business alignment.
Every organization already has some form of platform developers work with. The goal isn't necessarily to replicate the most sophisticated platforms from tech giants, as this can be resource-intensive and potentially over-constraining. Instead, a pragmatic approach is needed.
"The focus has to be on the outcomes more than on the approach." This means incrementally improving the platform, guided by business outcomes. The principles of "start small, measure, iterate"—core to DevOps—should apply to the evolution of the platform itself. Focusing on providing valuable business building blocks is often a neglected "knob" that can yield significant returns.
A helpful concept for guiding platform development is "shifting down." This extends the "shift left" idea from DevOps.
Shifting Down: The practice of identifying capabilities or tasks that multiple development teams perform individually (even if "shifted left") and building them into the underlying platform. This makes these capabilities readily available, reducing redundant effort and promoting consistency. Identifying what truly benefits from being "shifted down" into the platform requires a balance of business value, team efficiency, and organizational context. It's about enabling teams, not just constraining them.
Ultimately, the success of platform engineering should be measured by its contribution to business outcomes. A platform that only offers technical efficiencies without enabling the creation and reuse of valuable business capabilities is falling short. A critical litmus test:
"If the only APIs in your platform are as you said earlier APIs for the platform services right then then how yeah how are you supposed to get to business values quickly?" The aim should be to create a platform environment where building valuable things fast is the norm. This involves a conscious effort to ensure the platform supports and promotes the availability of business function APIs, bridging the gap between technical capability and strategic business value. Synthesizing the different notions of "platform" might lead to a more holistic approach that truly drives the business forward.
References Mentioned:
- Organizations/Companies: Amazon, Netflix, Boomi
- Concepts/Methodologies: DevOps, Microservices, Service-Oriented Architecture (SOA), Team Topologies (stream-aligned teams), Domain-Driven Design, Agile, CI/CD, "Bezos Mandate"
- Publications/Events: Books from IT Revolution (e.g., Team Topologies, Accelerate, DevOps Handbook, The Phoenix Project, Unbundling the Enterprise), Enterprise Technology Leadership Summit
- Websites: platformengineering.org
- Experts/Authors: Jean Kim, Dr. Carliss Baldwin ("Design Rules"), Richard Seroter (concept of "shift down")