Implement an ESB (Enterprise Services Bus) solution as a pillar of your IS

The Enterprise Service Bus: the heart to orchestrate, simplify and accelerate exchanges between your software and systems. Transform your IS into an integrated and responsive ecosystem. Unleash the synergy of your applications!

This Enterprise Service Bus content is part of our file on Interoperability and data flows.

Inter-application communication at the heart of ESB approaches

The ESB (Enterprise Service Bus) is a technological solution, also known as a middleware tool, which facilitates interaction between applications and the circulation of information within an ecosystem: within your own information system, of course, but also with those of suppliers, partners, customers…

This application bus acts as an integration column through which applications interact without constraints of format or temporality. Its role is to mediate and communicate between applications, databases, Excel files, etc. It is therefore the main tool for putting into practice urbanization principles such as Service-Oriented Architecture (SOA)!

Beyond its perception as a middleware and therefore back-office tool, the Enterprise Services Bus helps to provide solutions to business uses. Here are a few pragmatic examples:

  • Integration of the GRU (User Relationship Management) portal with the rest of the Information System
  • Recovering and sending data between the electronic initialing device, the EDM and the digital safe
  • Feeding of hardware repository in local authorities
  • Orchestration of internal services to facilitate data exposure through an API Management approach
  • Transversal entry/exit process for new agents
  • Implement new human resources management indicators, by feeding your warehouse from different sources
  • Link between HRIS and Finance IS
  • Agilization of IS in an SAP environment
  • Dematerialization of a financial flow
  • Preparing for structural IS changes (ERP migration, etc.)

The Enterprise Service Bus is often represented as a central channel or application bus, which connects to the various applications and software in the information system. While this representation is fairly conventional, it does have the merit of making the concept clear!

To be more precise, it's the notion of "services" - a service is an autonomous unit of software functionality(ies) - that lies at the heart of the ESB concept, as espoused in the Service-Oriented Architecture (SOA) models. The Information System's applications will propose their "services" to the ESB, which will publish them in its registry to make them available to all applications, who can subscribe to them. Applications are thus both suppliers and consumers of services.

The second key principle is the standardization of the exchange structure through a pivot format: target applications don't need to speak the same language as the source application, or to know their technical format, the codification.

iPaaS and ESB have the same objective: the integration of enterprise systems and software. From our point of view, and to put it simply, iPaaS :

  • 75% is a cloud-based ESB solution, with all the advantages that brings: scalability, horizontal scalability...
  • At 25%, it offers specific benefits, with the ability to deport processing execution as close as possible to the elements, and to reason in different computing zones, while ensuring consolidated supervision. Multi-tenant architecture is another. So it's more than just a hosted ESB!

Benefits: the circulation of information as the foundation of a more efficient IS serving the business lines

Of course, the implementation of an Enterprise Services Bus should not be seen solely in terms of information transmission and flow. They must aim to facilitate the exploitation of data according to the company’s business and strategic needs, and enable IS rationalization through :

ic-idee-1.svg

Information system interoperability and greater independence from applications

ic-idee-2-1.svg

Simplified integration of new processes and applications (or their decommissioning)

ic-idee-3-1.svg

Information system agility by limiting technical constraints

ic-idee-4-1.svg

Lower TCO (Total Cost of Ownership)

How to frame, deploy and extract maximum value from your ESB solution?

These projects are an opportunity to unite business and IT departments around common objectives! Including stakeholders in the early stages of a project encourages adoption and maximizes the final value. The convergence of different viewpoints takes place around the circulation of information within the organization. Its modeling reveals the role of human stakeholders and enables everyone to agree on a common vision of the who, what, how, when… It’s all about :

  • Become aware of the processes and data in transit, what can be exchanged, modeled, urbanized, their criticality…
  • Only then can we put in place an IT architecture that enables us to implement flows and cleanse data.
1st recommendation

Setting the scene for your ESB project

We advise you to study and take a step back on certain aspects in order to better frame your project and define your expectations according to the context of your organization:

  • Service granularity. We need to find the right balance between being too atomized and too grouped. The service must be easily reusable, while not requiring systematic reconstruction of service sequences.
  • Real time. By default, it’s better to anticipate real time: even if it’s not necessary now, it may become so in the future. However, there’s no need to force applications that can’t handle it!
  • Supervision. All cross-functional services must be standardized and supervised. Any error must be identified, with its context, immediately.
  • Know your flows. In-depth, shared mapping is the best way to ensure that no step is overlooked, and to identify all value drivers.
  • Anticipation. The aim of IS urbanization is to reinforce your agility. You need to be able to easily modify the sources and targets of flows without any specific development.
