Hybrid Integration Architecture and Patterns

Last week I was asked what my recommendation is for designing solutions using a Hybrid Integration Architecture.

I thought to give a brief explanation on this topic and share my recommendations for applying patterns with you.

A Hybrid Integration Architecture consists an on-premise Integration platform and cloud Integration platform (iPaaS) which are connected via open HTTP based protocols.

The architecture enables business applications to be integrated in On-premise to On-premise, Cloud to Cloud and specifically On-premise to Cloud Integration scenarios.

The advantages of an A Hybrid Integration Architecture apply to On-premise to Cloud Integration scenarios

  • Connectivity between on-premise Integration platform and cloud Integration platform needs to be established only once and is then reused. This eliminates the need for network configuration (firewalls) and improves security.
  • The capabilities of both Integration platforms can be fully utilized and complement each other. Consider that the cloud Integration platform processes data stateless and pushes messages onto a queue provisioned by the on-premise (ESB) Integration platform.

This does not mean that for each On-premise to Cloud scenario both Integration platforms are used, it may make sense to use just the one, the other or even none. Much depends on the solution requirements.

For example, in a scenario where payment orders are submitted by a On-premise application to a Cloud banking service, the use of HIA seems to be a logical choice. For security reasons however it makes more sense to shorten the Integration chain to avoid injection malicious payment orders. In this case a direct connection from on-premise application to the Cloud banking service is preferred.

As to the questions what my recommendation is for designing solutions using a Hybrid Integration Architecture:

I recommend to define a set of solution patterns which make use of the Hybrid Integration Architecture and address Integration scenarios common to your system landscape. Patterns provide similar solutions to common requirements and lower the TCO.

In addition I recommend to adopt a policy for pattern-based design eventhough not all requirements map to a pattern. In such cases an exception is warranted.

A solution pattern must document

  • The use case for the patterns clarifying when to apply and when not to apply the pattern
  • The solution itself, technologies or concepts, in accordance to your system landscape and strategy
  • Usage limitation for example on volume, latency or data size
  • Required resources, skills or other dependencies

When designing and documentatin patterns make enlist system SMEs to make sure the pattern implements the right solution. Also align with your IT and architecture communities for support and acceptance.

Solution patterns are not new, their success depends on tailoring them to your specific environment and applying them consistently.

Hashtag Integration can help you design solution patterns that fit your organization.

No Comments

Post A Comment