Your API strategy is not a Platform strategy

aka APIs are not platforms. Originally published on my homepage.

An Application Programming Interface (aka API) is the interface other people/developers use to access the functionality of your code. This is valid at the lowest levels of programming (microprocessor programming), at the highest levels (REST/GraphQL/gRPC/... APIs exposed by services), and everything in between (public methods of Java classes etc).

With more and more organizations choosing to expose their business capabilities over publicly accessible APIs, there is a widespread conception that having an API is a clear indicator that a business is "going digital". And since the distinction between products and platforms is already drawn poorly (as we have seen before), it has led to a massive explosion of so called "platforms" which are, in fact, nothing of the sort.

APIs as a Strategy

Exposing public APIs represents an attempt at opening up our system for use by the external world. An organization might build and expose API for many reasons. The primary among these is to allow its existing customers or partners to access some parts of its system remotely. It might also wish to attract more customers or partners by touting this digital experience as a differentiating factor from its competition. In industries where technology has not found a strong foothold, this can be very effective.

Once we have APIs in place, we are committing to other teams/organizations that they can access the behaviour of our systems in a certain way and that we offer well defined guarantees around the functionality. This includes defining the specifics of the functionality, expectations around availability and other service level agreements like latency, throughput etc, and the cost of using the API. Done well, all of this represents a significant trust on and investment in technology.

Even building this little digital window into its business can have dramatic effects for a company and a lot of hitherto old-school companies find even this limited digital transformation extremely challenging. Consider that you are a bank which has hundreds of branching running paper based banking processes. Every one of these processes has been refined over decades to cater to every customer touch-point with certain SLA. e.g. Opening a bank account may involve filling out a form, submitting many documents, repeated trips to the branch office, all taking 3-4 days.

Now let's say you decide to expose a createAccount API /web portal where a customer can fill the form and upload all documents in one go. Customers now expect to open bank accounts much. more quickly and many more of them may sign up via. this method. What happens to the. manual account opening machinery now. All the processes put in place over the years have to be re-thought to service the new customer expectation.

Also, what good is a createAccount API without a checkBalance API or a transferFunds API? If the bank continues to offer deeper online access to its capabilities, it is disrupting its legacy business very rudely and you can bet that a lot of feathers are being ruffled. If it doesn't offer these capabilites or offers some arbitrary subset of them, the entire digital customer experience is sub-par and the "digital transformation" stalls or fails.

As you can see from this example, having an API by no means qualifies the organization as being tech-driven. The technology mindset has to be adopted wholesale, or it is unlikely to be as fruitful as expected.

A platform is more than APIs

The platform narrative is more subtle, and thus gets obscured or misinterpreted in this API building frenzy. As we have discussed before on this blog, a platform is a set of tools that can be used to build new products and experiences. While APIs are critical to the platform journey (as the means to accessing the platform), a set of APIs is by no means a guarantee of platform architecture. A platform is more than a set of APIs.

By themselves, APIs are a one-way street. We have certain capabilities, that we allow some external agencies to access. An API, in this sense, in a sales funnel for our core business. While this allows others to access our core product, a platform offers far deeper modes of co-operation that an API does. This is because platforms offer the opportunity for organization to partner with each other at every step of every business process. While APIs limit interactions to the edge of the system (an existing end-user functionality becomes accessible over an API), a platform approach would open up the systems in a way that allows organization to easily hook into each other's decision making processes, leverage each other's capabilities more deeply, and create business value at the core of the business. This is done by integrating APIs from different organizations into a continuous chain of business decisions and resultant actions.

As Fig-2 shows, platform architecture actually externalizes the organization itself (or vice-versa, depends on how. you want to look at it) from the technical capabilities, thereby freeing all decisions to choose the best option from the entire eco-system with equal ease. The business processes of the organization can now use what was built by the internal teams, or easily bring in the technical capabilities of partner organizations to fill a gap in the value creation process.

As some of you may have noticed, this is very similar to how we can build systems "inside" a platform organization by stitching APIs from different teams into end to end business processes. This is yet another way to understand why I think that there are no "internal" platforms. Platform architecture and processes are inherently externalizable - always ready to be deployed in a context other than the one in which they were originally developed.

Over and above the useful capabilities it offers its users, a platform is the set of control structures required of operate the platform smoothly and prevent abuse. It is backed by an organizational structure and processes which focusses on creating and capturing economic value by empowering others, and it is the platform owner's commitment to mutually beneficial exchange of capabilities in an eco-system. The APIs of a platform are explicitly designed for being used as building blocks for other things.

Similar arguments hold for team mind-set. Teams in platform-centric organization work HAVE to work with an enablement mindset of helping their customers build new things and exploiting any opportunities in the eco-system to best accomplish their respective missions. The technical architecture of the platform super-charges this mandate by making it extremely easy to collaborate technically. As a result, a team can work seamlessly with any internal or external teams without having to worry about playing technology gatekeeper or process policeman. Participating in the ecosystem becomes the default behaviour instead of being an exception.

Conclusion

An API, sadly, is just an API. It can be thought of as a product - useful within its own context, but ill-suited to the give and take of a dynamic eco-system. The API-is-platform fallacy is another instance of organizations falling for the hype surrounding platforms and trying to build one as cheaply as possible without understanding their true nature.

If you like reading about technology and platforms, sign up for my mailing list to receive these articles right in your inbox.