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

The Enterprise System Spectator

Monday, February 20, 2012

Mischaracterization of Multitenancy in an SAP-sponsored Blog Post

SAP sponsored blog post
In an SAP-sponsored post on ZDnet, SAP employee Eric Lai attempts to identify "four big problems" with multitenancy in cloud applications. As I am writing a soon-to-be published research report on cloud ERP, I was interested to hear Eric's take on the subject.

By way of definition, in a software-as-a-service application, the term multitenancy refers to an application architecture where a single instance of the system's application code and database serves multiple customers.

Please read Lai's entire post, as, in the interest of space, I will not quote from it extensively.

Lai gets off to a good start:
Anyone can see how much more efficient [multitenancy] is versus the old server hosting model, where the ratio of server:customer is 1:1. Even using today’s Red Hat-type virtualization, each server can cram fewer users/customers onto itself than a true multitenant service.
Besides their efficiency, multitenant services can scale easily. Both of these mean lower costs for the hosters/software vendors, and, potentially, lower prices for customers.
No argument there. But then he quickly goes downhill. He first draws a distinction between consumers and enterprise customers, which have "much more rigorous requirements." He then presents his four objections to multitenancy.

1. "It's Inflexible."

Here, Lai doesn't really make a flexibility argument as much as a security and privacy argument. He points to privacy laws in some European regions that require data in some circumstances to be stored locally. But this is not an argument against multitenancy--it's an argument in favor of local data centers. A single-tenant system provider will need to build local data centers in the regions it serves, just as a multitenant provider will need to do so.

He then argues that multitenant systems might allow competitors on the same system to see each other's confidential information. I agree that IP theft is an increasing problem, especially with organized gangs of cyber-criminals in Eastern Europe and Asia, who in some cases may have the endorsement of their governments. (See, for example, this report.) But I do not know of a single cases where one tenant on a multitenant system was able to access the data of another customer on the same system. Tellingly, Lai provides not a single reference of such a confidentiality breach.

2. "It's Less Secure."

He now makes the security argument again, from a different angle. Here he argues that a multitenant database gives a careless database administrator, or a malicious hacker, the opportunity to compromise, with one breach, the data of multiple customers rather than just a single customer. He overlooks the fact that if a DBA is careless with one database, he or she would probably be careless with multiple databases. Likewise, if a criminal is able to gain access to a single customer's database in a secured data center, he or she will probably be able to gain access to many or all of the customer databases in the same data center.

3. "It's Less Powerful."

Here the argument is that the capabilities of the platform-as-a-service providers do not match the capabilities of traditional database tools. He points to Salesforce.com's database.com, Google App Engine, and Windows Azure as examples. Here, I find Lai's argument similar to that of Larry Ellison, head of SAP's arch-rival, Oracle.

In response I would point to the testimony of the head of development of one new enterprise SaaS provider. This individual came from a traditional enterprise software development and has now built sophisticated enterprise applications on both NetSuite's platform and on Force.com. He told me recently, "Frank, you wouldn't believe how easy it is to develop on these platforms. Things that used to take us months [at vendor X], we can now do in weeks or days."

Although I am no longer into software development, I am willing to stipulate that the newer cloud platform-as-a-service (PaaS) environments do not have all of the features and functions of traditional on-premise application development environments. (So also, in the old days we couldn't do as much with third-generation procedural languages, such as COBOL, as we could in assembler language. And, we couldn't do as much in 4GLs as we could in third generation.) But a PaaS removes an enormous amount of development work, by abstracting database, middleware, and user-interface functions, allowing the developer to focus on business logic. Furthermore, if (as I believe) PaaS is a disruptive technology, we should expect its capabilities to improve over time, and increasingly able to take on jobs that formerly could only be done by traditional tools.

4. "It May Be More Costly."

Here he doesn't mean the cost to the customer, but the cost to the ISV who wants to move from a traditional on-premises software product to a cloud offering. He is arguing, in essence, that it is cheaper for the vendor to simply host his traditional product as a single-tenant offering (i.e. changing nothing) than to rewrite it as a true multi-tenant SaaS offering.

As an advocate for enterprise IT buyers, I have to ask, will that hosted offering will be less costly for customers? Lai doesn't say. But in his introductory paragraphs (quoted earlier), he indicates that multitenancy offers "lower costs for the hosters/software vendors, and, potentially, lower prices for customers." So he has contradicted himself in his own post.

A Puzzling Position

Finally, what I find strange about this SAP-sponsored blog post is that it seems to contradict SAP's own position relative to Business ByDesign (ByD).

