APIs & Integration Strategy
min of reading
January 2, 2019

API Architecture Maturity Model

Rafael Rocha
Head of Solutions and Presales
A technologist degree in Information Technology from UNESP and a postgraduate degree in MBA Business Management from UNIMEP.
More about the author

Is your company ready for API Economy in 2019 ?

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

But which kind of architecture is crucial in this scenario ? Basically the system architecture and in special their integration architecture. System architecture is special essencial for business purpose, for example, the applications can scale out when company open theirs 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 condition and the desired future condition, 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 divided in 7 levels grouped in 3 general classifications which they are:

  • Not based on APIs: the system and integration architecture is not based on formal APIs, in some cases there are not communication and other they usually share files, uses queues, unstructured web-services or even make some TCP/Socket technologies in order to provide communication between applications.

  • Partially based on APIs: the system and integration architecture is partially based on APIs, it means has strong usage 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 architecture is fully based on APIs, it means there are separation of concerns between layers like API, Services and Applications. In business perspective, the APIs are foundation of new business models or the business itself depends of APIs. Also others technical characteristics and capabilities are observed like strong security mechanisms, API governance, monitoring, analytics measure and improved API developer experience.


This maturity model present 7 levels which the companies can be classified in, they are:

api architecture maturity model - Sensedia

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 in ad-hoc way. Usually, the integration technologies used here are:

  • Message Queues
  • Sockets connections
  • Database replications
  • File sharing (e.g XML, CSV or EDI)

Level 3: Component-based Architectures

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

  • EJB (Enterprise Java Beans)
  • Microsoft COM/COM+/DCOM
  • Standalone Web-Services Applications

Also, the 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 of this level are the integrations and interfaces has not or poor interoperability because the technologies used here only communicate with the same technology. Except for Web-services, but those web services usually do not follow standards and some kind of governance which makes interoperability harder to maintain.

Level 4: Service-oriented Architectures

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

The main characteristics of the system architecture are:

  • Monolith applications (for Application Layer)
  • Usage of SOA Stack (ESB, BPEL, Complex Event Processors, Service Registers, etc)
  • On-premise infrastructure

And the integration technologies are:

  • SOAP Web-Services
  • RESTFul Web-Services (but incipient usage)
  • Messaging (e.g JMS, ActiveMQ, etc)

Finally, the main issue related in this level is there is no separation of concerns between Service and API Layer (see picture below), only has a Service Layer which some API capabilities are incorporated on this layer.

Service and API Layer

Level 5: Private APIs based on Microservice Architectures

In this level, the system architecture uses the microservice approach. Usually has two kind of layers Front-End Layer and Back-End Layer where micro-services resides, in this kind of architecture the role of 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.

The main characteristics of the system architecture are:

  • Usage of Microservice Pattern
  • API Gateways
  • Mostly based on cloud infrastructure and containers.
  • Incipient usage of Mesh Architecture

And the main integration technologies used are:

  • 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 main crucial issue related about APIs in this level is the APIs are not fully managed, it means only some capabilities are used such as security and throttling which is provided by a single API Gateway. Other crucial characteristic is the APIs of Microservices are also not managed which means the communication are point-to-point without centralized governance (missing mesh architecture capability)

Another point to be observed is the architecture based only single API Gateways is not easy to be extensible for entire company, we strong recommend the usage of API Platform to sustain the evolution of this kind of architecture.

For all those issues related above, we classify this level as partially based on APIs.

Level 6: Open APIs

On this level, the company usually has some of technical characteristics from others levels, but the main technical characteristic is to have an API Layer on top of Service Layer, Application Layer or even Back-end Layer (Microservices).

In this case, APIs is part of company business once their business are increased by APIs. It means they can create a partnership ecosystem and open innovation environment, this scenario create new value stream and innovative services.

Under technical perspective other characteristics are observed:

  • Usage of commercial or open source API Platforms and theirs modules as listed below
  • Usage of Developer Portal to increase Developer Experience of partners and startups
  • Usage of Analytics Modules to monitoring technical and business behavior
  • Strong security constraints using WAF and DDoS protection.
  • RESTful APIs as standard for external integration.

Level 7: APIs as Business

As the name suggest, in this level the company business is totally based and is fully dependent of APIs.

In technical perspective some characteristics are mandatory:

  • Strong API Strategy
  • Full governance of external and internal APIs (including between services and microservices)
  • Usage of full capabilities of API Platforms (as described on level 6)
  • Strong compliance with regulations (e.g PSD2)
  • Mature microservice architecture using service mesh
  • Strong cloud-based infrastructure and foundation
  • Multiples managed communication protocols such as RESTful, GraphQL, WebSockets, gRPC, etc.

The Maturity Roadmap

Once you have assessed your company and realized which level is and which level your company desire to be. You can create a roadmap for the evolution, of course the details of this plan depends of 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!
  • Choose a MVP project to test some points, start small, test, learn and apply recommendations
  • Start with internal and controlled APIs
  • Define some API patterns and establish minimal API governance.


In fact, to participate in some way of 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 start an API Strategy for example create partnership ecosystems built upon APIs.

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

If you want some help on this journey, you can contact us!

Do you want to know more? Talk to one of our specialists, just fill the form below and soon we will get in touch ;)

subscribe to our newsletter with exclusive content.

Click and join the Sensedia News!

Click and join the Sensedia News!

Click and join the Sensedia News!

Thanks for reading!