Why API Platforms Should Be Open

Posted in

API development as a core business function is a critical element of the modern business landscape. As such, understanding how this development occurs, and most importantly, understanding the ingress function and process for new concepts into the system, can lead to massive business benefits.

Today, we’re going to talk about why it’s crucial to make an API platform open. We’ll look at what it means for an API to be “open” and what business functions this enables. This piece was inspired by a presentation by Erik Wilde.

Understanding the Platform

The Emerging Model of API Business Interaction

Before we can talk about why API platforms should be open, we should define what a platform is and where the concept of the API platform as a business function actually came from. In the modern space, traditional models of API development as a business value have changed in line with consumer and business need changes. Change has become a chief driver, with each new year requiring new business integrations, new user support, and new methods of development. What has evolved from this is the idea of a platform.

A traditional model, known as a linear business model, is essentially a straight line between the producer and consumer. This considers what a company has, what it can produce to add value to the mix, and what consumers are willing to pay. Unfortunately for traditional business models, the value offering is typically frozen as a single solid state — the product is stagnant, and if it requires change, a new linear offering must be created.

Traditional models are less adaptable, and if a rapid change is attempted, it often carries an extreme cost. The platform model, however, aims to fix this by creating a collection of variable systems that can move and adapt to changing requirements. A platform can pivot more quickly to provide additional functionality.

Erik notes that there are two fundamental approaches here: the “short game” and the “long game”. The short game is simple: establish the platform, ensuring that everyone is on board with using APIs and delivering capabilities from the organization with those APIs. The long game is more complex: ensuring that there is a space for evolution and consistent development is key, which requires not only enabling continual evolution but also creating avenues for this change to be implemented and included.

With this in mind, we should answer the core underlying question — what is a platform, specifically?

What is a Platform?

First, let’s answer what a platform absolutely is not. Contrary to some older business logic, platforms are not just technology, not just a linear business model, and certainly not a completely holistic ownership of a value chain that is linear and singular-purpose. Too often, companies state they have a “platform” when what they really have is a complex product offering.

So what, then, is a platform? Erik notes four core concepts that define a platform:

  • Co-creation: A platform generates value through its facilitation of exchanges and interactions. In essence, a platform should facilitate interactions, which ultimately result in co-creation and collaboration.
  • On-demand: A platform should create networks of users and resources that can be accessed on-demand. This on-demand nature allows for dynamic allocation, surfacing of intent and value, and co-creation from groups already bought into the system and the systems themselves.
  • Network effects: A platform should use the network effect to grow communities and markets, allowing for more broad-based support for contributions regardless of their origin.
  • External-facing: A platform should create value by reducing transaction costs while externalizing innovation.

Ultimately, a platform is the perfect meeting point between technology and business logic. While tech can be limiting, it can also be enabling; the same is true of business logic. Where these two things meet in the balance with those four elements, we have a true platform, which can deliver both greater technical possibilities and greater business value.

With that in mind, how can we help to build these platforms? More directly, how can we help to improve this experience and create a pipeline for partners to help develop and co-create?

Growing and Evolving the Platform

The best way to ensure that you build a robust platform is to ensure that you enable both growth and evolution, roughly aligned behind short-term and long-term planning. Growth is stimulated by allowing more transactions to happen, bringing more people into the fold, and unlocking additional functions. Evolution, on the other hand, invests in new action areas to drive further growth and development.

An essential facet of these approaches is developing new co-creation methods for value and creating new experiences for consumers. One way we can deliver on this great promise is to adopt open standards, methodologies, and approaches while ensuring we continually surface new groups and thoughts.

Growing the Platform

The first thing any organization should do when targeting platform growth is focusing on visibility and discoverability of the API and its functional resources. This can be a huge step, but in essence, this allows any co-creators to understand the API and see both what is happening and how they might augment it to add value. This is very much a classic case of “build it and they will come” — as only an effectively surfaced platform can iterate and grow. Make all assets and services available as an API, and thoroughly document them.

Being open in this way enables the network effect, allowing others to co-create and add value by contributing to a specific attribute of the greater overall platform. Through this, the business value of the platform is likewise grown and iterated upon.

An example of this kind of relationship would be in marketing and advertising. These groups may come into the platform with a specific experience or custom reach, and through offering this experience, they claim value. For the platform, this is something the API can use to drive their own revenue and offer this core experience to other potential partners to drive even more future revenue and value.

In essence, growing the platform requires surfacing and opening the platform in the short term, and should be seen as a precursor to the longer-term conversation about innovation and eventual evolution.

Evolving the Platform

Now that the platform is surfaced, we can begin to view the broader perspective of the platform as a business entity. Your platform needs to be comprehensively understood and open, but it also needs to evolve by adopting new consumers, channels, and solutions over time. Simply opening up is not good enough — you must also create ways through which change can be facilitated and built into the new platform.

This brings up a fundamental question — how do we bring in new groups of people to add value as an evolution of current business function and logic? The answer is simple: allow the platform to be open as a base concept. And, allow openness as a business concept when regarding possible avenues of development and integration.

Set a core business function of incorporating new elements upon demand (with restraint), and you’re creating an evolving business that leverages the open nature of collaborative co-creation to generate a pipeline of need that ends with a new offering. In essence, new users will need something of the platform and either request it directly or build it themselves. If you are properly positioned, these new developments can be folded into the core business-logic platform.

This includes some foundational perspectives on API styles and best practices. Adopting new API styles where appropriate, supporting new API design tools, and adding APIs utilizing different infrastructures to the mix can leverage your existing platform to deliver greater user support, and through this, greater business success.

Adopt good practices, but consider what it means to change these practices in the wild — it’s good to have current best practices, but why might we change them, and if we need to, how would we implement that change? Deciding this early on can help facilitate long-term platform evolution that originates from user interaction rather than the best guesses from platform managers.

Conclusion: Facilitating Openness

For these reasons, keeping your API open (or making it open if it’s not already) is perhaps one of the best practices you can adopt in the short and long term. Some methods can be employed to ensure this openness is supported — such as adopting open standards, surfacing functions at a top level, and ensuring that openness is a standard rather than a nice thought. These combined can go a long way towards guaranteeing continual evolution.

Other steps that can be taken include building in core open standards wherever possible. Adopting open documentation, open-source libraries, open-source SDKs, database solutions, open-source security tools, and more. This can ensure a sort of “lingua franca” for the platform as a whole, creating a clear venue for function development and addressing opportunity when it arises. When developing, API providers should think not just about what the future may require but how these requirements will be surfaced and how the answer to those developments will be integrated.

What do you think about the concept of open API platforms? What do you think of the presentation we linked at the top of this piece? Let us know in the comments below!