Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Wednesday, June 18, 2008

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

by Frank Scavo, 6/18/2008 12:52:00 PM | permalink | e-mail this!

Subscribe!

Read/post comments!
(1) Links to this post

Tuesday, June 17, 2008

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

by Frank Scavo, 6/17/2008 08:08:00 AM | permalink | e-mail this!

Subscribe!

Read/post comments!
(2) Links to this post

Thursday, June 12, 2008

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

by Frank Scavo, 6/12/2008 11:31:00 AM | permalink | e-mail this!

Subscribe!

Read/post comments!
(0) Links to this post

Powered by Blogger

(c) 2002-2014, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.


Go to latest postings

Custom Search

Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed

AddThis Feed Button


Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report

Get these headlines on your site, free!


Awards

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Blog Roll and Favorite Sites
Strativa: ERP software vendor evaluation, selection, and implementation consultants, California
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Vinnie Mirchandani: The Deal Architect
Si Chen's Open Source Strategies
diginomica
CISO Handbook


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
Latest postings