Enhanced Design Pattern to Scale Enterprise API7:30 AM
In organization you see multiple application handling operation like inventory management, sales/b...
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 OrganizationLets 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
Lets start refactoring approach by breaking down API into layer so that we can reuse them and refactor them fairly easily
Refactoring API into Layers
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.
In the second part of this post, I'll continue to talk about building governance model on top of this pattern, stay tuned