API-Centric Architecture: New Foundational Technology for Apps
Demand is continually increasing for contextually-aware, highly personalized, predictive applications, delivered to new types of clients, and built and deployed in tighter and tighter timeframes at ever-higher levels of scale. These requirements are pushing application architecture to move beyond the integration server/application server pattern that has characterized much of the last decade of web application development.
In previous posts in this API-centric architecture series, we’ve looked at how modern applications are built; we’ve argued that integration patterns are not required in the DevOps world; and observed the transition to an API-centric architecture that has resulted in the demise of ETL.
Businesses challenged with providing the right content and capabilities at just the right moment, for the right person, and on any number of devices are building applications that embrace a four-sided model of API architecture—app-to-client, app-to-backend, app-to-app, and the exploded app built from micro-service APIs.
This four-sided model means that not only can an application be built in an agile fashion, deployed at scale, and support any form of future front-ends, it can also easily be connected to every other application inside and outside the enterprise. It can also easily share the relevant data with analytics systems and in turn, deliver back data-driven, contextually-relevant actions based on real-time feedback loops driven from those same analytics systems.
An API-centric architecture has several important implications for enterprises:
Built for agility, scale, and communication: An API-centric architecture enables applications to be built in an agile fashion, future-proofed for new front-end technology, deployed at scale, and easily connected to other applications and systems inside and outside the enterprise.
Demise of the centralized service governance model: The rise of virtualization, IaaS, and PaaS, as well as a generation of internet developers with easy access to server resources, have all led to the demise of the centralized service governance model. SOA governance, which focused on centralized IT resources, has ceded ground to API governance, which focuses on supporting the application teams and agile and decentralized API-first architectures.
Integration models rooted in appliance-heritage products have no place in the automation-centric DevOps processes: New API use cases (especially those driven by mobile), as well as new API-centric and micro-service based development efforts, typically have little need for integration server technologies. As a result, heavyweight integration products have given way to a model where resources (including APIs and the systems they connect) are managed within the application tier by a set of DevOps automation tools designed for today’s agile enterprise.
APIs make agile data possible and ETL obsolete: In an API-centric architecture, ETL (extract, transform, load) becomes obsolete. Instead, every app is responsible for exposing its data in a structured way via APIs. Furthermore, the API-based pull and push of application data enables a complete feedback loop, and feeds predictive intelligence engines, which can communicate back to the application via APIs to drive actions.
Enterprises can no longer afford to view APIs as simply an extension and evolution of integration-based architectures that have long been in use within enterprise IT. APIs and API-centric architecture have become the foundational technology necessary for the development and deployment of robust and scalable enterprise applications.
For a comprehensive and detailed look at API-centric architecture, check out the free eBook APIs are Different than Integration.