The tech industry uses many flashy terms, but sometimes, the marketing jargon and the technical realities aren’t always compatible in a crystal clear way. It helps to specifically dive into a term and ask a simple question – “what does it really mean to be this?” The concept of a platform is one of these terms – often used to describe a wide range of implementations, it has slowly become a buzzword that sometimes ventures outside of its traditional definition.

Today, we’re going to provide that definition, and we’re going to look at the different kinds of business logic that results from API platforms. Since marketing jargon is informed by these business models, understanding both the technical and business sides of things will help to elevate and clarify. We’ll also look at some common types of platforms and general benefits from having a platform.

What is a Platform?

In the most general terms, a platform is a group of technologies, solutions, or offerings that form an iterative basis for developing, implementing or deploying other offerings. In many ways, a platform is just like a construction foundation — many different buildings could be constructed using the same foundation. But first, the foundation must be strong and outfitted with the elements necessary for iteration and expansion of the core offering. A platform must also be extensible and somewhat elastic.

Let’s look at a hypothetical example to better understand what we mean when we discuss platforms. Assume we have a commerce client for a camera manufacturer to ship directly to the consumer. We have several APIs and systems involved within the ecosystem, including a shipping system, a Just-in-Time manufacturing system, and other elements that manage the organization’s day-to-day operations. To improve the industry, we have open-sourced our shipment coordination and handling systems and have released our custom database format.

In this case, our platform is not a single API — it is the sum total of our offerings and the outward-facing interfaces that allow both us and others to iterate and build upon the core structure. If we wanted to pivot to producing simple lenses and camera systems for phones, we could build out another API and collection of machine management systems; since we already have many implementations running a core set of technologies. However, we can expand and iterate upon this core structure. This quality of iterative development and extensibility makes our system more than a “codebase” and instead makes it a true platform.

How is a Platform Business Model Unique?

The word “platform” is often used as a buzzword. Because of this, many codebases are not platforms, despite their claim to the opposite. The best way to understand the difference between an actual platform-driven business and a codebase-driven business is to look at how the business model for the API changes compared to the “traditional” API business model.

A traditional model is like building a chair. The chair is a structured offering, made for a specific use case out of specific materials. You can modify it in theory, but you’ll never be able to make an entire furniture set with it. A platform, in this analogy, is more akin to the workshop that produced the chair. In addition to chairs, the workshop can also construct tables, sculptures, and hundreds of other products using the same tools and materials.

This analogy helps understand the business model between traditional APIs and platforms because it lays out the difference in terms of the end-user focus. In a traditional API, the offering is predefined, and the function is largely at the whim of the developer who created the systems that underlie the API itself. A platform business, however, is one of enablement — how the system is used is more segmented from the platform itself.

Thus, an API-centric business is roughly analogous to “we built a specific solution — let’s find a specific problem to sell it to,” and a platform-centric business is more akin to “we built a platform for solutions to be created — let’s find businesses that want to use it to build solutions.”

The Platform Model and the Business Model

It should be noted that the line between the business model and the platform model is not always easily understood. There are cases where the platform business model can seem entirely independent of the core business model. In some cases, the decisions that benefit the platform can seem to be, at least in the short-term, non-advantageous to the business model, or even detrimental to the corporate “bottom line.”

For instance, it is not uncommon for corporate entities to utilize trade secret technologies within their platforms. These trade secrets may be so useful to the industry that the organization chooses to open-source the implementation as a whole. Even if this decision seems in the short-term to not be beneficial for the org, the decision may be best for the platform, and thus best for adoptees.

Circuitously, this might lead more people to utilize the platform and iterate new technologies that could leverage other parts and offerings from the business itself, thereby benefiting the “bottom-line.” In such a case, the line between the business and platform model is not clear, but the result is benefits for the platform, benefits for the adoptees, and benefits for the end-user.

Types of Platforms

Platforms are not all the same, and it bears some consideration as to what the platform itself is built around. You’ll often see something referenced as an “XYZ-first platform.” The specifics of that focus necessarily reflect what the implementation would require.

For instance, API-first platforms typically focus entirely on tooling explicitly built for web service APIs, including systems for load leveling and response forming, or other systems designed to enable web service-based communication and cooperation.

Other platforms might be focused on entirely different things, however. For example, a platform may focus entirely on enabling code and tool collaboration. Another might focus on data manipulation services and data transformation. You might even find a platform whose sole purpose is to enable automated standards compliance systems within industries like financial technology, where such compliance is often costly to manage in-house.

Ultimately, the platform focus is quite important. The differences between each focus aren’t just a marketing ploy — they often define the platform’s overall intent and suggest a general structure and interface experience.

The Benefits of Having a Platform

Having a platform unlocks some pretty marked benefits. First and foremost, having a platform shifts development from other platforms to your own. This seems quite obvious, but it’s an important paradigm shift worth considering — when you own a platform, you own your API development, and more to the point, you also have a piece of other developments. By providing a platform for others, you may be converting competitors into coordinated partners — even if your API does not take off, your platform may. Your competitor’s success then is no longer a failure for your business model; it’s a success in another vertical.

A platform also makes for significantly quicker innovation. Since a platform by definition is the “foundation” of a series of offerings, having a platform means that you spend less time reinventing the wheel, and can instead simply recombine and reconfigure already existing systems. This same rationale is also what makes for a wider range of revenue options, as you can respond agilely and reconfigure or redirect your business focus based not upon the technical reality of development, but instead upon what portions of the platform can respond to market demand.

That agility and innovation also mean that time to market is significantly reduced. Not having to reimplement basic networking systems, authentication flows, etc. means that when you do develop a new offering, you are using a tried and tested core offering, allowing you to respond to new challenges and opportunities quickly.

Platforms Enable Solution-Builders

Ultimately, if the organization and the codebase allow for it, having a platform is a no-brainer. There’s a wide range of benefits inherent in having a system of proven technologies and offerings that enable solution-builders. But, the specific business models and approaches can change depending on the needs of the organization. For this reason, platforms should be viewed within the context that they live in — wonderful systems with very high potential for development, revenue, and interoperability, but they also come with their own costs and overhead.

What do you think of the platform concept? Did we do it justice here? Let us know in the comments below!