Eliminating Point-To-Point Integration Pain with Mule ESB - Use Cases
Point to point integration is a quick fix that can just as quickly turn into a big headache. When your infrastructure only has a few components, point to point integration can seem like a lightweight way to connect everything together. Unfortunately, things won't stay lightweight for long.
As many organizations have learned the hard way, an infrastructure based on point to point integration quickly becomes unmanageable, brittle, and damaging to both the IT budget and the organization's ability to meet current and changing business demands.
If you are still using point-to-point integration with more than three systems, or are considering future expansion, you can't afford to wait. This article will help you understand why point-to-point integration causes problems for enterprise infrastructures, and how you can address these problems before they start.
First, we'll take a closer look at some of the problems caused by point-to-point integration, so you can make an informed assessment about your infrastructure's current health.
Then, we'll show you how two companies facing real-world integration issues just like yours were able to eliminate point-to-point pain from their infrastructures using Mule ESB.
By making Mule ESB's flexible, intuitive, and scalable integration platform the center of their new architectures, AllConnect and Nespresso solved their existing problems while preparing their networks for a smooth incremental migration to SOA. The results: Pain-free integration, greater business agility, and plenty of room to grow - without the hazy ROI timelines and vendor lock-in of proprietary solutions.
The Point To Point Integration Trap
No organization plans to have integration problems. Rather, point-to-point integration tends to build up over time due to sudden changes in business requirements. Teams are often too overloaded with existing infrastructure problems to make time for better planning, or assume that more sustainable solutions are too expensive or unproven.
It often takes a major "fire" - a bloated IT budget that can no longer be met, developer mutiny, or an update to a single part of the infrastructure that causes the rest of the components to fail - to make an organization realize the true extent of their integration problems.
Why is point-to-point integration so harmful to your infrastructure?
Reason 1: Exponential Increase in Complexity
It can be diffcult to see when you're only working with 2 or 3 architecture components, but the number of point-to-point connections needed to integrate a given number of components increases exponentially as additional systems are added. This is an especially serious problem for companies that rely on connectivity with an increasing numbers of partners as a part of their business model.
For a project involving only 3 components, you'll need only three connections. However, adding just two more components changes this number to ten connections. Full scale enterprise networks, with 10 or more components, will need 45 or more connections. Every one of these connections represents lost development hours in addition to potential hours lost on documentation and maintenance.
We say 'potential hours' here because many teams do not have the resources to keep all of their connectors up to date or refractor them to take advantage of the latest technologies, resulting in a large, undocumented tangle of code that also happens to be the most mission critical part of the company's infrastructure.
Reason 2: Single Points Of Failure
No matter what integration architecture you use, avoiding single points of failure should always be a top priority. Your integration components, due to their central place in your network, have potential to become one huge point of failure.
One of the most urgent reasons why point-to-point integration should be avoided is that the resulting architecture wreaks havoc on reliability.
A reliable system should be as simple as possible - the number of connectors required to pull off large scale point-to-point integration makes these architectures hopelessly complex.
A reliable system should be well-documented, to speed up response time for unpredicted problems. As point-to-point architectures grow, this becomes increasingly difficult.
A reliable system should be redundant - point-to-point integration distributes the weight of the integration responsibility, but does so without re-using components. This makes eliminating bottlenecks and shoring up problem areas difficult.
Reason 3: No Course Of Action For Emergencies
The large number of single-purpose, tightly coupled connectors can ruin your best efforts to shore up your architecture. Clustering can alleviate load problems, but what about security issues?
If a critical security patch causes one of your systems to become incompatible with your connector model, your entire network will be down until the five or six connectors that link this part of your infrastructure to the other components are fixed. Once you consider that "fixed" isn't a single step, but a process of re-factoring, developing, testing, and deploying - the scale of the problem becomes clear.
Reason 4: Loss of Agility
Point-to-point integration architecture forms "tightly coupled" connections between components. In order to replace an infrastructure component, every connector must be re-factored to work with the new system. Any new components must be linked to every other system in the infrastructure using new tightly coupled connections.
This design results in a loss of agility, in the IT sphere and for the organization as a whole. Breaking up legacy stacks into services becomes an unapproachable task due to the number of connections involved. Integrating with partner systems takes years instead of months, and may not be done at all. Business units make do with blunt software tools due to the complexity of integrating and creating more specified applications, resulting in lack of productivity.
Summing It Up
If your infrastructure uses 3 systems or less, and you're not expecting any growth in the future, point-to-point integration is an adequate solution. However, if you're expecting any kind of expansion in the future, or are already experiencing integration problems, you should make improving your integration architecture one of your top priorities.
Mule ESB - An Integration Platform That Just Works
When you're caught up in the pain of point-to-point integration, breaking free can seem like a task that's too large for any team. If you feel like you'll never see the end of your integration problems, you're going to love Mule ESB.
Mule ESB is built from the ground up to make real-world integration problems disappear. It has support for more standards, formats, and protocols than any other open source ESB, and an intuitive modular structure that eliminates hazy ROI timelines and makes incremental migration to modern integration architecture a reality.
An integration framework is only as good as its performance in real world integration scenarios. Fortunately, the real world is where Mule ESB performs best. To help you get an idea of how Mule ESB can help you get rid of your integration headaches, check out the two use cases below.
Mule ESB Use Cases
AllConnect and Nespresso - two different companies with two completely different sets of integration needs, both found that Mule ESB is the best way to do integration. Read their stories below.
Founded in 1998 to help people during their moves, AllConnect establishes a number of residential services for consumers, including power, telephone, cable & satellite television, DSL and home security all at no cost to consumers. The company partners with more than 30 power companies and hundreds of service providers across the U.S. and employs over 500 associates.
AllConnect was suffering from a variety of complex integration problems - point-to-point spaghetti, legacy systems, and a growing number of partners.
The Mule ESB Solution
Using Mule ESB, AllConnect was able to:
- eliminate all point-to-point connections
- expose existing system functionalities as services, and organize them into an efficient, unified, standards-based architecture
- practice agile business tactics, quickly rolling out new partner offerings and pricing structures into their ordering system
- plan a non-destructive incremental migration path from their legacy stack to lightweight service-oriented architecture
Want to know more about the future of Mule ESB?
The Mule development team has released new Development features to the platform, including: