API’s and API management will be critical components in the digital transformation of many companies, but how will these technologies integrate into existing architectures?
It seems that there is a wide belief that API’s, API management, and digital transformation in general, will bring new capabilities that eliminate the need for the older service oriented architectures (SOA) of years past. In forum posts and conversations, I often hear of API’s as a miracle cure, that will deliver the functionality of services with a far less governance and much greater speed to market.
In my opinion, any approach that aims to replace services and service oriented architectures with API’s and API Management solutions, will miss the potential benefits of API’s. Further, I believe that many companies, that adopt this kind of approach, will likely do harm their enterprises. A service oriented architecture is the foundation upon which successful API management can be executed.
Definition of Services vs. Modern API’s
To illustrate my point, I must first offer a definition that differentiates between what I mean when I talk about a service and an API.
A service, in the classical SOA sense, is designed in a provider-centric manner. An architect creating services would analyze the capabilities of the providing application and look to create services with interfaces that expose the capabilities of that application. During the design of the interfaces, reuse is a central concern, and when done well, redundancy, in the Systems of Record (SOR), is greatly reduced because a common service will satisfy the needs of many customers, requests, and combinations of valid inputs.
An API, in modern usage, is designed in a consumer-centric manner. The architect creating an API will look to what the consumer needs while defining an interface. Speed to market and ease of use are the major concerns when the API is designed. Reuse should not be a concern at all.
Notice that I didn’t mention RESTful interfaces. While many API’s will have RESTful interfaces, REST is not a defining characteristic of an API. API’s can have SOAP interfaces and services can be RESTful. The focus of the design approach (consumer vs. provider-centric), is what differentiates API’s from services.
How Services and API’s work together to deliver the promise of API’s
While both API’s and Services live in the Systems of Integration (SOI), services reside on the edge of the Systems of Record (SOR). They extend the reach of the SOR’s and must be leveraged to ensure a consistent response to inquiries. Having tightly governed (mode 1) reusable interfaces, as the entry points to the SOR, ensures consistent and accurate responses. The risk of inconsistency and unpredictability, when a tightly governed service layer is not present, is the reason that API’s cannot be a replacement for the services and service oriented architectures.
With a solid SOA foundation in place for API’s to access, the need for governance of API’s is greatly reduced. Speed to market is also greatly improved because there are already well-defined interfaces available for the API’s to call when gathering information. Of course, the reduced governance also contributes to the increased speed to market.
Organizations with both API’s and services will be able to be truly bi-modal, with API’s following mode-2 type processes and governance. A ‘many API to one service’ configuration will be common. API’s will be built quickly, follow their own life-cycle, deliver consistent information, and give business the needed agility to deliver offerings to the market when they are needed.
I often use the analogy of the service layer being a buffet of information, while API’s are like a plate that can be filled with any combination of items (data/information), that the consumer wants. Figure 1 is an illustration of API and service layers working in conjunction.
Figure 1. API and service layers.
As can be seen in the figure above, API’s and services offer different benefits that compliment each other to enable business agility and response integrity.
– Jeffrey A. Leach