Platforms, Teams, and APIs: How Do They Fit Together?

Erik Wilde

Dieser Artikel ist auch auf Deutsch verfügbar

This article is part of a series

• Part 1: Common Approaches in the Field of Socio-Technical Architectures
• Part 2: Platforms, Teams, and APIs: How Do They Fit Together? (this article)

From Pages to Services

The early 2000s marked a turning point with the rise of the web. Tim O’Reilly, publisher and founder of a well-known media company, was one of the first to see the web not just as a human-centric system (where web pages are delivered to browsers) but also as a global service platform that enables communication between programs. He shared this perspective in early 2000 during conversations with Jeff Bezos, then CEO of Amazon. At the time, Amazon was a rapidly growing online marketplace. Bezos was inspired by the idea that the future lay in making businesses faster and more flexible—and that services were the right building blocks to achieve this. Bezos responded swiftly and decisively. In 2002, he issued the now-famous “Bezos Mandate.”

Jeff Bezos made a clear and bold directive: from that point forward, all teams at Amazon had to offer their services via programmable interfaces (APIs). These interfaces needed to be designed not just for internal use but also for external consumers. The goal was to reduce tight coupling between components and make all services easily discoverable and reusable.

The mandate did not prescribe a specific technology for these interfaces—as long as they were network-based.

The motivation behind this decision was clear: as a fast-growing, ever-evolving marketplace, Amazon required an IT culture and structure that prioritized speed and flexibility. Traditional software development challenges—such as long development cycles and high coordination overhead between teams—needed to be addressed.

The Bezos Mandate was both simple and radical, transforming Amazon’s software architecture with the ultimate goal of accelerating value creation.

As a result of this mandate, Amazon launched its first e-commerce APIs in 2004, which helped drive the growth of its marketplace. However, the most influential outcome came in 2006 with the public release of Amazon Web Services (AWS) APIs, opening entirely new business opportunities.

But what exactly did the mandate say that had such a profound impact on Amazon’s success?

Every Team Has an API

To enable Amazon teams to develop as quickly as possible, dependencies on other teams had to be minimized. This was achieved by requiring every team to provide an API (the original mandate used the term “service” instead). The mandate was brief but had far-reaching implications. It consisted of the following key points:

1. All teams must expose their data and functionality through service interfaces.
2. Teams must communicate exclusively through these service interfaces.
3. No other forms of communication are allowed—no direct linking, no direct database access to another team’s storage, no shared memory, and no backdoors. The only permitted communication is through service calls over the network.
4. The choice of technology does not matter—HTTP, CORBA, Pub/Sub, custom protocols—anything is allowed.
5. All service interfaces must be designed from the ground up to be externalizable. Teams must plan and architect their interfaces as if they were intended for external developers. No exceptions.

At the time, this was a radical approach that significantly improved the scalability of team interactions compared to the tightly integrated systems that were common back then. When viewed through this lens, it becomes clear that the Bezos Mandate was primarily about minimizing inter-team dependencies (loose coupling) and restricting team interactions to a well-defined communication channel.

The mandate also had far-reaching consequences. Steve Yegge described them in his famous “Google Platforms Rant” from 2011[1], where he reflected on his experiences at Amazon. His insights reveal that implementing the Bezos Mandate was complex and took years. In an API-driven company, even fundamental aspects—such as debugging issues or locating services—change dramatically.

However, this discussion is not just about the technical complexity of decentralized software architectures. More importantly, it highlights how team structures and technical structures are inherently interconnected.

How Teams Interact

The Bezos Mandate fundamentally changed how teams interact by establishing loose coupling as the default—and in fact, the only permitted—approach. However, this shift did not automatically make collaboration between teams easier or less complex.

Since the 2019 publication of the book Team Topologies[2], a new perspective on team interactions has gained traction. One of the key ideas introduced is the concept of a “Team API.” Unlike the Bezos Mandate, which focused solely on technical APIs, the Team API concept extends beyond just interfaces and services. It also includes practices, collaboration patterns, and the key people involved in a team’s processes. The idea is that loose coupling should be complemented by additional information that helps external teams understand how to interact with a given team effectively.

