Let us go back to the point-to-point integration scenario and assume that we have four separate in-house systems, one for each of the four separate departments (HR, Accounts, R&D, and Sales). The operational problem the business faces is to interoperate these systems. In the point-to-point integration, we need to have independent channels of connection between each pair of systems. These channels are static, strongly typed, and without much intelligence for dynamic routing or transformation. The advantage is that it is rather easy to build the solution.

As shown in the next figure, if there are six systems (nodes) to be interconnected, we need at least thirty separate channels for both forward and reverse transport. If we add one more node to the IT portfolio, the number of channels to be defined goes up from thirty to forty two. This means, as time passes and as more and more systems and applications are added to the organization, the number of interconnections or channels to be defined between these systems rises exponentially, in the order of two.

We can generalize the number of channels (Nc) required for complete interconnection for n separate systems as:

Nc = n2 - n

This number is still manageable for small organizations with a small number of systems, but experience has shown that this is going to be a nightmare for mid-sized and large-sized organizations. It is customary for such organizations to have more than fifty or hundred systems. For complete interoperability in a hundred system scenario, we need to define around ten thousand separate channels! Leave alone the definition, how do we maintain such a huge network of interconnection?

Perhaps, every system in an organization needn't interoperate with every other system. Again, experience has shown that only half of them need to interoperate fully, thus bringing down the figure to five thousand. What this means is, we have to build five thousand adapters to define channels to interoperate for these systems. Still this number is not manageable.

In a perfect world, we can somehow build five thousand separate adapters to interconnect a hundred systems by fifty percent, and then hope to relax. But the real scenario is far from perfect. The imperfection arises out of constant innovation and evolution, and this forces change even to system interfaces. An int data type in C++ is of two bytes whereas the same int in Java is of four bytes. We have already taken care of this data impedance by building adapters. But, what if on one fine morning, the C++ application starts spitting float instead of int? The existing adapter is going to fail, and we need to rework on the adapter in this channel.

The good news is, within an organization this can be controlled and managed since we have access to both the ends of the adapter. The scenario worsens when the interface changes in a B2B scenario where systems between two separate organizations interact. As we know already, this is going to happen. So, we have to build agile interfaces.

Adding new systems is an after effect of business expansion, but there are multiple risks associated with it. First, we need to integrate new systems with the existing systems. Secondly, many a time, new systems introduce data redundancy. This is because the same data might get entered into the network through multiple interfaces. Similar is the problem of the same data duplicated at different parts of the organization. This contradicts the requirements of Straight-Through Processing (STP). STP aims to enter transactional data only once into the system. This data can flow within or outside the organization. To achieve STP, there should be mechanism for seamless data flow, also in a flexible manner.

Data redundancy can be managed if and only if there is a mechanism to consolidate data in the form of Common Information Model (CIM). For example, the NGOSS's Shared Information/Data (SID) model from Telecom Management Forum is the industry's only true standard for development and deployment of easy to integrate, flexible, easy to manage OSS/BSS components. The SID provides an information or data reference model and a common information or data vocabulary from a business and systems perspective. Not every domain or organization has access to a readymade information model similar to this.

In such a scenario, ESB can play a vital role by providing the edge of the system view by wrapping and exposing available network resources. Thus, ESB provides hooks for a "leave-and-layer" architecture which means that instead of altering existing systems to provide a standards-based services interface they are wrapped with a layer that provides the services interface.

Code and component reuse is a familiar concept amongst designers and developers. We have Gang of Four patterns to prescribe design solutions for recurring problems. But with the invention of SOA, we have what is called the Service Oriented Integration (SOI) which makes use of Enterprise Integration Patterns (EIP). SOI speaks about the best ways of integrating services so that services are not only interoperable but also reusable in the form of aggregating in multiple ways and scenarios. This means, services can be mixed and matched to adapt to multiple protocols and consumer requirements.

In code and component reuse, we try to reduce copy and paste reuse and encourage inheritance, composition, and instance pooling. A similar analogy exists in SOI where services are hosted and pooled for multiple clients through multiple transport channels. ESB does exactly this job in the best way integration world has ever seen. For example, if a financial organization provides a credit history check service, an ESB can facilitate reuse of this service by multiple business processes like a Personal Loan approval process or a Home Mortgage approval process.

Cross cutting concerns like transactions or security or even Service Level Agreement (SLA) management and monitoring are just a few of a set of features apart from business functionality that any enterprise class service ecosystem has to provide. The ESB architectures provides enough hooks to attach similar services onto the bus separate from normal business functionality. This ensures that these cross cutting functionality can be applied to all services and also enable us to manage, monitor, and control them centrally.