Three Keys to Making Multi-tenancy Work

Not all multi-tenant applications are alike. Their cost and value are heavily dependent on these three architectural and design considerations.

There is still some debate over whether multi-tenancy is a prerequisite for cloud computing, but doubters are getting harder to find. Nearly two years ago (an eternity in Internet time), David Linthicum, blogging in InfoWorld, called the dispute “silly.”  “Let’s get this straight right now,” he wrote, “Cloud computing is about sharing resources, and you can’t share resources without multi-tenancy.”

Even so, there are differences of opinion about what makes a good multi-tenant application strategy. First, to be clear on what multi-tenancy is, Wikipedia defines it as “a principle in software architecture wherein a single instance of the software runs on a server and serves multiple client organizations (tenants).” In contrast, a single-tenant cloud app, even it if runs on a virtual server partition, is almost identical to the old hosted ASP model, which dates back to the 1990s. And by now it’s abundantly clear that the multi-tenancy can lower a customer’s costs and offer significantly more value over time. (See Alok Misra in InformationWeek).

But not all multi-tenant applications are alike. Their cost and value—especially value—are heavily dependent on architectural and design considerations. The multi-tenant experience is often likened to leasing an apartment or condo versus owning a home. As anyone who has ever spent any time renting knows, the quality of the experience often depends on your landlord. In situations wherein our software is being used by a multi-tenant-application “landlord,” Kinetic Data has always tried to leverage best practices in the multi-tenant environment. To us, these boil down to three key considerations:

Be flexible, not monolithic.

Since all tenants in a multi-tenant environment share the same application, it may seem logical that the application must be the same for all tenants. If you accept that notion, you have to conclude that while a multi-tenant application may provide some broad value to all customers, its monolithic nature limits the unique value it can provide to customers with unique needs.

Kinetic Data set out to disprove that notion years ago, at least in the BMC Remedy® IT service management world. We acknowledged that at the application-run-time engine and application-data tiers, the same instance of BMC Remedy has to serve all customers in the same ways. This is the essence of multi-tenancy, and there’s no way around it.

But there are other tiers atop those two basics tiers, and each can be configured to provide unique service experiences. The trick is utilizing what we call cloning or templating, using metadata in the outward-facing applications customers actually use (in our case, Kinetic Request and Kinetic Task). In the Kinetic world, there is a clear separation between the compiled BMC Remedy run-time engine/application data and the metadata-based templates customers use to create unique branding, workflow processes, portals, and forms. In this way, each Kinetic Data customer can change the templates they use without affecting other tenants. This “isolation of processes” thus allows the creation of unique customer applications that are easily configured and deployed without sacrificing the security and integrity of the underlying application.

Security must be architected in, not added on.

In the early days of multi-tenant cloud computing, there was a lot of concern about data security. After all, multiple independent tenants share the same application, each with their own data sensitivity and security requirements. How do multi-tenant application providers ensure that each tenant’s data is kept separate and secure?

In Kinetic Data’s case, we use the “row-level” security model already built into BMC Remedy. This model ensures that row-level records are locked to a specific company ID. As a result, the ability to query, view, and modify records is restricted to users with company (or companies) privileges that allow access to those records.

Employ multiple implementation models.

Customizability, unique value and ironclad data security—those are the pillars upon which Kinetic Request and Kinetic Task are built. But we also took another need into consideration. In the ideal multi-tenant world, companies may want to use applications on a strictly company-specific basis or share certain services among vendors, campuses, clients, partners, and others, or maintain the ability to do both. That’s why the Kinetic Data architecture is based on these three specific implementation models.

In the Kinetic Data company-specific model, companies can configure uniquely branded catalogs, portals and service items without affecting the branding or processing of any other company in the same BMC Remedy instance. In the shared Kinetic Data model, companies can share these items while maintaining the row-level security of the BMC Remedy environment. And in the blended Kinetic Data model, companies can share items while maintaining company-specific service items.

So what makes multi-tenancy work? In Kinetic Data’s case, it works thanks to:

• Customizable user interfaces for each tenant and the ability to configure unique tenant processes without global effects, via isolation of processes;
• A flexible deployment model (or unique or shared services or a combination thereof); and
• Data integrity and segmentation.

Looking to get in contact? Connect with us here.