Enhanced Design Pattern to Scale Enterprise API

In organization you see multiple application handling operation like inventory management, sales/business management, analytics, e-commerc...

In organization you see multiple application handling operation like inventory management, sales/business management, analytics, e-commerce, shipping services, communication services (like Twilio) and much.

To get information from these system, engineers quite often end up spinning a custom API for applications to meet business needs,  but these API/Service are bonded to application and fail to scale at enterprise level.

As org scales, more application comes in picture which in-turn end up having more application level API and sooner it ends up like a old telephone exchange system (comprising of maze of wires) talking to each other.

See picture blow to understand how a bloated organization look like with time



Well structured plan and pattern for designing enterprise driven API can significantly boost flexibility of evolving architecture and organization needs.  Lets talk more on how we can resolve this, by assuming a scenario

Typical Organization

Lets begin understanding by simple example for an org, where inventories are managed in ERP system (SAP), e-commerce system (Demandware) and Salesforce holding customers data.

Traditional approach would be look at where your data is coming from, look at where you write or design business logics and design an integration project.


1. Pull up customer data from SAP and Salesforce via API, combine business logic in service
2. Derive order-history from e-commerce system and Salesforce to track customer-orders
3. Use e-commerce and business service to derive order status


This looks great, promising and on-time application architecture and logic looks pretty de-coupled but it will work only for 'this application'


After six beautiful months, customer starts demanding mobile application and business team decides to offer service for mobile and guess what ? The mobile team gonna do it again, and your architecture may look like this now




Refactoring API into Layers 

Lets start refactoring approach by breaking down API into layer so that we can reuse them and refactor them fairly easily


System level API 

Lets wire SAP and Salesforce to produce a customer data feed to data API, and then lets write a combined feed API that mix and match data from two worlds as another API called Customer Feed API.

This allow developer to unit-test against that particular piece of the project and make it natural and easy to expose and reuse these API, that is the key observation here.



Similarly with order data in your e-commerce system, expose order data feed as an API. The exposing of data in a kind of API can be called as System Level API or Data Access Layer API's. Since these are systems you would be interacting with and everything on top of it will be an API, this core and below this layer you deal with systems directly.

Process Level API 

To know order status and order history, you can trace the data our from the System Level API and apply business logic on top of it. This layer deals with your business and formulate to consumers



Presentation Layer API and Complete Model


Since data formulate is de-coupled, segregated from on process level API. You can clearly write dedicated application level API to serve dedicated data experience. Data messaging, formatting logic can be served here and endpoint can be exposed for application or consumers from here.


After six months when Mobile application comes into scene only presentation layer will add another API to formulate data for Mobile keeping everything underneath we structured consistent and uniform across the organization thereby offering enterprise level API experience. Now you got your developers investing in innovation rather and recreating the wheel again and again.



In the second part of this post, I'll continue to talk about building governance model on top of this pattern, stay tuned

What Others Are Reading