The Story of EAI/ESB

Strengthen your enterprise data integration net

In order to keep track of growing market demands and the ever-changing business environment, today’s enterprises, especially those running operations internationally, are highly dependent on Information and Communication Technology systems.

ICT systems are usually defined as the IT infrastructure which still traditionally consists of hardware and software – but with the appearance of terms like Cloud, SaaS, IaaS, enterprise services and SOA, things have suddenly become noticeably different and more complex.

Seems puzzling. Who and why would want this additional complexity?

Complexity comes from diversity. Lots of companies still run their business on old but reliable IT technologies. They also use one or more custom developed software modules based on them. Later, new technologies have been deployed. Some of them on premises, some on the cloud. Just like mobile apps, external AI services, event sourcing and data stream processing systems, as well as others. These systems generate or consume a vast range of data in all kinds of standard or proprietary formats. Over time, inevitably the need arises for data exchange between these systems.

IT management is a line of business which must be tightly aligned with core business needs and demands in order to be successful. For them to be sustainable on a long-term basis and to achieve profit, core business activities must on all levels make the effort to establish cost-effective practices, strengthen customer relations, effectively manage risks, and accomplish business process elasticity in order to be resilient to dynamic and sometimes very sudden market environment changes. The same goes for IT management in order to provide satisfactory IT support by building and maintaining a stable but flexible IT backbone that allows for growth, scaling, and change.

To achieve this goal, EAI/ESB is one of the key concepts that needs to be deployed.

It can be used in all industries and business domains – but to gain a broader picture, here is one widely known case.

A Well-Known Retail Scenario

Imagine a retail company which has hundreds, maybe even thousands of shops, storage units, suppliers, delivery vehicles and logistic partners all over the world. They also have their own, as well as many partnering webshops.

Which operations should be supported by information technologies?

• The logistics module should cover the supply chain, transport and delivery, customs, warehousing, and stock management.
• The point of sale module should cover customer payments and receipt issuing, store inventory management, taxation, sales reports, and shop staff information.
• The webshop works in a similar way to the point of sale module, but there is need for additional features like a virtual shopping cart, online payment, automatic notifications for customers, items availability status, transaction and delivery tracking and keeping track of customers’ purchase history.
• The retail back office module should provide central management, monitoring and reporting of all POS systems for one or more shops.
• The ERP system usually covers accounting, accounts payable, accounts receivable, inventory and asset accounting, payroll and human resources for the whole company.

The five modules and systems listed above can be built as a single monolith information system or each of them can be separate, based on the different technology, developed by different IT companies, and finally, customized and maintained by several others.

As we can see, there are a lot of modules or applications which, in order to be functional and to maximize the anticipated ROI, have to exchange information in all directions among each other and also with external systems.

What happens when a customer approaches the counter with a request for information about an item which is currently unavailable in the shop?

In such a case, the retail information system should provide answers for the customer to the following questions:

Is the requested item available in the local warehouse?

Is the requested item available in some other shop nearby?

Is the requested item available online?

When is it expected that the item will be available?

The customer might want to pay up front and reserve the item, and then later be automatically informed when the item arrives at the shop, and finally ask for home delivery.

In such a case, which modules should be used and consulted by the POS system?

• Logistics – to obtain information about the item’s availability on the warehouse, and if the item isn’t available, when it is expected to be available, and to schedule delivery.
• Point of sale back office – to obtain information about the item’s availability at other local stores and automatically inform the customer when the item arrives.
• Webshop – to obtain information about items available online.

If the information system isn’t monolithic – which is a rare case – we have to connect these three modules either directly or indirectly.

A direct connection means that all the mentioned applications have developed outbound interfaces specialized for the particular requests. The application interfaces should be able to provide information for many applications, and the exchanged data should be ‘understandable’ by all of them.

Are we expected to program the same interface over and over again every time when a new need for data exchange emerges in a new process/application? Such an approach leads to a technical and organizational mess which is endless, usually impossible to manage and enormously costly.

Indirect data exchange means that there is a technical system in the middle – usually called middleware – which knows how to communicate with all exposed application interfaces, but these interfaces don’t need to be aware of and ‘understand’ each other, hence they can be developed only once. 

Conclusion 

It seems that already at this point a big money-saving potential exists. But there is a lot more potential. Middleware solutions can be custom developed. Usually, but not necessarily, in such a case the solution is poorly planned, built with major architectural, technical, functional and security leaks, which together lead to a mess similar to the one mentioned above. In most cases, improvisation leads to degradation. Such a scenario can be found in any business and industry – be it in finance, logistics, health, hospitality, energy or industrial manufacturing.

The market offers a long list of candidates, divergent in features and price. Both open source and proprietary. To ease this difficult decision, it’s good to know what to expect from such a product. A solid EAI (Enterprise Application Integration), ESB (Enterprise Service Buss) system or simply Integration Solution should provide the following features:

• Connect all systems and data that reside inside and outside of the company
• Route, transform, enrich, filter, monitor, event source, and distribute data
• Support all standard protocols and data formats, with the option of custom development.
• Provide a wide range of integration templates and smart connectors for rapid connectivity to apps like Salesforce, SAP, Oracle EBS, Siebel, PeopleSoft, JD Edwards.
• Be rich with integration management tools and environments for building advanced integration scenarios not only by IT, but also by business personnel.
• Be deployable as SaaS, cloud or an on-premise software solution.
• Be thoroughly documented and well-supported by the vendor, partner network and user community.