Multi-Tenant Integration – Busting the Myth of “Hosted” versus SaaS

I’ve noticed a trend recently of conventional integration vendors offering a “hosted” alternative to their on prem products and appliances. Unfortunately, those offerings are then marketed as “SaaS” or “on demand” simply because they are hosted “in the cloud.” To be clear, that is an ASP model – a model that did not fare so well. Just because something is hosted does not make it SaaS. (Nor does leasing or offering monthly payments make it SaaS either.)

So what’s the difference and what’s the big deal? The chief characteristic of SaaS that separates it from the old ASP model is multi-tenancy. Multi-tenancy simply means there is only one copy of an application deployed in the cloud (single instance) but that all customers can use that copy (multi-tenant) and even customize it to meet their unique requirements. Multi-tenancy is what makes all the great values of SaaS, such as rapid time to value, faster innovation cycles and ultra-low cost structure, possible.

It is particularly important in the world of integration because integration is such a fundamental building block for the SaaS community. Think of any common infrastructure system such as electricity as an analogy. It only makes sense to build common infrastructure systems once to the benefit of the entire community.

In his book “The Big Switch,” Nicholas Carr describes how one hundred years ago, companies stopped generating their own power with “dynamos” and plugged into a growing national power grid of electricity. Looking back today, the benefits are obvious: dramatically lower cost, greatly reduced maintenance, and ubiquitous distribution. It also made the process of upgrading technology much easier as changes made to the common grid were immediately available to the benefit of all users. But most importantly it addressed the scalability issue that was created by the limited reach of isolated dynamos and in the process unleashed the full potential of the industrial revolution.

We are in the midst of a similar revolution today with the advent of SaaS and cloud computing and integration has become the modern-day version of electrical power – call it digital electricity. Conventional integration products and appliances are single tenant – they were designed and built to support individual enterprises much like the electrical “dynamos” of yesteryear. In the single-tenant model, the burden and cost of building, implementing, and maintaining integration is shifted to the end customer. Every business must generate its own digital electricity at great expense. And attempting to grow the multi-tenant SaaS ecosystem with single-tenant integration products will result in sky-rocketing maintenance costs and greatly limited adaptability and scalability.

When we built Boomi On Demand, we recognized that the industry needed a “universal power grid” to unleash the full potential of the SaaS revolution. We built the Boomi platform from the ground up as a true, single-instance multi-tenant SaaS platform. It was designed and built to natively handle the complexity of multi-tenant SaaS applications. ISVs and end customers alike can now plug directly into Boomi’s “power grid” and have instant access to integrate with the industry’s largest network of interconnected SaaS, Paas, on-premise and cloud compute environments.

This is not a perfect analogy but I think it makes the point. Multi-tenant platforms such as Boomi unite and power the growth of the SaaS ecosystem. Single-tenant integration products simply weren’t designed with SaaS in mind – they were built for conventional on-premise implementations.

So yes, multi-tenancy does matter. We have the opportunity as we build out the SaaS ecosystem to avoid the integration mistakes that plagued the enterprise era. Adopting a common, multi-tenant architecture for integration is imperative to support rapid growth and expansion.

Comments

[Rick Smith]

I am confused on one topic above - you say that your platform is truly multi-tenant. But when I checked out your product, I saw that there was something called an "atom" that I needed to download for on premise integration. Are you saying that this "atom" is multi-tenant? If so, it doesn't make sense to me as this piece of software that is needed is sitting within my firewall and is "isolated" for my use.

if the "atom" is on premise, then I guess you make the point of the design experience being on-demand. This is not an important criteria for SaaS; even salesforce.com's Force.com platform - the leading platform as a service offering - provides an eclipse plug in for their developers. It is important for the run-time experience to be truly on-demand as a service, not the design experience.

[Bob Moul]

Thanks for the comment Rick and we appreciate your taking the time to read the blog. You are correct that Atoms deployed on premise are single-tenant. As they process only one customer’s data, there is no need for them to be multi-tenant. However, Atoms deployed in the cloud are in fact multi-tenant and can support processing of multiple customer’s data.

The multi-tenant aspects of Boomi’s platform go beyond just the design experience. The entire platform is multi-tenant which includes not just design/build but also deployment and on-going monitoring and management. As such we can deliver the great benefits of SaaS such as lowest cost structure, fastest time to value, fastest innovation cycles and massive scalability in the integration context. Beyond that, being SaaS allows us to deliver capabilities like instant sharing of new connectors and maps for design/build, deployment of multi-tenant integration processes (built once - deployed many) and the ability for ISVs to monitor and manage all their customer’s integration processes, wherever they are deployed, from one platform.

Another great example is API maintenance. When a change is made to an API, that change can be made one time in Boomi (through our multi-tenant designer), and each tenant who needs that change gets it instantly. Imagine by contrast using a conventional integration product installed at each site, or even hosted in the data center. Each instance of that stack would need to be updated when the same API change occurs.

Hopefully this helps to illustrate the benefits of the entire integration life-cycle experience being multi-tenant as opposed to just the run time. Let me know if you have any other questions and/or check out our free 30-day trial on our website.