Given the ever increasing information complexity, as well as the constant demand for enterprises' connectivity, the need for a good framework comes as no surprise.
Much, if not all, of the API-related technology is a victim, or rather a creation, of a framework-led approach. It really is only natural that integration, another IT branch in rise, should converge towards a common working model. Frameworks facilitate cooperation and make finding a common ground much easier.
In Mulesoft's whitepaper on the next step in the evolution of Service Oriented Architecture, API-led connectivity, a framework for ordering and structure API-led connectivity building blocks is proposed. According to Mulesoft, the focus of Three-layered API-led connectivity architecture is on agility and flexibility.
The core systems of record are not easily accessible due to connectivity and authentication concerns. System APIs take care of authentication. The data retrieved by them is often not in a user-friendly format, if human-readable at all. APIs' specifications in this layer are not likely to change very often since they are most probably set by a central IT. An estimated frequency of changes is 6-12 months.
The process layer encapsulates APIs that support the logic behind anything that happens to data between its retrieval in the system layer and its final presentation to the end user, as per that user's request.
Speaking of end users, the experience layer is the only layer of concern to them. The experience part, whatever we call it, is the most exposed and vulnerable layer, be it within or out of a framework-driven application. This is certainly another reason to encapsulate the APIs into appropriate layers. The experience layer is also subject to the most frequent changes – 4-8 weeks, depending on the size and the line of business.
Experience APIs are there to please the audience and ease the data consumption. The idea is to have a common data source and eliminate the need for potentially numerous point-to point integrations.
Three-layered API-led connectivity architecture
The proposed framework offers a context for application development and its subsequent maintenance. It provides guidelines regarding ownership and indirectly a rough workload estimate for each layer. We hope to see these well intended guidelines gain a wide consensus and acceptance.
LATEST FORUM UPDATES