Since Massimo Pezzini and colleagues at Gartner coined the term “Hybrid Integration Platform” (HIP) in 2013 [Gartner’s paywall], giving a catchy name to an evolving integration platform architecture that included both on-premise and cloud components*, the approach has become pretty much a de-facto standard for large organisations implementing integration capability. Indeed, most middleware vendors now have, or at least claim to have, capabilities that bridge on-premise and cloud environments.

The idea has now become so pervasive that it almost seems like a no-brainer to recommend an organisation implement a HIP this as part of their intgration strategy. However, sometimes, it might not be the right solution.

What is a HIP? In this article I’m using the term in its original meaning – a platform that comprises both on-premise and cloud components, working together. I think it’s fair to say that over time, the term has expanded represent a platform that supports all deployment modes, all forms of integration, and all usage scenarios.

I’ve been working with a client recently that has decided to move aggressively into the cloud. They have an on-premise footprint in the form of a large, in-house-developed monolithic legacy system, which pretty much runs their current operation, but the IT Director has mandated that all new software will be cloud-based.

Wheeve have been supporting this strategy by designing the to-be integration platform to support this future architecture and the thing that’s been vexing me most at the early stages has been whether to adopt a HIP architecture, or simply to use cloud-based iPaaS.

Initial thinking was that we’d need to go for a HIP – after all, a significant proportion of the client’s landscape was on-premise. However, on closer consideration, we have decided that’s probably not necessary.

The key thing to note in this instance is that we don’t foresee there being any new integration requirements between on-premise systems. All new integration requirements will either be cloud-to-cloud, or cloud-to-ground. Therefore no need for on-premise infrastructure.

I think there’s a fundamental, underlying force at work here: it’s where the centre of gravity of the systems landscape is shifting. In this instance, it’s moving very decisively to the cloud, and that’s not unusual – most organisations are. That means diminshing needs for any on-premise integration over time. Granted, there might be some now but there’s no reason why they can’t be handled in another way, even if it is via less elegant means.

This may seem like a bold proposal, but in this scenario I can’t really see any strong benefits for implementing on-premise infrastructure. And avoiding an on-premise implementation significantly simplifies the plan, speeds up the implementation and minimises cost.

There are some technical challenges to consider along the way, and there’s always a possibility that due to latency issues we may have to consider something on-prem, but we could always add that later, so I’m happy with this decision. If we need to change tack, adding on-premise components as necessary, we can do so; the vendor we’ve chosen has capability we can use, but at the moment we think we’ll be fine without.

If that changes, I’ll update this article to explain the change in direction and why. Watch this space!