Eliminating point-to-point integration pain with Mule ESB - use cases

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?

It can be difficult 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.

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.

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.

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.

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.

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 Anypoint Platform.

Anypoint Platform, which contains 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 Anypoint Platform performs best. To help you get an idea of how MuleSoft can help you get rid of your integration headaches, check out the two use cases below.

AllConnect

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.

The Problem

AllConnect was suffering from a variety of complex integration problems - point-to-point spaghetti, legacy systems, and a growing number of partners.

The Anypoint Platform Solution

Using Anypoint Platform, 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 Anypoint Platform and Mule as an ESB?

The Mule development team has released new Development features to the platform, including:

• Mule Enterprise Security
• High Availability
• DataWeave

Interested to learn more? Take a look at further resources about Anypoint Platform.