APIs and Platforms: Enabling the network economy

This article was co-authored with Manfred Bortenschlager, API Market Development Director at 3scale.

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:

1. An internal perspective for building platforms to ensure all necessary segments will work together, and
2. An external perspective for making platforms accessible and usable.

The common denominator for both perspectives is the platform design quality and choice of interfaces that enable access to the infrastructure and flow of data into, through, and out of the platform.

THE PLATFORM: EXTERNAL PERSPECTIVE

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.

THE PLATFORM: 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:

1. An explicit architecture design needs to specify the various sub-systems and their function.
2. A definition of interfaces that describe how the sub-systems interact with each other.
3. A set of standards to lay out the ground rules for the overall system.

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.

HOW CAN THE BENEFITS OF PLATFORMS BE REAPED?

There are multiple perspectives that need to be considered while laying out a platform
infrastructure’s relationship to external stakeholders.

1. The private scope refers to the use of a platform-based integration approach within the boundaries of an organization. An organization’s different business units may still need to use these interfaces to access the platform infrastructure, as well as stakeholders external to the platform. When we refer to the external perspective, we mean external to the platform, which can still be internal to the organization. Amazon serves as a great example of this. At some point, Amazon decided that every internal service had to be represented by an API, which created an internal platform infrastructure. Every business unit communicated with each other via these internal platforms. These platforms created a network of business units that were always plugged-in and working with each other, integrated through the flow of data and information.
2. The curated partner scope refers to APIs that are open beyond the organization but only to selected, curated partners.
3. The open access scope refers to public APIs that can be accessed by anyone. These are typically self-serve and open to external developer communities to plug and play with.

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:

1. Enabling mobile channels
2. Growing an ecosystem
3. Increasing reach
4. Powering new business models
5. Driving innovation

For more detailed background regarding these use cases, please refer to the ebook
“Winning in the API Economy.”

PLATFORM ECONOMICS: THE NETWORK LAYER

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.

BUILDING PLATFORMS: TAKE-AWAYS

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.

TWEETABLE TAKEAWAYS

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