Did you ever hear Facebook, Google or Amazon using ESBs? May be not. A web scale organization may have much more integration complexities than a typically enterprise, but it is not common to hear them adopt certain architectural paradigms (or technology products) that are mainstream in enterprises, say a bank or an insurance organization. One of the fundamental reason for that is the “age” of enterprise and its “evolution” alongside technology advancement over the decades. These enterprises existed much before web companies came into existence, and what differentiates them is the huge legacy that they have accumulated over years.

Let us talk about a tech-savvy bank (say XY Bank) of pre-internet era, starting from 90s. XYB has most of its business functions and data on mainframes. Employees are using dumb terminals that connect them to the mainframes. Thick client UI applications have taken over some of the front-end functions. These client/server applications talk to a [database] server or say a program written on C/Unix, which in turn communicates with a DB or mainframe systems.

By mid 90s, internet gradually started gaining popularity. XYB now wants its core functions to be available on internet so it creates a web platform for its customers. Since internet is just an additional channel, it makes no sense for core applications to be re-written. We just need new web platform to “communicate” to the existing applications in mainframes, coded in client/server architecture, are packaged/bespoke and so on.

The need for applications to “communicate” accelerated advances in “distributed computing” technology. Remember this was also an era of mergers and acquisition of financial organizations, which increased the need to wire more systems. Technology companies filled the void with middleware products. Standards emerged; vendors came up with their implementations (e.g. implementation of ORB or enterprise java specification), EAI frameworks and finally ESBs. ESBs fundamentally fulfilled the following needs:

• ESBs held the internal architectural pieces of enterprises together. It is the internal nervous system of an organization, which decouple big monolith organs, and provided a unified layer for upstream applications.
• Connected desperate enterprise systems written in different technologies, at different times, use different protocols, and are owned by different departments etc.

Fast-forward a decade and we have API platforms. There is a commonality between the two in simplistic terms.

ESBs abstracted enterprise assets built in 90s and before. API management suites are doing just the same with additional decade of legacy.

The way internet forced enterprises to wrap their existing resources under ESBs to ease the consumption; digital forces are pushing them to adopt API based suites.

In perfect world, enterprises did not need ESB suites then or API lifecycle suites now, but market competitiveness does justify introducing an extra layer in the architectural mix.

With digital-everything, XYB has a need to become a platform now. The consumers are not just its end customers, but also a larger ecosystem outside its enterprise boundaries. Fundamentally, XYB is still a bank with same core business, but it now needs one extra layer to the onion architecture to appear like a platform. And what can fill that need? Web APIs. Web APIs can make XYB more consumable in a standardized fashion. APIs can open it up for new partnerships say with FinTech startups, new channels and new products.

The challenge is, this needs to happen in a lean and nimble way amid all the complexities of IT landscape in a typically bank. This is where API management platforms shine. You do not need API platform to create APIs but you need them to create APIs fast. Of course, there are additional bells-and-whistles that API platform provide, but for an enterprise, the fundamental need is to create APIs quickly on top of their existing legacy assets. It is the ability of quickly wire the downstream resources and create an API that makes API platform unique.

API platforms meet the notion of 2-speed IT which is fundamental to segregate system of records from system of engagements. And they will continue to do so for a foreseeable future.