SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for October 8th, 2007

Amazon Launches SLA’s for Web Services

Posted by Bob Warfield on October 8, 2007

Amazon has just announced an SLA policy for S3 that’s retroactive to October 1.  Arthur Bergman on O’Reilly and others have been grumbling about Amazon’s lack of Service Level Agreement, although that doesn’t seem to have impacted the enthusiasm of a lot of startups using the services that I talked to.  Nevertheless, it is evidence that they’re quite serious about encouraging others to use their Platform as a Service.

Some competitors, like Flexiscale, had been touting Amazon’s lack of SLA as a big advantage for their own services.  Scratch one advantage!

The way the SLA works is that if Amazon doesn’t meet their commitment to 99.9% up time, you’re entitled to get back up to 25% of the fee for the month, depending on the details of what actually happened.  That’s a pretty normal SLA, and it guarantees that Amazon can’t make a profit on the service (I doubt their margins are much higher!) unless they can keep to their SLA’s, so they’re properly motivated.

Related Articles

SmugMug is happy, they use Amazon S3, although they haven’t been worried about the lack of SLA’s in the past.

Posted in amazon, business, platforms, saas, strategy, Web 2.0 | 6 Comments »

The Perils of Platform as a Service (It’s Not As Bad As All That!)

Posted by Bob Warfield on October 8, 2007

OnStartups has a great post that is critical of Force, Salesforce’s SaaS platform, as a desirable way to access a platform.  I’ve said before that my concern about Force is it’s basically a very conventional platform that’s been hosted.  The tool looks a lot like SAP’s ABAP, Peoplesoft Peopletools, or a host of other Enterprise platforms.  This is something Salesforce would never let an app vendor get away with: just hosting your app without radically improving it along SaaS lines with things like multitenancy is a no-no.

OnStartups drills down to the next level of detail to make some excellent arguments that deserve a much closer look:

  • Lack of an Ecosystem
  • Upper Limit on Growth
  • Royalties
  • Lack of Price Controls
  • Gives Salesforce Too Much Power Over the ISV Using the Platform

Enterprise Irregular Rod Boothby agrees,  and suggests that while it isn’t ideal for software startups, there may be other audiences Salesforce is more interested in:

But I think is aiming at a slightly different audience. is aiming as corporate IT departments with only a couple of coders on hand, and no real resources to build and deploy ad-hoc internal applications. External consultants also fill this role. For these types of users, there may be some benefits to going with a company like

Before we throw the whole Platform as a Service idea out based on Force, let’s drill down on each of these and see if we can identify some cures that would make people more comfortable with the idea of a Platform as a Service.

Lack of an Ecosystem

This is a big one that plagues a lot of would be platform services, and not just Force.  Tools like Coghead and Bungie are in the same camp.  OnStartups says, “Where will you find other developers? Books? Training? Tools? Components?”  These are all good points that go to the inability to use any existing tools that already have vibrant ecosystems inside Force.  This has some deep implications.  If you require developers to adopt a completely proprietary approach where their old tools are no longer applicable, you create two problems.  First, developers hate having to relearn everything.  Second, developers become suspicious about what they’re going to do if they run off the edge of the platform.  Being able to employ familiar tools offers a safety valve.  The failure to address this is one of the big shortcomings of RAD and 4GL tools.  When you hit the limits of their models, you were done, and this happened all too often.

Amazon EC2 is a great example of a Platform as a Service that embraced familiar tools.  Yes, you will have to write some custom code to use it, but that code is largely around orchestrating familiar components written in familiar tools that have ecosystems.  That means developers have a much smaller learning curve:  just what’s new in Amazon EC2.  And, they can tap into their familiar ecosystems because Amazon supports a crude component model in the form of Linux virtual machines.  We can quarrel about whether finer grained components would be nicer, but the beauty of Amazon’s approach is they get to tap into any ecosystem (say open source components, for example) that runs on Linux.  That’s powerful!  I wrote about my visit to Amazon’s Startup Project, where they bring in enterpreneurs using their Platform as a Service to talk about it, and believe me, it was very interesting.

