Is your company ready for API Economy?
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.
The main characteristics of the system architecture are:
- monolithic applications (Application Layer)
- 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), 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.
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 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.
Under technical perspective, other characteristics are observed:
- Usage of commercial or open source API Platforms and their modules
- Usage of Developer Portal to increase Developer Experience of partners and startups
- Usage of Analytics Modules to monitor technical and business behaviors
- Strong security constraints applying WAF and DDoS protection.
- RESTful APIs as standard for external integration.
Level 7: APIs as Business
As the name suggests, companies at this level the run their businesses totally based on APIs.
Below are the mandatory technical characteristics observed:
- Strong API Strategy
- Full governance of external and internal APIs (including between services and microservices)
- Usage of full capabilities of API Platforms
- Strong compliance with regulations (e.g PSD2)
- Mature microservice architecture using service mesh
- Strong cloud-based infrastructure and foundation
- Multiple managed communication protocols such as RESTful, GraphQL, WebSockets, gRPC, etc.
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!
- Choose an MVP project to validate your assumptions, start small, test, learn and apply recommendations
- Start with internal and controlled APIs
- Define some API patterns and establish minimal API governance.
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.
If you want some help on this journey, you can contact us!
This article originally appeared on Sensedia.