This approach further strengthens team autonomy, as teams operate externally as service providers. However, with greater autonomy comes increased responsibility—teams must now handle the entire development lifecycle independently.

To mitigate this natural but unintended consequence of increased autonomy, the platform model has emerged as a solution. This includes not only traditional infrastructure platforms but also a more modern evolution: the Internal Developer Platform (IDP), which provides streamlined tools and services to help teams maintain their autonomy while reducing operational overhead.

Team Efficiency and Platforms

The fundamental difference between an infrastructure platform and an Internal Developer Platform (IDP) lies in their composition and purpose. While an infrastructure platform consists of standard market components (such as runtime environments and programming languages), an IDP is specifically tailored to the needs and practices of an organization.

This distinction is why Team Topologies introduces the concept of Platform Groups. These teams are responsible for relieving other teams of repetitive and potentially time-consuming tasks by implementing them within the IDP. As a result, regular teams (referred to as Stream-aligned Teams in Team Topologies) can work more efficiently by offloading certain responsibilities to the platform.

From a Team Topologies perspective, this approach achieves two key objectives: First, it creates the “Logical Platform,” which is perceived and consumed as a cohesive platform. This enables teams to develop more easily by leveraging the platform’s capabilities. Second, “Platform Groups” collectively contribute to the provision and continuous development of the Logical Platform—while potentially operating independently from one another.

Another advantage of the platform model is that it facilitates and encourages component standardization. For example, if teams previously used different monitoring solutions, a platform can offer monitoring as a standardized service, ensuring consistency across the organization.

Platform Engineering Supports Teams

The term Platform Engineering refers to a socio-technical approach that leverages team structure and responsibilities within the development process to reduce cognitive load and increase efficiency.

The growing popularity of Platform Engineering and platform teams today is primarily driven by two factors. First, the rapid increase in digital products has made efficiency gains in development more impactful than ever. Second, the demand for faster development cycles has intensified, requiring organizations to accelerate how they build and deploy digital products and solutions.

When development becomes simpler and faster (and therefore more cost-effective), companies can pursue more exploratory strategies—which leads us to the final missing piece in the modern platform puzzle…

Team Efficiency and Effectiveness

Platform Engineering primarily focuses on improving the efficiency of the development process. While this is both necessary and valuable, it does not automatically ensure that the right things are being developed.

This is where the concept of optionality comes into play, which Stephen Fishman and Matt McLarty explore in detail in their recent book.[3] Optionality means strategically maintaining as many options as possible to maximize value creation within an organization, while continuously refining and optimizing this process.

To achieve this, Fishman and McLarty argue that an organization’s default approach should be to enable the reuse of business serviceswherever possible. This brings us back full circle to the Bezos Mandate, which was introduced earlier in this article.

Although the Bezos Mandate is frequently cited, its radical implementation is rare. This is partly because it is not always the most cost-effective approach for a given business model at a particular moment. Instead, it represents an investment in decoupling services, thereby creating greater flexibility for future developments. This concept, known as “Unbundling”, is described by Matt McLarty as follows:

Unbundling requires effort and resources, and its strategic logic is not always appropriate in every scenario. Similarly, loose coupling comes with costs. However, these investments contribute to resilience and flexibility—values that are becoming increasingly critical in today’s rapidly evolving world.

That does not mean that business and IT need to be completely overhauled. Instead, it calls for a shift in focus—toward teams, their interactions, and the potential of these structures. Team Topologies addresses this with the concept of the “Thinnest Viable Platform.” This approach does not require a radical restart but instead aims to provide a minimalistic platform that offers only the essential functions needed to support product teams, simplify their work, and avoid unnecessary complexity.

This trend is also evident in the API product market, which plays a key role in supporting unbundling within organizations. After a period of stagnation, momentum in this area has surged. New vendors are emerging with API portals and marketplaces, and companies are increasingly making strategic investments in API strategies and programs. While part of this shift is undoubtedly driven by the rise of AI applications that rely on APIs, the trend toward strategic API management actually began well before the current AI boom.

Sources