Here’s another aspect to the ecosystem argument.  Why not Open Source the platform?  We’ve gone back and forth about Open Source and SaaS before on this blog, and it surely doesn’t make sense for a lot of things, but it seems extremely valuable for a platform.  The platform vendor would employ one of the strategies Open Source vendors apply to retain economic return from the code, but the Open Source conveys several advantages to the PaaS vendor:

  • It’s a nucleus for another community to build up around in an area that Open Source traditionally shines in: platforms.  It’s been proven that these communities can spring up in a hurry when you give them source.  Look at how quickly some of them have come into being when they’ve solved a real problem.
  • It’s a safety valve in the event there is a problem with the platform.  It makes it dramatically easier for would be platform users to envision life if the platform vendor went bust.
  • It helps facilitate platform adoption.  Engineers will want to get inside and kick the tires before adopting a platform.  With Open Source, it’s all right there to look at.  This has been a recurring theme with Open Source companies I’ve talked to like SugarCRM.

Upper Limit on Growth

Like the lack of an ecosystem, this one also has elements of a fear of the unknown.  What happens if your product is phenomenally successful on the Force platform?  The example given is what if you build the next Facebook?  Can the platform keep up, or will it hinder you?

This is a very interesting question, and one where I agree with the writer that Force has problems.  Before we look at the concerns, let’s keep a perspective on what the Salesforce people will say:  if you can actually build an application that rivals Salesforce, you’ll be our most important customer and we’ll do everything we can to help you succeed, until then please remember we’re the most successful SaaS company to date!

It’s not a bad answer, but I’m not sure it’s a great answer.  I think of it as a question of business focus.  How large does your application get before it becomes distracting to Salesforce?  At that point, you’d better hope your interests are well aligned and that they really do want to help you succeed.  Because of the lack of ecosystem, you’re stuck if they don’t.

Now let’s flip back around and look at Amazon EC2 again.  It’s not the only game in town, see 3Tera for another placeholder that’s interesting and along similar lines.  And that is precisely my point, by the way.  If the PaaS is capable of running on multiple sets of infrastructure, that seems like a mighty good answer to me.  Think of it as the next thing after the LAMP stack.  Many providers offer LAMP, what is the equivalent PaaS/SaaS solution?  What comes after LAMP for more power and scalability, more business features needed for SaaS, and the ability to use a Polyglot Language strategy?  Picture such a thing available on multiple hosting infrastructures and we’re starting to get somewhere.

We will see a lot of big companies get engaged in the Utility Computing Hosting space.  I’ve named 2, but we can expect IBM, Google, Microsoft, and many others to dive in.  Sun offers Sun Grid today as another example.  What if the PaaS is more of a middle man that can rehost to any of those services, including more than one service at a time?  Doesn’t that give it more legs to deal with the “Upper Limit on Growth” angle?  Moreover, I would argue platforms should be the PaaS company’s only business, and not a sideline like Salesforce.  I’d rather my platform vendor not be building apps that could potentially compete with me, thank you very much.  This means their focus is totally around making applications built by others successful on the platform.


OnStartups worries that royalties can burden a startup to the point where it can’t compete successfully.  Force charges $25 a seat/month, which is a lot. 

It’s a lot indeed.  If we take the average of 3 SaaS vendors (Salesforce, Concur, and RightNow), they spend about 22% to deliver their services.  To get to that competitive benchmark, you either have to talk Salesforce down on the price (good luck, they’re legendary for sticking to guns on these prices), or you had better be able to charge $25/22% which is almost $114 a month for your app.  That’s a LOT more than Salesforce charges, BTW.  Suppose you want to charge $60 for your equivalent of Salesforce.  That means your PaaS vendor has to be willing to host you for a little over $13 a month or you won’t be competitive.

This seems like a massive showstopper, and in all honesty, I don’t expect it to change for Force.  Their argument will be that you’re getting the benefit of their community so that the platform delivers sales leads, and those are where the value is to offset the cost.  The reality is you can get that benefit a lot more cheaply, as many are doing, by building a small component around Force and keeping your flagship off the platform.  The small component gives you a reason to talk to Salesforce customers, and if they like it, it can be unbundled to a few seats while you sell the lion’s share of your product on a different platform.  How long Salesforce will let that continue remains to be seen.  However, if they tip their hand by being predatory about it, that’s just another reason to look elsewhere for a platform.

Must royalties be a poison pill for any PaaS offering?  I don’t think so, but they have to be inline with the economic model.  Suppose we take my 22% cost to deliver services.  If the PaaS can host the new application for 22% and provide other significant advantages such as time to market, why wouldn’t you consider it?  In this case, you’re just paying the PaaS vendor what you have to pay a hoster anyway.  In fact, I’ll submit there’s room for a little extra for the PaaS vendor if the platform really got you there an order of magnitude faster.  The thing is, the business model for the PaaS vendor must not be at war with the SaaS vendor building atop the platform.  This is possible if the PaaS economics slot into and replace existing line items for the software vendor.

