- On November 24, 2019
Many enterprises find themselves at a crossroads when it comes to managing their dependency on legacy systems, difficult to coordinate with more forward-thinking technology integrations like cloud-native apps and IoT. It is the reason many businesses struggling to remain competitive in the face of continuous digital evolution. Let’s look at how many organizations ended up at their current crossroads, trying to balance their reliance on old technology with an increased need for speed and flexibility.
From SOA to ESB to APIs
The original intent of service-oriented architecture (SOA) was to separate the implementation of services used by an enterprise from the interface. Ideally, you would not have to know what was happening beneath the hood. A consumer could send a request to a specific endpoint with a contract outlining their needs that could provide the expected response.
The primary mechanism of handling these requests was via easy-to-use interfaces like web services. However, what was meant to be a simple back-and-forth began breaking down as user and organization needs began evolving. Sometimes a back-end system too out-of-date to support newer requests from evolving interfaces that wanted faster responses.
That need to handle the disparities between old systems and new protocols gave birth to Enterprise Services Bus (ESBs). They were the mechanism by which integration runtimes could centralize the way different applications handled web services using SOAP/HTTP.
The Challenges of ESB
ESB became a bottleneck to roll out new applications and features instead of serving its main purpose as an accelerator. Centralized ESB usage had the potential to provide a lot of savings. The problem came in with the way ESBs were structured. Since they were meant for enterprise-wide usage, it required a lot of overhead when it came time to make changes.
Adding a button to the screen of one platform meant making sure every other application connected to the ESB received related code updates. Maintaining ESB brought the following headaches for DevOps with every potential change.
- A potential destabilization of unrelated applications running on the centralized ESB
- The need for continuous live patches for various integrations
- The expense involved in disaster recovery and keeping the ESB at high availability
- A lack of understanding of the underlying infrastructure of ESBs among integration teams
- An inability to maintain updated documentation around applications running on the ESB
Many enterprises found themselves running into delays for simple changes thanks to a complicated approval process. That led to frustration among the technology staff and delays in pushing out application changes.
The Need for Further Decentralization
Application Programming Interfaces (APIs) represented a step forward in providing platform independence. They focused on allowing a consumer to interface directly with a specific component without affecting other applications. Consumers and devices could use an API from any geographical location. However, API availability could not fully meet the broader technology needs of enterprises looking to expand their capabilities.
Agile Integration - IBM Whitepaper
Send download link to:
Understanding Agile Integration Architecture
Agile integration architecture brings together three essential features of modern technology capabilities.
- Containers — Containers allow organizations to create independent virtualization units containing separate application environments, powered from one underlying OS kernel.
- Distributed Integration — Distributed integration can be thought of as a more flexible implementation of an ESB. The architecture is a unique implementation with no tie to other components. Teams gain the ability to manage applications and deployments, making for speedier changes and delivery of products.
- APIs — APIs make integrations between different applications possible while providing them with autonomy.
Agile integration architecture moves organizations away from the silo approach of traditional SOA implementations and toward the concept of microservices. Organizations would no longer have to maintain a big silo of code with complicated dependencies.
Instead, each component runs independently of each other, using an individual runtime, file-based system, and container infrastructure. Each could implement a unique way of interacting with legacy systems in a way that met the application’s needs without affecting other business systems.
Microservices makes it possible for developers to use cloud-native infrastructure that scale as needed and run online 24/7. It also improves the enforcement of DevOps ownership standards, making teams responsible for the lifecycle of components they develop. Agile integration architecture provides developers with more speed and flexibility when it comes to expanding the capabilities of new and existing platforms.
The independence provided by microservice architecture allows a business area to move forward with adding a new textbox to the screen of business applications. Teams gain the ability to understand how their platform works beneath the surface without being dependent on help from other technology areas. They can expand application capabilities based on business needs without experiencing bottlenecks.
How Agile Integration Affects Your Digital Transformation Strategy
Organizations already familiar with concepts like containers and microservices will have an easier time shifting towards agile integration. Enterprises at the starting point of that journey will need to account for an investment in training staff and investing in the technology.
Many businesses continue relying on a mix of traditional SOA architecture alongside more flexible microservice implementations. One benefit of moving towards agile integration is a better alignment of the needs of developers and DevOps teams. It can smooth out some of the conflicts that come with wanting an application built correctly versus meeting a deployment deadline.
Agile integration allow for more interactions between areas that typically would not have the opportunity to interact unless something happens to adversely affect an application release. It also helps to create a shared technology stack to enforce some consistency in how different areas implement technology like cloud-native apps.