Eliminating Point To Point Integration Pain with Mule ESB - Use Cases

Eliminating Point-To-Point Integration Pain with Mule ESB - Use Cases

Point to point integration: a quick fix that can turn into a big headache just as fast.  When your infrastructure only has a few components, point to point integration can seem like a lightweight way of connecting everything together.  Three systems, three connections - what could be easier? Unfortunately, things don't stay that simple for long.
 
As many organizations find out the hard way, infrastructure based on point to point integration quickly becomes unmanageable, brittle, and damaging, not only to the IT budget, but to the organization's ability to meet current and changing business demands.
 
If you're still using point-to-point integration with more than three systems, or are considering expansion in the future, you can't afford to wait on researching alternatives.  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 also 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 on having integration problems.  Rather, point-to-point integration tends to build up over time due to sudden changes in business requirements, teams that are too overloaded with existing infrastructure problems to make time for better planning, or the assumption that more sustainable solutions are too expensive or unproven to warrant a closer look.
 
For these reasons, 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?  Let's look at the reasons.
 

Reason 1: Exponential Increase in Complexity

It can be hard 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.  
 
To calculate the number of custom integration connectors you'll need to maintain in order to integrate all the components of your infrastructure, you can use the formula (n(n-1))/2, where the variable 'n' represents the number of components you will be integrating.  As you can see, with only three components, you'll only need 3 connections: (3(3-1))/2 = 3.
 
However, adding just two more components changes this number to ten: (5(5-1)/2 = 10.  Full scale enterprise networks, with 10 or more components, will need 45 connections and up.  Every one of these connections represents not only development hours, but also potential hours spent on documentation and maintenance.  
 
We say 'potential' here because the reality is that 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 the potential to become one huge point of failure as a whole.  
 
One of the most urgent reasons why point-to-point integration should be avoided at all costs is that the resulting architecture breaks almost every reliability rule in the book.  
 
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 it does so without re-using components.  This makes eliminating bottlenecks and shoring up problem areas a complicated proposition.
 

Reason 3: No Course Of Action For Emergencies

The large number of single-purpose, tightly coupled connectors can turn your best efforts to shore up your architecture to mush.  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 for the count 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, re-factor, develop, test, deploy - the scale of the problem becomes clear.
 

Reason 4: Loss of Agility

Point-to-point integration architecture forms "tightly coupled" connections between components.  This means that in order to replace an infrastructure component, every connector must be re-factored to work with the new system.  Additionally, any new components must be linked to every other system in the infrastructure using new tightly coupled connections.
 
This basic mechanic translates into a general loss of agility, not only in the IT sphere, but 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 months instead of years, or 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

To sum 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 probably a good solution for your needs.  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 big for any team.  If you're feeling 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, with 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.
 
It's easy to look good on paper, but an integration framework is only as good as its performance in real world integration scenarios.  Fortunately, the real world is what Mule ESB does 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, who both found out firsthand that Mule ESB is the best way to do integration.  Read their stories 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 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
 
 

Nespresso

 
Nestlé Nespresso is the worldwide pioneer and market leader in premium portioned coffee.  Headquartered in Paudex, Switzerland with more than 1,700 employees, Nestlé Nespresso S.A. sells products in more than 50 countries directly to its customers and currently operates more than 79 prestigious boutiques in key cities around the world.
 
The Problem
 
Rapid demand-driven growth of Nespresso's online sales channels resulted in a point-to-point integration architecture that lacked scalability and was difficult to maintain.
 
The Mule ESB Solution
 
Using Mule ESB as the center of their new SOA platform, Nespresso was able to:
  • eliminate all point-to-point connections
  • quickly integrate a wide variety of modern components, including an automated voice-based telephone ordering system, inventory management systems, and automated warehouse components
  • add high availability, scalable messaging
  • prepare for future expansion