If your integrations involve more complexity than simply passing messages between systems (e.g. you want the ability to gain insights on inter-system traffic, you need to add security or validation into the workflow, or you need to translate between incompatible technologies) having a central solution capable of such abilities will avoid having to write new mini-systems for each scenario.
By placing an ESB between two systems you have a third system (the ESB itself) to manage. This includes provisioning resources, monitoring availability & performance, and another team (or at least consideration) in the mix when discussing integration between the two systems.
As more systems are added, each with 1:1 integrations with other systems, a lot of existing solutions need to be recreated for the new systems, the ability to view and/or understand all of the integrations becomes more difficult, and the complexity around transactions becomes more complex.
Whilst the underlying application may not support all modern communication technologies (e.g. REST), the service layer can provide this ability, using an alternative compatible technology to subsequently communicate with the underlying application.
By hosting the service layer as its own system, integrations using the API are no longer tightly coupled to the underlying systems, allowing you to swap applications whilst maintaining a consistent service layer over the old and new system.
Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to Safari