ByD is a full multi-tenant ERP offering for SMBs. It is a well-known fact that SAP's first attempt at ByD employed a single-tenant architecture, similar to that proposed by Lai in his blog post. That iteration was not successful in that, according to SAP spokespeople, they could not get that approach to scale cost-effectively. So, SAP took an extra two years or so and rewrote ByD as a completely multi-tenant application. The system is rolling out in multiple geographies worldwide, in local data centers where required, presumably with security and privacy measures commensurate with SAP's high standards for customers. The system is cost-competitive with other SaaS ERP offerings and has grown quickly to over 1,000 customers at the end of 2011.

SAP now has such confidence in its ByD platform that it has made it the platform for developing its line-of-business applications, such as Sales OnDemand and Travel OnDemand, for its large enterprise customers--presumably the ones with the most demanding security and privacy requirements.

Now, at the top of the post, ZDnet does make the disclaimer, "Eric's views are his alone and do not necessarily represent those of SAP." Still, as I mentioned, I find it puzzling that Lai's views appear to be closer to Larry Ellison's than those of his employer.

I am waiting for SAP's rebuttal to its own sponsored post.

Update: Eric Lai responds in the comments below.
LinkUpdate, Feb.23: Please read the more detailed response on SDN by Sybase's Eric Farrar.

Related Posts

Cutting Through the Fog of Cloud Computing Definitions
SAP in Transition on Mobile, Cloud, and In-Memory Computing

Labels: , , ,


by Frank Scavo, 2/20/2012 08:43:00 AM | permalink | e-mail this!

Subscribe!

 Reader Comments:

Hi Frank - agreed, Eric's post does portray a muddled view of multitenancy. A company called Kinetic Data has done some interesting work in this area, presenting services in a way that doesn't require code changes in the underlying enterprise platform (SAP, Oracle, whatever). Here's a relevant link if you're interested: http://kineticdata.com/Markets/ServiceProviders.html

Thanks!

Tom
 
Hi Frank - I do appreciate your taking the time to read and respond to my post, as I enjoy an honest debate.

First of all, I do indeed think multitenancy is a great thing for cloud applications, both for the vendor (due to increased efficiency) and for enterprise IT (due to resulting lower prices).

My critique of multi-tenancy was aimed purely at cloud data platforms and platforms-as-a-service (PaaS). And not just any cloud-based platforms, but ones that sacrifice features and/or customization in favor of one-size-fits-all scale.

My understanding is that is the case today with the biggest names in the PaaS space. But I'd love to hear about ones that are exceptions to the rule.

Also, this blog was aimed at enterprise ISVs and in-house enterprise developers, who are wrestling whether to move from on-prem or single-hosted platforms.

For them, I truly believe that many multitenant cloud platforms today lack the flexibility to account for their security/regulatory requirements. Or that the benefits of a new platform don't justify the cost of porting an app.

Apologies if my imprecise language caused any conflation/confusion. This was not meant to be an inadvertant criticism of SAP's own products like ByD or Successfactors.

Would welcome comments from any and all, esp. the SAP mentors like Messr Reed and/or Messr Howlett.
 
Glad to see that Eric responded. The concept of multi-tenancy is a black and white definition. You either have it or not. In this case, SAP needs to deliver it.

Now here's an interesting fact, when I go back to my old architecture friends, it appears that core R/3 was architected for MT. It supported about 100+ tenancies. Not sure who's idea it was to take it out in the future versions but that person must be kicking themselves by now!!!

R
 
It's good of Eric to take the time to respond to Frank's spot-on analysis. But really this is such a tiresome debate.

It seems from Eric's comment that his criticism of multi-tenancy is that it's not identical to conventional on-premise architectures: "My critique of multi-tenancy was aimed purely at ... cloud-based platforms ... that sacrifice features and/or customization in favor of one-size-fits-all scale."

Correct, cloud trades custom features for scale, because it enables an economy of operation and rapidity of feature refresh that more than makes up for having to do one or two things a little differently. If you don't understand this, then you really shouldn't waste your time drafting a critique.

If there's a custom feature that you simply can't afford to miss out on, then shop around and if you can't find it in the market today, wait a few months until a suitable provider adds it in their next feature refresh. Don't use the lack of that feature as a straw man you can knock down to self-justify your set prejudice against the multi-tenant model.

If you're an ISV, make a careful analysis whether you should build your own multi-tenant platform or use someone else's. But only choose to remain single-tenant if you plan to retire sometime in the next five years.
 
Eric, thank you for the response. I do see now that you are talking about PaaS rather than SaaS.

