Interface Design and Integration Architecture contains the decision, whether and/or which integration technology shall be used. Sometimes integration experts are challenged by an interface requestor (business or IT, but mainly by software developers), why putting an integration component (middleware) between two applications, if they speak the same language and protocol.
If mediation is required (mapping/transformation, routing, i.e. publish&subscribe, protocol switch, orchestration, queuing), the use of an integration component is obvious, but how to handle the fact when both applications speak the same language and protocol (or one is willing to speak the others message format)?
There are the typical arguments against putting a middleware in between, especially when it comes to synchronous interfaces (besides the fact that synchronous integration is not loosely coupled and creates technical and lifecylce related dependencies):
- Another Point-Of-Failure
- A middleware is slowing down the interface
- I have to coordinate with another team (the integration people of my company)
The Cons are not so massive in reality.
- The up-time of a middleware component is extremely high, as it is anyway managing your integration traffic all the time. Cloud components promise to be available at around 99,8%…
- You have to choose the location of your middleware wisely. Of course you should pick a middleware component deployed On-Premise if you connect two On-Premise applications. The delay is typically around 200 milliseconds for pass-through scenarios placed at the correct location.
- Aligning with another team might slow you down, but remember: “If you want to go fast, go alone. If you want to far, go together.”
Now that we have limited the Cons a bit, lets have a look at the Pros of Pass-Through:
- Transparency: Knowing which applications are connected at a central place. A long-term perspective for constant transformation and ongoing change management.
- Control (Monitoring): Realizing where things break or don’t work well
The larger an interface landscape is, the more obvious are the arguments above. A person who oversees only 5-10 interfaces has a different understanding of integration who is responsible for 50, 500 or 2000 interfaces.
The smartest way to support
- synchronous pass-through interfaces is via API proxies (e.g. SAP API Management – basically only the host might change as a minimum, but you can add additional policies to influence/secure the integration),
- asynchronous pass-though interfaces is via an ESB (e.g. SAP Cloud Integration) or through a broker (e.g. SAP Event Mesh). Both support loose coupling and queuing to buffer the messages if required.