2nd recommendation

What studies should be carried out in advance of the project?

Here is a non-exhaustive list of studies to be carried out upstream:

  • Flow mapping from an organizational and business point of view, and if necessary, questioning the existing system!
  • Mapping of the application base, in order to share a global vision of the information system.
  • For each flow, indicators of volume, criticality of exchanges, frequency, and the need or otherwise for real time.
  • A glossary for all those involved in the project, so as to share the same vocabulary.
3rd recommendation

Key criteria and functions to include in your specifications

Here are a few essential criteria to include in your list of requirements:

  • Mediation and intelligent routing: dispatching the right data to the right place
  • Transformation: messages are converted into a standard format
  • Retention and persistence: distribution can be synchronous or asynchronous if the target application is unavailable, without blocking routing to other applications
  • Convergence: multiple sources can go to the same place
    Supervision: a consolidated view of flows and their progress
  • Enrichment: ability to enrich messages through intermediate distribution channels MDM (Data Repository)

In addition, requirements matrices within the specifications of data integration platforms generally take at least these categories into account: Connectivity, Exchange protocol and triggers, Transformation, Mediation and routing, Supervision and monitoring, Security, Openness and exposure of services, Ergonomics and main principles, Hosting, Technical platform, Architecture, Pricing model, Planning & Project.

The distinction between ESB and ETL has become irrelevant in the context of modern business requirements.
ESB vs ETL

Choose our Data Foundation Module to support your Enterprise Services Bus and urbanization strategy!

The Data Foundation module of our Phoenix platform is an ESB solution (named Viaduc in our Blueway Public Sector range) enabling the implementation of SOA (Service-Oriented Architecture) best practices. In fact, it’s because we’re convinced of the fundamental role of data processing, transport, manipulation and control that we’ve named this foundation “Data Foundation”! This foundation integrates all the functionalities mentioned above, and also provides you with assets to accelerate your projects and reinforce your autonomy.

Our strengths in implementing your urbanization strategy

Low-code and intuitive

Data Foundation lets you handle all your inter-application services "at the click of a mouse", within a dedicated graphical interface. What's more, our solution is accessible in thin-client mode, so everything can be done through a browser.

Supervision console

You have all your monitoring elements in one place. No need to navigate between different interfaces to diagnose a problem and implement the associated treatments.

Industrialization tools

You have greater control over multiple environments. Connection chains adapt to the environment: your teams can develop directly in the platform and deploy it in production at the touch of a button. Modifications, changes to production... are of course traceable.

Context library and pre-configuration

You can speed up project start-up by capitalizing on a library of sample technical and functional processes and reference frameworks.

ESB and ETL complement each other

You've provided an overall response to the issue of data circulation within the IS. In our opinion, it's up to the tools to converge and adapt to the business, not the other way around!

Data Platform Phoenix : DQM, MDM, BPM, ESB, Data Catalog

… and beyond, take advantage of the complementarity of ESB, BPM, MDM, APIM and Data Catalogue with the Phoenix platform.

At Blueway, we’re convinced that every business need requires a global, shared vision of processes and data, and therefore of the different dimensions of data governance.

That’s why we’ve built our Phoenix Data Platform around bringing together the uses of BPM, MDM, ESB, API Management and data mapping, around your business and human challenges.

Would you like to discuss your interoperability and urbanization issues?

Book a meeting now!

Our Enterprise Service Bus speeches

Our FAQ about the Enterprise Services Bus

The two approaches, ESB and APIM, are complementary: ESB positions itself as the orchestrator of your Information System's services, while APIM focuses on the governance of exchanges with the outside world (controlling access to and use of APIs, monitoring usage, standardizing APIs to ensure scalability, etc.).

The scope of ETL (Extract-transform-load) and ESB partially overlap.

Historically, ETL has been considered capable of handling very large volumes of data, for a limited number of exchanges, while ESB is better suited to managing high-frequency exchanges, but with smaller volumes of data.

Our conviction is that this ESB vs. ETL compartmentalization is no longer relevant today: the technical solution must adapt to business challenges and move beyond these conceptual visions.

These two notions are not at the same level: ESB is an integration tool, whereas microservices are small service components that can be combined to create an application. Microservice architectures are thus made up of lots of specialized services used to build application functionalities. These architectures enable more agile development and the easy addition of new functionalities. The granularity is finer, but also generates greater complexity.