7 Layers of API Architecture Maturity

This is the reflection for new year’s resolutions which architects and digital strategists must make in order to planning next year, if they desire their company to join the new API Economy. But this initial reflection must identify the current conditions and how mature the company architecture is in order to support API initiatives, and after assessing the current condition, define the desired future condition.

But what kind of architecture is crucial in this scenario? Basically the system architecture and mainly their integration architecture. System architecture is essential for business purposes, for example, the applications can scale up when the company open their APIs? And how about integrations? Basically APIs are the interface of the integrations which requires some standardization and technologies.

To help them to identify the current architecture state and to plan the target architecture, we can use a maturity model specific for the system and integration architecture which will support the APIs initiatives.

API Architecture Maturity Classifications

This maturity model is organized in 7 levels, grouped in 3 general classifications as shown below:

Not based on APIs: the system and integration architectures are not based on formal APIs, in some cases there are no communications at all between applications, and sometimes files sharing, queues, unstructured web-services or even TCP/Socket technologies are used to provide communication between applications.

Partially based on APIs: the system and integration architectures are partially based on APIs, meaning there is strong adoption of SOAP and RESTful Web-services, using resources like Service Repository and Developer Portal but with low governance, standardization and separation of concerns (between APIs and Services).

Fully based on APIs: the system and integration architectures are fully based on APIs, meaning separation of concerns between layers like API, Services and Applications is in place. In business perspectives, the APIs are the foundation of new business models or business has a direct dependency on APIs. In addition, technical characteristics and capabilities are observed, like strong security mechanisms, API governance, monitoring, analytics and improved API developer experience.

Levels

This maturity model contains 7 classification levels. See below:

Level 1: Isolated Applications

The system architecture in this case is based on isolated applications with no/low integrations. The main types of application are: monolithic applications, off-the-shelf applications like ERPs or CRMs.

Level 2: Unstructured Integrations

There are integrations between applications but they are unstructured, it means there are no standards for message structure or even technologies to be used. Also the integration channels are decentralized (point-to-point), there is no hub or some kind of bus – the integrations are created ad-hoc to solve a particular problem. Usually technologies used are:

Message Queues

Socket connections

Database replications

File sharing (e.g XML, CSV or EDI)

Level 3: Component-based Architectures

This level refers to system architectures based on components, the main architecture models used here are:

EJB (Enterprise Java Beans)

CORBA

Microsoft COM/COM+/DCOM

Standalone Web-Services Applications

Main integration technologies are:

TCP/Sockets (e.g Java RMI, COM, EJB)

Custom socket connections

HTTP Endpoints (e.g SOAP, RPC over HTTP)

The main issue found in this level is that integrations and interfaces have no or very poor interoperability because the technologies used only communicate with the same technology on the other side. Web-services are an exception, but usually they don’t follow standards and there isn’t any kind of governance in place, which makes interoperability harder to maintain.

Level 4: Service-oriented Architectures

In this level, the system architecture implements SOA principles, for example there are separation of concerns between Services Layer and Application Layer. Usually the application layer relates to business and data storage capabilities, and services layer refers to contract/interface standardization, abstraction, composability, discovery etc.

Finally, the main issue related in this level is: there is no separation of concerns between Service and API Layer (see picture below), the Service Layer comprises some API capabilities as well.

Level 5: Private APIs based on Microservice Architectures

In this level, the system architecture uses the microservice approach. Usually there are two types of layers: Front-End Layer and Back-End Layer where microservices resides, in this kind of architecture, the role of the API Gateway appears in some cases to provide integration between Front-End and Back-End. We classify as Private APIs because only internal front-end applications uses those APIs.

RESTful APIs (exposition to front-end or even communication between microservices)

AMQP (e.g Kafka, RabbitMQ, etc)

Incipient usage of new communications protocols such as gRPC, Thrift, etc.

But, the crucial issue related to APIs in this level is that APIs are not fully managed. Only some capabilities are used such as security and throttling, these are provided by an API Gateway. Another important characteristic is that APIs exposed of Microservices are also not managed, which means the communications are point-to-point without centralized governance (missing mesh architecture capability).

Another point to be observed, the architecture is based on a single API Gateways, that is not easy to be extended to the entire company, a strong recommendation is to adopt an API Platform to sustains the evolution of this kind of architecture.

Due to all the issues described above, we classify this level as partially based on APIs.

Level 6: Open APIs

On this level, the company usually has some technical characteristics of the other levels, but the main technical characteristic is to have an API Layer on top of the others.

In this scenario, APIs are an important part of business as it supports business growth. Companies can create partnership ecosystem and open innovation environment, to support the creation of new value streams and innovative services.

The Maturity Roadmap

Once you have assessed your company and realized the current level and which level your company desire to be, you can create a roadmap for the evolution, of course the details of this plan depends on various factors such as business drivers, technical constraints and future perspectives.

However, when you are creating your plan, we recommend you consider some tips, for example:

First of all, move from level 4 to level 5 instead from level 4 to level 7, baby steps!

Conclusions

In fact, to participate in some way of the API Economy, your company needs to manage your APIs for internal or external contexts. No matter which level your company is placed on, the company can initiate the creation of an API Strategy, for example to target the creation of a partnership ecosystems built upon APIs.

The main focus of this article is point how mature is the architecture based on some scenarios to understand what is the best technical solution and technical strategy to be implemented in order to provide a mature API Architecture according to business and technical requirements.