However, now you have gone from simply being wrong to being incoherent.

Your position appears to be that "multitenancy is a great thing for cloud applications" (e.g. SAP's Business ByDesign), but not for "cloud data platforms and platforms-as-a-service." This makes no sense for the following reasons.

1. The benefits of multitenancy for SaaS (which you list as "increased efficiency" and "lower prices") must be the same as for PaaS.

2. It is hard to imagine why a software developer would want to build a multitenant SaaS application (which you say is a "great thing"), but do it using a single-tenant development environment. It might be because no commercially available PaaS has the ISV's desired feature set. But that points to the immaturity of the PaaS market, not to an inherent disadvantage of multitenancy.

3. Finally, the advantages of MT PaaS are seen in the thousands of applications written on platforms such as Force.com and NetSuite's Suitecloud. As my developer friend said, "These platforms are a dream." This, coming from a developer with decades of experience as a traditional ISV.

Do the cloud platforms require a rewrite for a traditional on-premises ISV? Of course. Should every ISV invest the time and effort to do such a rewrite? Of course not. It all depends on the business case for the ISV. As Phil writes above, if you are thinking to retire in the short term, maybe not.

But to turn that business decision into a general argument against cloud platforms simply makes no sense.
 
Eric -

Good of you to engage here.

I've been struggling with your blog post a bit for a couple of reasons.

One is how you framed the discussion. Another is the fact that you work for SAP so readers are inclined to assume that your views on this topic do tie into SAP's own.

On the second point, the shame of it is that SAP has done a better job than they are given credit for in terms of committing to multi-tenant archictures. This actually gives them a nice talking point against Oracle. As Frank points out, your post had the effect of blurring those lines and adding more fuel to the skeptics who think SAP has missed the boat on multi-tenancy across the board.

It's too bad, because aside from some questions on HANA and mult-tenancy SAP has yet to sort publicly, SAP has come a long way on multi-tenant apps since the early ByDesign days. I don't think you got that across in your post - some clarity there would have helped the reader.

I realize you were trying to frame the multi-tenancy talk a bit more narrowly. I thought your comment to Frank post made your position much cleared than your own blog post, which left a lot open to interpretation.

Typically, I see this debate framed as private versus public cloud, rather than multi-tenancy, and I believe that there is a definite worthy debate on the merits of private clouds for data where regulatory issues involving cloud storage come into play.

Most reasonable people accept the idea that customers will make their own value (and in some cases, regulatory)-based decisions on hybrid cloud landscapes so I'm not sure there's a huge discussion to be had there.

However, when you expanded things to multi-tenant PaaS, things got muddier. I guess it's how you look at PaaS, but for ISVs looking to develop on a platform, there is a big value in a multi-tenant architecture that will bring their solutions to scale.

A more critical issue for you is that SAP's own PaaS plans are clearly aligned with multi-tenant approaches. Your post made me wonder if you've had a chance to talk with SAP's own PaaS team about what they are up to. The Mentors had a meeting with them today and I again got a clear sense that multi-tenancy is a very important architectural consideration across SAP's ABAP and Java PaaS solutions.

This would make sense, since the idea is to allow ISVs to develop industry and add-on solutions that complement products such as ByDesign, Sales OnDemand, and eventually, on the Java side, StreamWork, SuccessFactors, etc.

If you disagree with SAP on this point, fine, but I think it behooves you to make that as clear as possible so that readers realize not only your position but in this case (PaaS multi-tenancy) how you deviate from SAP's. Instead, in my opinion, too many readers left your post thinking SAP "just doesn't get multi-tenancy."

I don't think that was your intent, but when you blog about mobility, you are much more clearly aligned with SAP and Sybase, so readers have a tendency to think the same this time around. At any rate SAP could help your cause by being more painfully clear about their own PaaS plans and I expect after SuccessFactors is pulled into the roadmap we'll have our answers.
 
My Sybase colleague Eric Farrar explains what I meant to say about Multitenancy and PaaS and ISVs, only much much better.

http://iablog.sybase.com/efarrar/2012/02/multi-tenancy-platforms-and-isvs/

I'd also recommend this blog by SAP Mentor Richard Hirsch, who explains how he views SQL Anywhere On-Demand in relation to other Platforms-as-a-Service, including SAP's.

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/26836
 
Great rebuttal - you have very strong points here.
We actually offer a Multi-Tenant solution 'in the cloud' that works really well for most of our customers:
http://www.bicomsystems.com/products/multi-tenant-pbx/
Check it out if interested.

Thanks,
Laura
 
Post a Comment
 

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
Latest postings