What is agile integration?

**This post was updated on September 26, 2018.**

If you Google the term “agile integration,” you’ll come up with about 30 million results, but they focus heavily on one area: continuous integration within agile development. That definition of agile integration is based on the build environment.

However, it is possible to have another definition for “agile integration,” one that looks at the platform architecture.

In this definition, “agile” doesn’t relate to the process or the infrastructure, but to the flexibility and adaptability--the agility--of the application architecture. Integration within this context has a more strategic role, as the architectural framework that defines the interoperability of services and with a focus on the application functionality.

Check out this e-book to learn more about Agile Integration: The Blueprint for enterprise architecture.

Traditional vs. agile as an architectural approach

There are functional similarities between traditional integration and agile integration - like routing, connectivity, and orchestration capabilities. The difference between traditional enterprise application integration and agile integration is not in the tasks performed, but in the strategic perspective of those tasks. Put simply, integration can be viewed as a necessary but often limited part of the infrastructure (traditional) or it could be viewed as the core framework of the application architecture (agile).

The problem that traditional integration tried to solve was how to funnel data from one application to another siloed application. With a traditional integration approach, integration through something like an enterprise service bus (ESB) simply provided a hub where service data could be mutually accessed by applications. This provided a way for applications to coexist independently, but the application design lay within those large-scale applications.

Integration in the traditional approach is a way of gluing those separate applications together in a way (generally) that let them share or reuse data, and this often led to centralized ESB type architectures and deployments. It treated integration as a component of the infrastructure.

Modern applications, though, are moving away from large-scale, monolithic  architectures to more loosely coupled architectures. Microservices break application functionality into small, independent services. That means there are no clear pathways between applications or centralized points where applications can transfer data, like when ESBs were the integration strategy. Rather, in a modern architecture, there have to be flexible ways for services to communicate with each other in ways that allow for elastic scalability―the ability to add (or drop) service functionality. The services are decentralized.

For agile development, the idea is to break applications (at least conceptually) along feature or functionality lines. The development cycle is in a brief, iterative sprint that creates a complete set of functionality for a specific set of tasks and then moves onto the next iteration. This development approach complements a microservices architecture naturally because microservices are small and discrete, with an explicit function and service boundaries.

Trying to use a traditional integration approach would fail because the service architecture itself is decentralized, while centralized ESBs assume a more rigid infrastructure with clear relationships between applications and well-established pathways for data transfers.

Agile integration is the approach that allows those microservices to be dropped into the architecture seamlessly or to be removed or updated without disrupting other services. Routing, orchestration, messaging, or data services are the points where a new service interacts with the environment. This is an application or service level perspective of integration.

Three pillars of agile integration

We define three core capabilities of agile integration, which work together to create an overall integration strategy:

• Distributed integration
• APIs
• Containers

Each of these hits a different aspect of agility and integration for both the infrastructure and for applications.

Distributed integration: Flexibility to adapt

Distributed integration is lightweight and API-based. Traditional integrations are centralized, but a distributed integration means functionality can be deployed where required and scaled as needed. Distributed integration is easier to include in applications or as part of microservices architectures. Red Hat Fuse provides distributed integration through a variety of connectors for different services and messaging.

APIs: Connect and manage efficiently

APIs provide an interface that allows users (internal or external) to connect to your business assets. This lets businesses extend their knowledge assets and maximize their business value. APIs also reduce the complexity of integration and improve collaboration.

Managing, securing, metering and analyzing API usage is critical to provide more competitive digital services. Create and connect APIs using Red Hat Fuse and manage APIs using Red Hat 3scale API Management.

Containers: Scale with demand

Containers can be used to develop, deploy, manage, and scale applications. Because containers use image catalogs for repeatability and can be managed programmatically, they provide a platform for continuous development and deployment. Containerized applications can be deployed in hybrid environments, on premise, or in private or public clouds. A container platform can orchestrate all of those applications automatically, which means containers are fundamental to microservices architecture.

Red Hat OpenShift Container Platform provides a container platform that handles orchestration and centralized management functions like monitoring and logging.

Read more

This post just touches on the concept of agile integration. The whitepaper covers a lot more on the concepts and technology for agile integration. Learn more about agile integration, and check out this e-book on Agile Integration: The Blueprint for enterprise architecture.