What is integration?

IT integration, or systems integration, is the connection of data, applications, APIs, and devices across your IT organization to be more efficient, productive, and agile. Integration is key when discussing business transformation—fundamental changes in how you conduct business to adapt as the market shifts—as it makes everything in IT work together. Integration not only connects, but it also adds value through the new functionalities provided by connecting different systems’ functions. For instance, Apache Kafka is an open source platform that allows you to integrate streams of data with your applications, so they can act on data in real-time.

IT integration isn’t the same as continuous integration (CI), which is a developer practice where working copies of code are merged into a shared central repository multiple times a day. The goal of CI is to automate build and verifications so problems can be detected earlier—leading to faster development.

As IT systems grew and developed over time, they started to sprawl away from one another. One vendor’s solutions didn’t communicate with another’s. Next thing you knew, you had an entire IT stack that was connected only by the fact that you owned it all. So there needed to be a way to organize this technology "spaghetti" to stop duplicating efforts—especially when it came to implementing and acting on business logic.

*Note: The following is subject to debates about semantics: physical topologies vs. logical topologies, approaches versus architectures versus technologies. The explanations below are intended to be general overviews.

Enterprise application integration

A solution to all of this disparate sprawl was enterprise application integration (EAI), which is technologies, tooling, and a framework that implements real-time, message-based integration between apps. These messages are triggered by changes or parameters built within the individual apps. EAI was accomplished in one of 2 ways, point-to-point and hub-and-spoke.

The point-to-point model meant that each application had to be customized to talk to the other applications and pieces of your IT. This is all customized for each IT asset and for each asset that it connects to. This is also very tedious work and, understandably, highly error prone. To further complicate things, as you update your infrastructure and apps this model can be very hard to maintain over time.

To solve this, there’s the hub-and-spoke model, where the connections between apps and services are handled by a central broker—the hub. The spokes that connect the hub to the apps and services can be individually maintained. This allows the apps themselves to be more focused, with all arts of integrations handled via the hub and spokes. The main downside to this approach is the centralization of the hub. It becomes a single point of failure for the system and for your infrastructure communications. All integrations in the EAI hub-and-spoke model is, by design, dependant on the hub to function.

The enterprise service bus

Following the EAI hub-and-spoke approach was the enterprise service bus (ESB), a tool providing message-based abstraction—modularizing services between applications.

An ESB also acts as a central hub where all of these modularized services get shared, routed, and organized to connect your apps and data to one another. It’s a better solution to the EAI hub-and-spoke, but perhaps not the end-all as organizations grow, add assets, and need more speed across all of their properties and software resources.

By now you’ve surmised that an ESB looks a lot like the hub-and-spoke model. This is true, but an ESB has some very distinct features that set it apart in terms of functionality.

• ESBs present themselves as a service using open standards. This removes the need to write unique interfaces for each application.
• Integration services can be deployed with minimum changes to applications.
• ESBs rely on industry-standard, open protocols and interfaces to ease new deployments.

However, typical ESB deployments often lead to centralized architectures for obvious reasons mentioned in the hub-and-spoke model—one place to host and control all integration services. But the centralized ESB deployments and architectures come with rigid central governance which doesn't help deliver faster and more adaptive solutions which are the foundations for digital transformation initiatives. Furthermore, ESBs often become monolithic applications themselves.

Agile integration

So far we’ve discussed integration itself—the technologies that make everything work together. So, what’s agile integration? Put simply, it’s how Red Hat sees the future of connected systems and how they support the real work your IT teams must accomplish to thrive—especially as change occurs more frequently.

Red Hat believes that the traditional approach to integration, with centralized teams controlling monolithic technologies, can impede the development and long-term usefulness of distributed applications. Traditional integration technologies like the ESB have benefits like prioritizing security and data integrity, but they also rely on a single team to define integrations for the entire enterprise.

Today’s loosely coupled, cloud-native application architectures developed through agile and DevOps methods need an equally agile and scalable approach to integration. Red Hat’s view of agile integration is just that, an approach to connecting your resources that combines integration technologies, agile delivery techniques, and cloud-native platforms to improve the speed and security of software delivery. Specifically, agile integration involves deploying integration technologies like APIs into Linux containers and extending integration roles to cross-functional teams. An agile integration architecture can be broken down into 3 key capabilities: distributed integration, containers, and application programming interfaces.