The theory of everything APIs and Platforms
Much has been written about the benefits of platforms as a basis for building successful and scalable businesses. Great examples of organizations that successfully deployed platforms include Amazon, Microsoft, Intel, Google, eBay, Flickr, Airbnb, and Spotify.
The word “platform” is often used in a variety of situations. In an earlier article The Platform Stack, I had elaborated on different platform configurations using the platform stack as a design framework. Platforms have three distinct layers: Network, Technology Infrastructure, and Data, as shown in Figure 1.
This article will analyze the inner workings of a platform that enable the extension of the technology infrastructure and the flow of data, as well as the development of a network on top of the technology infrastructure.
We cover two perspectives:
The common denominator for both perspectives is the design quality and choice of interfaces that enable access to the infrastructure and flow of data into, through, and out of the platform.
To download this article as an ebook, click here now:
Marc Andreessen has stated that the key characteristic of a platform is that it “can be programmed.” Because of that, it can be “customized by outside developers—users—and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated.”
The generic nature of a platform leads to its most powerful aspect: the potential for a mul-
titude of new use cases built on top of the platform, or mashed-up with other platforms. Think of it as LEGOs on steroids, where the blocks are not only able to connect and build on top of each other but can also talk to each other and benefit from each other.
To achieve this goal of extendibility, platforms need to be accessed via some form of technical interface referred to as application programming interfaces (APIs), as also described in Marc Andreessen’s article. The better these APIs are designed and documented, the more effectively the platform infrastructure can be accessed and leveraged. This argument aligns with the external perspective mentioned above.
An API is an interface. The abstract concept of “interface” is defined in Communication
Theory as “a point of interaction between a number of systems.” An integral part of Systems Theory, this concept is used for describing or modeling any type or form of system. The idea of using interfaces—or APIs in our concrete case—it not just useful for accessing the platform from an external perspective, but also for designing a platform from an internal perspective.
A platform, internally, may be viewed as a composition of multiple complex systems.This is especially true when we consider platforms built across large organizations that facilitate workflows across their resources and harmonize access to these organizational resources (data or services). If an organization is built from scratch—say, a new venture or startup—with a platform business model in mind, it becomes easier to set up the company around the platform business model. We call this the platform-first design approach. Gall’s Law would encourage going this route whenever possible:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Because of this, it is much more challenging to build a platform within the constraints of an existing organization’s legacy systems. But therein lies the challenge for many large enterprises looking to transition to a platform-based business model today.
However, several existing academic theories can help us create a design for these companies. Herbert Simon’s theory of Decomposability suggests that complex systems can be simplified by breaking them up into smaller discrete pieces with clearly defined interfaces for interaction. Baldwin and Clark go a step further, and argue that three principles need to be followed to make a decomposed complex system work:
By following these three principles, complex systems can be aligned with well-designed platforms. The technical interfaces act like glue and allow the various platform-internal sub-systems to communicate with each other.
Built with APIs, they are crucial for programmable platforms, not only for access (the external perspective) but also for building platforms (the internal perspective). To create a best practice platform-first approach, we recommend an API-centered focus for building the technology infrastructure for the platform. API-centered means that the interfaces are in focus and are designed first, the rest follows from it. Figure 2 below illustrates the two uses of APIs in platform businesses.
There are multiple perspectives that need to be considered while laying out a platform
infrastructure’s relationship to external stakeholders.
The obvious difference between these scopes is one of access. Irrespective of the scope, five typical use cases for platforms, made accessible via APIs emerge:
For more detailed background regarding these use cases, please refer to the ebook
“Winning in the API Economy.”
All five use cases are enabled via underlying platform infrastructures. These use cases can leverage platform economics, which enable platform-based business models. This can be seen in the network layer of the Platform Stack.
The graph on the left-hand side represents the market of side 1. The graph displays the price vertically and the quantity horizontally, with a resulting demand curve. The price is set to P1 which, based on the demand curve, impacts a certain quantity Q1. Because side 1 and side 2 markets are connected via the platform, the price/quantity combination in the side 1 market has an effect in the price/quantity combination of the side 2 market.
The next illustration shows what happens when something in this constellation changes.
In this example, we assume that the platform provider decides to lower the price in the side 1 market from P1 to P2—or even make it free, as in the Google Search example. P2 in side 1 would result in a much higher quantity Q2. Again because both markets are interdependent, which would result in a change in the side 2 market. Because of the higher demand in side 1 there will be more demand in the side 2 market, which means an outward shift of the demand curve. This outward shift also means a higher quantity Q2 in the side 2 market and potentially a higher price P2. Both combined mean a higher revenue in the side 2 market indicated by the red rectangle in the above illustration. These interdependencies of side 1 and 2 markets go both ways. If, for example, a platform provider changes price or quantity in the side 2 market, perhaps via special promotions or price reductions, this will have a knock-on effect on the side 1 market.
More details about the market dynamics of platform-mediated markets are explored in the blog Platform Thinking. The mechanism by which different platforms create value is also explained in detail in this article explaining the Platform Stack. The ideas were also discussed at the APIDays conference in Paris.
The benefits of platforms—adaptability to countless needs and niches—are clear, the challenge lies in building them. When building or re-designing organizations or units, we recommend the interaction-first approach that is discussed often in the Platform Thinking blog. In order to implement the technical infrastructure for a platform, we recommend an API-centered approach. Focus on the design of the technical interfaces first—everything else follows from that.
As outlined in this article, we see the interfaces (APIs) as the unseen enablers of platforms. APIs serve platforms externally by allowing managed and controlled access.Internally, APIs can be used to connect services or applications and control access to data or services resulting in an extremely clear and clean system architecture. If API centered design is not possible due to the need for the integration of many legacy systems, we recommend that organizations follow the three principles proposed by Baldwin and Clark: architecture, interfaces, and standards. To have control and visibility into an API’s usage, and behavior—internally as well as externally—API Management solutions may be deployed.
Building businesses on platforms can be tremendously effective. The unseen enablers of platforms are APIs. These technical interfaces standardize access to an organization’s assets (data and services). APIs lead to a liberation of access to data and services.In the coming years, every organization will need to have an API strategy and allow access to assets via APIs, just like every organization has a website strategy today to allow access to its information.
APIS and platforms: how interfaces and access enable the networked economy Share this
Why APIs will change business operations and business development Share this
APIs are the contract and the integration interface Share this
APIs: From organizational transformation to ecosystem development Share this
The future of work may favor the portfolio over the problem-solver.
Network effects for asset-heavy businesses