Is Your Company Ready for a Successful API Economy?

Is your company ready for the API Economy in today’s world and beyond?

Every year, architects and digital strategists must plan for the year ahead if they want their company to participate in the new  API Economy. The first thing they should do is look at what's happening now and see if their company is ready to work with APIs. After they understand where they are, they can decide where they want to go.

In this scenario, the system architecture and its integration platform play pivotal roles. For instance, applications can scale up when the company opens its APIs. When it comes to integrations, standardized DevOps practices are imperative, as APIs serve as the DX platform and require specific technologies.

To help identify the current and desired conditions, we can use an API maturity model specific to the system and integration architecture, which will support the API strategy.

API Architecture Maturity Classifications

This maturity model is divided into seven levels grouped into three general classifications, which are:

• Not based on APIs: The system and integration architecture is not based on formal APIs. In some cases, there needs to be more communication. In others, they usually share files, use queues, unstructured web services, or even make some TCP/Socket technologies to communicate between applications.

• Partially based on APIs: The system and integration architecture is partially based on APIs, which means it has intense 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).

• Entirely based on APIs: The system and integration architecture is wholly based on APIs, which means there is a separation of concerns between layers like API, Services, and Applications. 
  

From a business perspective, the APIs are the foundation of new business models, or the business itself depends on APIs. Also, other technical characteristics and capabilities are observed, like solid security mechanisms, API governance, monitoring, analytics measures, and improved API Developer Experience.

‍

Levels

This maturity model presents seven levels in which the companies can be classified:

‍

Level 1: Isolated Applications

In this case, the system architecture is based on isolated applications with no/low API connectivity. The main types of applications are monolithic and off-the-shelf applications like ERPs or CRMs.

Level 2: Unstructured Integrations

There are integrations between applications, but they are unstructured, which means there are no standards for message structure or technologies to be used. 

Also, the integration channels are decentralized (point-to-point), and there is no hub or bus – the integrations are created in an 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 to the system architecture based on components. The main architecture models used here are:

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

Also, the leading integration technologies are:

• TCP/Sockets (e.g., Java RMI, COM, EJB)
• Custom socket connections
• HTTP Endpoints (e.g., SOAP, RPC over HTTP)

The main challenge at this level is the need for improved interoperability in integrations and interfaces. The technologies used typically communicate only within the same technology, except for web services. However, these services often require adherence to standards and some form of API governance, making it challenging to maintain API connectivity and interoperability.

‍

Level 4: Service-oriented Architectures

At this level, the system architecture uses SOA principles. For example, concerns are separated between the Services and Application Layer. When the application layer relies on business and data storage capabilities, the services layer refers to contract standardization, abstraction, composability, discovery, etc.

The main characteristics of the system architecture are:

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

The integration technologies are:

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

Finally, the main issue related to this level is the need to separate concerns between the Service and API Layer (see picture below). It only has a Service Layer, and some API capabilities are incorporated.

‍

‍

Level 5: Private APIs based on Microservice Architectures

At this level, the system uses the microservice architecture approach. Usually, it has two layers: the Front-End Layer and the Back-End Layer, where microservices reside. 

In this architecture, integration platforms provide the connection between Front-End and Back-End. We classify it as Private APIs because only internal front-end applications use them.

The main characteristics of the system architecture are:

• Usage of Microservice Pattern
• API Gateways
• It is primarily based on cloud infrastructure and containers.
• Incipient usage of Service Mesh Architecture

The primary 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.

At this level, the main important issue with APIs is the need for comprehensive management. API Management Platforms utilize specific capabilities like security and throttling, which a single API Gateway cannot provide.

Another crucial characteristic is the APIs of Microservices are also not managed, which means the communication is point-to-point without centralized governance (missing mesh architecture capability).

Another point to be observed is that the architecture based only on single API Gateways is challenging for the entire company to be extensible. We strongly recommend the usage of an API management 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 technical characteristics from other levels. Still, the main technical feature is to have an API Layer on top of the Service Layer, Application Layer, or even Back-end Layer (Microservices).

In this case, Open APIs are part of a company's business operations. It means they can create a partnership ecosystem and open innovation environment. This scenario creates a new value stream and innovative services.

From a technical perspective, other characteristics are observed:

• Usage of commercial or open source API Management Platforms and their modules as listed below
• Usage of Developer Portal to increase Developer Experience of partners and startups
• Usage of Analytics Modules to monitor 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 suggests, at this level, the company business is based and is wholly dependent on APIs.

From a technical perspective, some characteristics are mandatory:

• Strong API Strategy
• Full adaptive governance of external and internal APIs (including between services and microservices)
• Usage of full capabilities of API Platforms (as described on level 6)
• Maintain substantial regulatory compliance (e.g., PSD2)
• Mature microservice strategy using a service mesh architecture
• Robust cloud-based infrastructure and foundation
• Multiple managed communication protocols include RESTful, GraphQL, WebSockets, gRPC, etc.

‍

The Maturity Roadmap

Once you have assessed your company and realized which level your company desires to be, you can create a roadmap for the evolution. 

Of course, the details of this digital transformation depend on various factors such as business drivers, technical constraints, and future perspectives.

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

• First, move from level 4 to level 5 instead of level 4 to level 7. Baby steps!
• Choose an 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.

‍

Takeaways

Effective API management is non-negotiable to thrive in the API Economy. Regardless of your company's current level, initiating an API Strategy and building partnership ecosystems around APIs is vital. This article emphasizes the importance of gauging architectural maturity for informed technical decisions aligned with business needs.

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

Ready to embark on the journey to business transformation? Connect with our specialists by filling out the form below. Let's elevate your API game together!

‍