.png){kind=small}
.png){kind=small}
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.
This maturity model is divided in 7 levels grouped in 3 general classifications which they are:
This maturity model present 7 levels which the companies can be classified in, they are:
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.
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:
This level refers the system architecture are based on components, the main architecture models used here are:
Also, the main integration technologies are:
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.
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:
And the integration technologies are:
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.
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:
And the main integration technologies used are:
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.
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:
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:
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:
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 ;)
