Sunday, March 25, 2007

Matrixed Multi-Tenancy and the Future of SAAS

SAAS buyers need to ensure the solution they are buying is built to match the purpose they have in mind, and the launch time-frame of the project.

We can say this from experience. Layering in an automated software distribution business on top of a millions of end points connected via a massive service provider infrastructure is the main thing we do. Since our first deployment of Authentium ESP almost five years ago, we've become very good at doing this.

One of the core reasons why? "Matrixed multi-tenancy".

As you probably already know, the main difference between "single-tenant" SAAS systems and "multi-tenant" SAAS systems lies in the design of the database.

Single-tenant systems have historically been designed to handle a single tenant, or customer. Single-tenant architectures usually take the form of a single, isolated database inside a single network, designed to serve up a single shared application set to a single, non-tiered distributed base.

Multi-tenant databases are typically far more complex, and are usually designed to serve multiple application and feature sets to multiple types of customers. Multi-tenant systems feature databases designed to handle multiple distributors and tiering relationships, multiple customer types, multiple application types, multiple brand-customer relationships, etc.

Why "matrixed? Because supporting multiple ISV application and feature offerings is complex and requires linkage between databases, in order to support complex policy settings, and tiered reporting, including end user status reports, and reseller commission and ISV royalty reports. A layered support infrastructure designed to handle all of the matrixed inbound and outbound relationships is necessary to enable global reporting, and support commerce.

Speaking on a purely practical level, one of the main things we've learned from our installs is that if your SAAS solution is going to scale, it needs to support not only end point application and feature modularity, but "distribution modularity" as well.

Most of the clients that we work with have to manage multiple distribution channels, support networks, ISVs, and brands, in addition to multiple physical networks. You just can't do this with a single-tenant data model - or even with a web-centric "multi-tenant-lite" model.

The single-tenant approach quickly falls down when sub-distributors need to be added, or applications/features withheld from subsets of the population, or prices adjusted by geography - or when new sub-systems need to instantly come online, as the result of a merger or acquisition.

In addition, single-tenancy systems are usually expensive to set up, highly inflexible when it comes to sub-distributions of application bundles or branded offerings, and usually don't scale well beyond the original brand that created them, or network that purchased them.

Matrixed multi-tenant systems, such as those we've built for ESP 4.0 (Elements) and ESP Enterprise, are highly-flexible by comparison, and are increasingly much more cost-efficient than their single-tenant predecessors.

By enabling true multi-tiering of offerings, including different application bundles, support offerings, and brands, matrixed multi-tenancy offers real and sometimes significant cost and time-to-market savings.

Historically, the argument against multi-tenant systems has always been expense-related, because, with the possible exception of hosting companies, no one has ever built these databases into a shippable product, or "service".

However, with the arrival of Elements and ESP Enterprise, the expense argument is now moot. Because of the cost-savings enabled through hosting multiple populations, it is possible for us to ship our ESP solutions for less price than the less-flexible single-tenant providers.

Right now, ESP is the only matrixed multi-tenant system of its class that supports automated, tiered distribution of complex end point applications by backbone service providers to multiple sub-distributors, such as regional or local ISPs.

I don't expect us to hold this high ground forever. As true multi-tenancy becomes cheaper, and more premium SAAS applications come onto the market; as CIOs and network administrators start developing a taste for productivity-based end point widgets; as more and more telco and cable companies merge their networks - all SAAS networks, enterprise and consumer, will inevitably move to matrixed, multi-tenant architectures.

No comments: