SaaS: degrees of multi-tenancy

Phil Wainewright has a good discussion on the various architectures underlying today's software-as-a-service (SaaS) products, such as Salesforce.com.

I've commented in the past regarding the superiority of a multi-tenant architecture (many customers supported on a single hosted system instance) versus the tradition single-tenant architecture (a separate hosted system instance for each customer). Salesforce.com is an example of a SaaS provider building on a multi-tenant architecture, whereas Oracle's On-Demand offering of its E-Business Suite is an example of a single-tenant architecture. The economics of the multi-tenant architecture are so much more attractive in that each new customer involves minimal marginal cost to the provider, allowing the provider to offer attractive pricing.

Except for protestations by the single-tenant providers, there is little debate about the superiority of the multi-tenant model. Wainewright, however, points out that there are in fact different flavors of the multi-tenant architecture. He lists three main variations:

• First-degree multi-tenancy (e.g. Salesforce.com). Here, "all customers are served from a single infrastructure in which every component is shared, all the way down to the tables in the database" This purist approach is often called "shared schema multi-tenancy because the database structure is defined by the schema and if everyone’s data is stored inside that structure then by definition, everyone is sharing the same schema."

• Second-degree multi-tenancy (e.g. Intacct, a financial systems SaaS provider). This approach is similar to first-degree, but it "uses replication much more broadly than Salesforce.com to distribute its shared-schema instances across large numbers of server clusters." A key advantage of this approach is that it can use low-cost hardware (e.g. Linux on Intel) rather than large Unix or Linux servers with massive databases. It also allows customers to operate on different versions of the system, based on which cluster thay reside upon, giving some flexibility on when they upgrade to newer versions.

• Lesser-degree multi-tenancy (e.g. Oracle, and others). There are many variations of this type, with the shared services primarily involving shared server infrastructure. Each customer has a separate database instance. This approach provides maximum flexibility to the customer but gives up much of the scalability and economic advantages of multi-tenancy. It appears that SAP's greenfield SaaS offering for small business, Business ByDesign, is taking this approach.

Debates about the advantages and disadvantages of the first versus second degree multi-tenancy approach are a bit too much "inside baseball" for most buyers. Selection of an architecture, in my opinion, should be driven by the requirements of the application. I can see where a high volume, small footprint, departmental application might benefit from the first-degree approach, where the economies of scale drive down the price per user, allowing the app to reach a larger number of users. I can also see where a larger, more complex application might be deployed more cost effectively, and with greater flexibility, using the second-degree approach. And applications requiring the greatest flexibility for the customer might be driven to the third category, though, as I pointed out, this approach loses much of the economic rationale of the first two.

Read Wainewright's entire post for a fuller discussion.

Update: Wainewright has a follow-up post where he refines his definitions and provides additional insights on Intacct's architecture. If SaaS platform decisions are important to you, you should read Wainewright's follow-up post.

Related posts
Workday: evidence of SaaS adoption by large firms
Cloud computing: can Microsoft turn from servers to services?
All not sweet with NetSuite
Computer Economics: The Business Case for Software as a Service
Dell acquires SaaS platform Everdream

Vendor maintenance fees: just say no

A journalist contacted me last week on the subject of vendor maintenance and support contracts. Maybe Spectator readers can help him out.

He wanted to know if I had seen evidence of a trend for companies to "essentially forego support and maintenance contracts for enterprise applications, hardware, or networking infrastructure, electing, instead, to have internal IT support the products." He also wanted to know if I had an opinion on what types of IT products are good candidates for abandoning vendor support.

His inquiry got me thinking on this subject.

"Going naked"
The practice of just saying no to support contracts has been going on as long as software vendors have been charging for maintenance and support. It may sound crazy, but it may make sense to abandon vendor support if an organization (a) has highly modified the software, or (b) is running on an older release no longer supported, or (c) intends never to upgrade, or (d) plans to migrate from the system in the near future.

I think that any software package for which vendors charge maintenance for is a potential target for a “go naked” strategy. Systems that have frequent regulatory updates (think, payroll, or sales tax compliance) have a stronger business case for staying on maintenance. But systems that have maintenance/support contracts only for bug fixes, or help desk, or access to future enhancements have a weaker business case for vendor support contracts.

An alternative to “going naked” (as this practice is sometimes called) is to buy a maintenance/support contract from a third-party service organization, such as TomorrowNow or Rimini Street.

My own opinion is that the trend has increased toward going naked, or signing up for third-party support, as software vendors have increased their fees for maintenance to the point where they may not be justified in a larger percentage of cases.

Good idea or risky tactic?
Vendors love their maintenance and support businesses. They provide recurring income and often carry the highest profit margins of any revenue source. But do maintenance contracts always make sense for the buyer?

Now I'm looking for examples. Do you work for an organization that has dropped its maintenance contract for an existing system? Was this the right decision? Leave a comment on this post or email me with details.

Related posts
Reading the fine print on ERP contracts
High software maintenance fees and what to do about them

Legal basis for third-party ERP support industry

Some interesting information continues to dribble out of the Oracle vs. SAP/TomorrowNow lawsuit. Oracle filed the lawsuit last year alleging that SAP's TomorrowNow (TN) unit perpetuated massive theft of Oracle's intellectual property in delivering maintenance and support services to Oracle customers.

As part of the proceedings, SAP has released a 2002 letter from TN to PeopleSoft, in response to a previous letter from PeopleSoft alleging that TN's provision of third-party support was illegal.

The letter provides a good overview of the basis for third-party support. The letter takes particular exception to PeopleSoft's claim that TN is misleading customers about its ability to perform PeopleSoft upgrades and claims that it cannot provide such services because it is not "a certified member of PeopleSoft's alliance network."

This last claim attacks the very basis for a third-party support industry. So, TN took dead aim to counter that claim. The letter states,

..you are undoubtedly aware, or certainly should be aware, that

(a) there is no requirement that a service provider join or be affiliated with any PeopleSoft-controlled alliance before servicing a customer's PeopleSoft software

(b) the tools for physically upgrading releases are built into the PeopleSoft software release itself and licensed with the software product to customers,

(c) customers who pay PeopleSoft for annual support services have rights to access and use PeoleSoft upgrade documentation and instructions made generally available to PeopleSoft's annual support services customers regardless of whether a customer chooses to hire PeopleSoft, a third-party, or internally and independently performs the upgrade process,

(d) many software upgrades are performed by customers without fee-based consulting assistance from either PeopleSoft or its certified alliance network members, and

(e) many software upgrades are performed by customers without their internal project staff of employees and/or contractors receiving any full education or training equivalent to PeopleSoft's "Consultant Certification" curriculum used by PeopleSoft internally for its fee-based consultants or the curriculum used for the fee-based consultants of its certified alliance network members.

Apparently, the letter had its intended effect, as PeopleSoft appears to have not pursued any further action toward TN after receiving this letter--that is, until Oracle (PeopleSoft's new owner) took action last year.

Oracle's current complaint against SAP (TN's new owner) and TN alleges conduct that goes far beyond the points in the 2002 letter. To my view, Oracle is not alleging that TN had no right to offer the services it offered. Only that it did so by misappropriating Oracle's intellectual property.

Whether that is true is a matter now for the court to decide.

Related posts
Rimini Street to provide third-party support for SAP
Court orders mediation in Oracle vs. SAP/TomorrowNow case
Oracle wants to broaden lawsuit against SAP and TomorrowNow
SAP lists TomorrowNow as a discontinued operation
TomorrowNow and the future of third-party support providers