API-Centric Architecture: APIs Make Agile Data Possible
In previous posts in this series, we’ve looked at how modern applications are built, the rise of micro services architecture, and what this new application architecture means for services governance. We’ve also argued that integration patterns are not required in the DevOps world.
This time we examine the important difference between the way data is leveraged in the API-centric architecture and one based on integration technologies. One of the first casualties of the transition to an API-centric architecture is the practice of ETL (extract, transform, load).
Analytics APIs and the push and pull of data
In a pre-API architecture, many organizations find it necessary to have teams dedicated to extracting data by reverse engineering an app’s internal structures and accessing databases directly, bypassing application logic. In an API-centric architecture, every app is responsible for exposing its data in a structured way via APIs. The extraction phase can be eliminated and transformation is greatly simplified as a result. Another common practice is to provide an analytics API to the application developer; they can push data to it in the appropriate places in their code. Often times, both techniques will be used, allowing of analytics systems to easily harvest or pull data from various applications out of their APIs as well as enabling the individual applications to push data into the analytics system.
One aspect of the API-centric architecture that is particular relevant to discussions of data is related to the movement of interaction functionality into the client tier, as is the case with HTML5 and mobile. This clean separation of concerns means that most user interactions occurs over the API channel rather than within web page presentation. As a consequence, the metadata about context, such as user identity and interaction intent, can be derived by observing and inspecting the API traffic.
Context and predictive intelligence
Integration-centric architectures only cared about connecting systems together, and in most cases context was lost. However, the API-centric architecture allows context to be captured for business and operational purposes—a stream of contextual data can be sent to business intelligence systems and the signaling for operational monitoring systems helps ensure the overall health of the systems.
Taking this one step further, this contextual data can be used to drive context-aware applications, enabling the complete feedback loop. Personalization and recommendations are common examples of this, as are decision-support dashboards utilized by customer service personnel. To make this happen, the API-centric architecture leverages the API-based pull and push of application data to feed predictive intelligence engines that can then communicate back to the application via its APIs to drive actions. With an integration-based architecture, wiring up this kind of feedback loop would be cumbersome at best.
But with an API-centric architecture, applications can easily deliver the necessary data to the predictive analytics system and application developers can easily leverage the resulting feedback to build individualized user experiences by constructing and presenting UX elements tailored to the specific user.
Next time, we’ll wrap it up with a summary of the important implications this shift to the API-centric architecture has on today’s enterprise.