Two Dimensions of Enterprise Integration

In a complex enterprise such as a bank, two topologies (bus and hub-and-spoke) often need to be simultaneously deployed in order to achieve Enterprise Integration.

If applications are integrated in a point-to-point manner, the number of interfaces and the associated complexity grows rapidly with growth in applications (approaching n-squared, where n is the number of applications). Another implication of point-to-point connectivity is the tight coupling between applications. When a new application is introduced, other applications have to be aware of the precise data format expected, the integration style, the protocol used, etc. Integration styles can range from service calls (which may be RESTful web services, SOAP web services, CORBA or RMI calls etc.), to message-based integration (e.g. MQ), file-based integration or even using a shared-database for integration. Such tight coupling strangles flexibility, or the ability of the enterprise to iterate.

Bus topology, in the form of an Enterprise Service Bus is typically used solve these problems and to decouple interfacing applications. 

Using a bus, interfacing applications are shielded from the protocols, message formats,  physical endpoints etc. used by their peers. Additionally, the bus can be used to publish messages to multiple subscribers, and even to implement an Event-Driven Architecture if so desired.

However, this level of decoupling is not sufficient. If an application needs to provide data (say transactions or portfolio positions or customer data etc.) to 40 other applications, generally it still needs to extract the data independently for all 40 applications and feed it over the bus. This is because of variation in the needs of the 40 applications (such as expecting incremental data vs. a full set, end-of-day vs. near-real-time, reconciled/clean data or raw, etc.).

To solve this problem, Hub-and-Spoke topology in the form of a Data Hub is typically created. 

This might be called an Operational Data Store (ODS) and contains commonly used data which is replicated from source systems to the Data Hub. Applications form the spokes and obtain common data from the hub. With a Data Hub, the next level of decoupling occurs. Data consumers do not need data producers to be available at the precise moment they need the data, so availability of applications goes up. Applications are shielded from the volume of data requests, and can focus on executing business functions without impact to performance. Apart from scalability, another advantage of the Hub is that data consolidation and data enrichment/correction can occur in the hub.

Apart from a Data Hub, a Service Hub is often created to house common services that access data in the Data Hub and/or invoke other applications to fulfill requests (including Service Orchestration). The services in the Service Hub can be used to implement common semantics across the enterprise.

The Data/Service Hub has be overlaid on the bus i.e., the Data/Service Hub itself has to be interfaced to the bus.