Lack of Price Controls

Another great point.  Imagine you’ve built the next great mousetrap on a PaaS.  You started out with a reasonable deal along the lines of the 22% I mention above.  It seems like over time, the more you succeed, the more your PaaS vendor ups their prices, which allows them to siphon away all of your profits.  Terrible scenario!

What’s the answer?  First, it has to be possible for you to move your software in a reasonable amount of time to new lodging if it gets too ugly.  I’ve been involved in projects that involved radical rehosting around an OEM platform, for example.  That means software that has some 3rd party component at its heart, something happens, and suddenly you have to do a rewrite to replace the 3rd party.  In these cases, a “reasonable time” seems to be about 1 year.  The job can be done in less time, but the platform user feels less pressured if they can take up to 1 year without undue stress while staying on the PaaS in the meanwhile.

What about those price controls?  SaaS vendors like Chris Cabrera tell me that the solution is to sign a 2-3 year contract.  BTW, this is pretty typical for OEM component deals too.  You don’t pay BOBJ to embed Crystal Reports on a month to month deal.  You sign a 3 year contract so that your development cost is amortized over a reasonable period.  That contract sets the price during it’s term. 

So what happens at the end of the contract?  If it were me, I would simply negotiate an extension 1 year before the end of the 3 year contract for another 3 years at prices negotiated.  This makes it very manageable for the platform user to understand what it will cost them and to prevent the PaaS vendor from suddenly spiking their fees at an inopportune time.  Most ISV’s would view this as a comfortable deal because they’re familiar with these types of terms from OEM deals they’ve made.  If you can’t come to terms, you have a full year to rehost to another platform, which is doable.  SaaS CEO Steve Singh said in my interview of him that SaaS works so well because it keeps control in the hands of customers.  That’s what’s needed here too.

Such deals also benefit the PaaS vendor because they further establish stickiness and long term recurring revenue while eliminating an important objection to the sale.   Salesforce will likely give such a deal too, but the rub will be getting the deal at a price that’s economical.  Salesforce will tell you, “Show us the volume and we’ll show you the quantity discount pricing.”  The PaaS vendor has to be willing to negotiate a low price without having huge volumes yet.  This can be factored into the contract as well. 

Gives Salesforce Too Much Power Over the ISV Using the Platform

The last point is one of the most important.  I’ve written about this before when I said your platform vendor needs to act like Switzerland, and not be bent on world domination.  I gave some examples of “Swiss” platform vendors.  Adobe has done a great job for a long time not making Flash, a platform for rich user experience in the browser, punitive.  Ning does a good job not competing with their customers.  This is really the issue: is your PaaS vendor going to be tempted to enter your SaaS market?  If they’re already an application vendor, it’s scary.  What are the chances Marc Benioff will let a breakthrough CRM component thrive on his platform versus taking steps to force them to sell to him or worse, building a competitor?

BTW, the steps I’ve recommended above give customers of the PaaS platform recourse if the PaaS vendor gets too rambunctious.  If the platform is Open Sourced and runs on a variety of hardware infrastructures from companies like Amazon and others, worst case is you can take your marbles elsewhere.


Building SaaS software is hard: 

  • 70% of what you have to build will be wasted, because it doesn’t create proprietary advantage.  It’s things every single vendor does almost the same way, but that still have to be built and tested.
  • There are no good platforms yet that embed most of that 70% of basic things business software needs, let alone the next tier which is what a SaaS vendor needs (such as multitenancy).  Everyone has to “roll their own”. 
  • There’s not even really a good ecosystem around SaaS.  There are a ton of Open Source components and ecosystems around Social Web software, or simple Web software niches like E-Commerce, but SaaS remains very proprietary.

A platform that saved a lot of that waste, that slotted into an economic model the SaaS vendor could live with, that worked on a variety of hosting layers like Amazon’s EC2, that didn’t make you relearn everything and integrated with existing tools and ecosystems would be a hot commodity among the folks I know who are building out SaaS companies.  Even the web startups are beginning to wonder whether building yet another ad-supported social network is a viable business model.  They should be looking at delivering Web 2.0 to business, but business is used to dictating a whole list of requirements the garage shop angel funded web world hasn’t yet come to grips with.

Related Articles

