It's commonly believed that there are three types of API:
- Open, or Public APIs which have no restrictions on access
- Partner APIs which are made available only to strategic partners
- Private or Internal APIs which expose systems or capabilities internally, and which are most often not open to external use
All three are interesting but for me internal APIs particularly so since they are far less talked about and yet enable an organisational operating model to be built around a Service Oriented Architecture (SOA) where individual teams and functions can make data and resources available as a service to other teams that might need them. Whilst this approach is not without its challenges (including discovery, managing demand, and support), it has the potential to support far greater agility by making more data and capability available on demand as and when it is needed. Think about how frequently in a large organisation one team requires information, resources or numbers from another team and just how slow that process can be through manual processes and email. Most organisations have grown up with multiple systems that don't share data or talk to each other meaning that breadth of access to relevant data becomes difficult.
Amazon were of-course the first scaled organisation to realise the potential of APIs to enable a truly innovative operating model that has given them (and continues to give them) considerable advantage. It all began with a famous mandate from Bezos as far back as 2002 which went something like this:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn't matter what technology they use.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn't do this will be fired.
This resulted in the business transforming internally into a SOA where every team interacts through APIs, defines what resources they have and makes them available through web services. But it also meant a business that thinks of everything in a services-first way. This was then taken to a whole new level through the successive externalisation of capability (services like AWS, Fulfillment by Amazon, Amazon Connect and so on). This approach means that Amazon gains greater leverage and learning through scale, services have to compete on the open market ensuring greater efficiency, and in affect that Amazon becomes Amazon's largest customer.
In this scenario teams become partners of each other, loosely coupled but able to draw on copious resources at will. Given that the need for horizontal collaboration and agilty (along with free-flowing access to data and resources) has never been greater, I'm surprised that we don't see more of this potentially transformational approach.
