As organizations adopt more API centric approaches to system connectivity, effective API architecture is required to ensure a coherent API strategy across the enterprise and ensure that executives, business, and technical teams are aligned and have buy-in on the API strategy and target state architecture.
Of foremost importance is to define, and get buy-in, on what the enterprise wants to achieve with their API strategy, and what the business value proposition is. In today’s world, API’s can be a sellable product in themselves (SaaS / API as a Service), part of an orchestrated effort to provide value-add services and information to customers, partners, or suppliers, and/or to streamline and abstract information and services across the enterprise to streamline development and re-use of services, amongst other things.
Once the goals of the enterprise are clearly defined in relation to API strategy, it’s important to work towards an API target state architecture, and communicate and ensure the strategy is executed across the organization.
What is API Architecture?
API architecture covers a broad range of enterprise, business, and technical capabilities. It’s way beyond just deploying a set of microservices orchestrated by Kubernetes, and it’s more in depth than just procuring an API Gateway and fronting your inbound API requests with it. In fact, API architecture encompasses those things, but it goes way beyond that, and includes, but is not limited to:
- Non-functional requirements, including: scalability, caching, rate-throttling, etc
- Usability – online traditional applications, API’s customers are, generally, developers. The API architecture needs to consider how developers will consume the API, the complexity of consuming the API, and importantly it will ensure that developers want to use the API.
- Discoverability – Developers need to know which API’s exist and how they can be used. They need to be able to get this information quickly.
- Design Standards, and Governance – Acceptable design patterns, technology stack, and usage guidelines all need to be incorporated. There also needs to be defined governance to ensure compliance with the target state architecture and ensure there are adequate avenues to negotiate implementation when constraints prevent solutions from meeting design guidelines.
- Security – Standards on how API’s are secured, how they are accessed, and how authorization and authentication are handled. Different logical API layers may require different security, authorization, and authentication schemes.
- Infrastructure – The underlying topology and physical components need to be defined.
- API layers, frameworks, and platforms – Define which technology to be used, where and how it will be used, in order to support your enterprise API target state.
This article will focus the logical API layers which can form part of an API centric architecture for an enterprise as one way in which API centric logical architecture is implemented across organizations.
High Level Logical API Layers in an API Centric Enterprise
Let’s break each of these logical tiers down. Each of these logical layers could take many different forms depending on the goals of the enterprise and chosen technology stack. That will be discussed later (future article).
Client Connectivity: Your API consumers are generally developers. Even if you are exposing your API as a product in order to attract new business or as part of value-added offering to existing customers, ultimately, it’s your customers’ developers who will be consuming your API. This logical tier is the “presentation layer” which consists of web applications, dashboards, mobile apps, etc which, depending on the capabilities you are providing, will be internal or external to your organization.
Experience APIs: Experience API’s are paramount to effective API adoption. Your experience APIs are the API’s consumed by your presentation layer (the apps). The Experience API logical layer is the first point of contact when making an API request. Depending on your business goals and value proposition, the Experience API may be accessed by internal applications, external applications, publicly accessed as an Open API by internal, external, contract, or 3rd party service developers.
Careful consideration must go into the Experience API, and you need to know who your intended consumers are. Part of architecture is architecting to ensure user adoption so that the business value stream is realized. Knowing who your consumers are, how they should and how they want to access the API, and how to provide the service and data in the most useable and straightforward way possible is key to effective API adoption.
Experience APIs are designed to satisfy a specific “experience”. It’s crucial to design your Experience APIs to target a specific type of consumer, business domain, or application rather than implementing a one-size fits all solution.
Process APIs: Process APIs should be called by the Experience APIs and are the place to maintain business logic and where orchestration can take place. Process APIs are the conduit in between Experience and System APIs. Process API’s don’t access back-end data directly, but get data from backend systems by way of using System APIs designed for that purpose.
System APIs: The role of System APIs is to push and pull data from backend systems. System APIs aren’t concerned with business logic, and are the conduit to expose system data to your consuming Process APIs. System API’s can provide API services for all kinds of backend systems, including modern and legacy solutions.
Data Storage and The Wild West: This is where your persisted storage resides, and where your System APIs push and pull data to and from. Your System APIs are built for this data which could be a Wild West of modern, legacy, on-prem, and cloud applications using a wide variety of technology and platforms.
Conclusion
Logically defining your API tiers is a fundamentally important part of API architecture and is critical to ensuring the business value of the API is realized. Your target audience and the capabilities you want to provide will help guide architectural decisions. When considering an API centric strategy for your enterprise, the logical tiers need to be fundamentally understood across the organization by technology teams, business sponsors, and executives.
In an upcoming article, I dig deeper into API architecture and concepts that need to be understood in order to make significant decisions that impact the architecture and fundamentally help ensure the success of the overall API architecture and strategy. Stay tuned.