Since this post is very highly ranked by Google when you search “Platform as a Service”, those coming here should be sure to check out the rest of the blog.  Platforms as a Service, SaaS, and Cloud Computing are the major themes I dwell on here.  There’s always something new going on in the Clouds!

Posted in business, platforms, saas, strategy | 9 Comments »

SAP Acquiring Business Objects

Posted by Bob Warfield on October 8, 2007

Interesting move in the consolidation game:  SAP is acquiring Business Objects for $6.8 billion.  As I look at the financials for BOBJ this Sunday, it looks like SAP is offering a 20% premium on a company that was going to miss its earnings number.  This is quite generous, and indicates they wanted the deal pretty badly.  They’re also paying a greater multiple on revenue than Oracle had paid for Hyperion last March. 

Why was SAP so eager for the deal?  It’s certainly one way to grow and add valuable recurring revenue in the form of the maintenance revenue associated with a large entity like Business Objects.  According to their last 10Q, these maintenance revenues were in the neighborhood of almost $150M/quarter.  It also gives them something new to take back into their installed base in order to try to extract more revenue with another module.  My guess is Oracle was coming on strong with Hyperion, which is an excellent product, and it was putting pressure on SAP’s in-house product.

The one troubling thing for me about this acquisition is that SAP does not have a strong acquisition culture.  That’s not to say they can’t do it, but acquisitions are hard.  It’s very difficult to do one without destroying a lot of the value there.  We’ll have to watch and see how SAP does with BOBJ.

Where does that leave the rest of the BI gang?  In an interesting lurch I would guess.  When you look at the breadth of Enterprise Solutions either SAP or Oracle can muster, as well as just how much data they are the systems of record for, it seems like the other vendors will find it challenging to horn in on BI opportunities where SAP and Oracle are strong.  Suddenly, they seem much less valuable.  Perhaps not.  We’ll see what the markets say about the likes of Cognos tomorrow morning.

One alternative for firms like Cognos is to try to focus more on partnering with Enterprise software companies other than SAP and Oracle.  There are many levels of partnering possible.  These two deals mean two less technology bases to OEM into other products for BI purposes.  BOBJ, in particular, had an excellent OEM’able technology in Crystal Reports.  Companies that had partnered with either player on this basis likely need to rethink that strategy and get connected with an independent.  Of course, this is challenging when musical acquisition chairs are playing.  It takes a considerable investment to build a solution with an OEM partner.  Wouldn’t it be terrible to just be finishing one up only to hear your OEM partner is being acquired by an unfriendly big company?

The other interesting dynamic is the remaining BI players will have to think twice about partnering with either Oracle or SAP.  It will be interesting to see how much of their market that cuts into.  There will be a lot of chaotic meetings going on first thing Monday to try to sort out what to do about all this.

Here is another thought:  Business Intelligence is a technology that many SaaS vendors prefer to be able to OEM from some source for the simple reason that shipping huge volumes of data to the BI tool can be prohibitive.  Hence they’d like to be able to put the BI tool at the same end as the database resides.  It’s certainly not impossible for the two to be in separate data center.  Lucid Era is a promising SaaS BI startup aimed exactly at that mechanism.  It will be interesting to see whether SaaS players who want BI find themselves pushed into partnering with LucidEra and the like, or whether they hook up with some of the remaining BI vendors.

There is a dark horse out there: open source.  I’ve looked into several of these solutions.  By and large they’re not up to snuff compared to the big boys.  One OEM technology that used to exist and was withdrawn from the market was Informatica’s Power Analyzer.  It’s a new generation tool compared to the big boys, but Informatica was never able to invest enough in it to reach critical mass.  Nevertheless, it beats the BI tools that are available open source today.  I’ve always thought Informatica should have open sourced Power Analyzer.  That would shake things up again.

We’ll continue to see the M&A game play out for software.  The economic forces driving it are strong.  SaaS is eating many companies from the bottom up, while at the same time the disruptive nature of the SaaS model prevents them meeting the challenge head on.  There are significant economies of scale that let the bigger software companies succeed more easily than the smaller ones.  And, the big ones need to acquire to gain new feedstock.

Who will fall next?


Cognos has soared almost 10% the first trading morning after the announcement.  Looks like the expectation is they’ll be the next ones picked up.  ZDNet’s Larry Dignan says they’d make a good one for Oracle.  Not clear how Cognos can stay independent.

Posted in business, strategy | Leave a Comment »