Category Archives: Cloud Software

Snarky Comments on Cloud SLAs

When I read articles about contracting with cloud service providers (or other IT service providers such as colocation providers) often I see a lot of emphasis on Service Level Agreements (SLAs).  That’s the wisdom that they offer you: make sure you have a solid SLA with your cloud service provider.  The only problem with SLAs is that while, theoretically, they should be a useful tool for managing your cloud vendors, in practice they are a bit weak.   Here’s why:

1) The standard penalties you are likely to get in your contract with a cloud vendor if they miss their SLA are miniscule compared with the pain and suffering you are going to experience if the service goes down.  One cloud provider with whom I’m familiar (I won’t name them, but their SLA is pretty typical) will provide a 5% credit if their uptime is between 99-99.5% (their SLA guarantee is 99.5%).  So let’s say you are spending $5000 per month with that service provider, and that during one month they are down for 7 hours, and you can’t service your customers for most of a business day.  What do they give you?  Let’s see….a month with 31 days has 744 hours in it.  So if they go down for 7 hours, we’re just above 99% uptime.  So they owe you 5% of $5,000, which is $250.  ARE YOU KIDDING ME???  Your business is out one day’s revenues, the CEO is on the phone asking to speak with “shithead”, and your cloud service provider is going to give you $250?

2) Typically, cloud vendors lowball the SLA.  A typical number you’ll see in the marketplace now is uptime SLAs in the range of 99.5%.  So over the course of a year, they could be down for…365*0.005 = 1.825 days?  There’s a good chance I could hit 99.5% hosting your software on my laptop.   (Well, as long as I promise not to fire up iTunes, which seems to crash my Windows 7 laptop.  Yeah, yeah, I know.  It rocks on a Mac.)  By the way, that 99.5% target doesn’t include scheduled downtime.  So as long as they announce the downtime ahead of time, it doesn’t count.  By the way, ask your vendors how much notice they provide.  Some vendors only give about a day’s notice for maintenance windows, which makes it difficult if you have users that use the system during off-hours, when the vendor is doing the maintenance.  So anyway, the cloud vendors just aren’t setting very aggressive SLAs.  If you ask the vendor, they’ll probably admit that they are lowballing the SLA, or at least they’ll say, “Well, our long run average is certainly better than that.”

3) Some cloud vendors won’t even provide an SLA. is an example.  At least they won’t give you one if you’re not a mega-customer.  And apparently even for big customers they try to avoid doing so, to the point where according to some sources (, they won’t even call you back if you call and ask for an SLA!  So they are really just saying “look, we think our service level is good enough, but we’re not going to guarantee it, so just try it out and if you aren’t happy, then just leave.”  For certain kinds of services that’s probably good enough, but for “mission critical” services, it’s not a very reasonable answer.  One thing Salesforce does that I like a lot, though, is give you transparency to their current system status, and recent history.  Check this out:  So you can have some feeling that they’ll be honest with you if there is an issue.  However, they don’t provide data on their long-run historical performance and they aren’t making you any promises.

So what do you need to do to?  Forget about SLAs?  Not entirely.  I’ll talk about some ideas for managing SLAs in my next post (people have been telling me I put too much information in my posts and I need to chop it up!)

Tagged ,

Cloud Software – 4 Step Plan

I’ve had a chance to do some thinking about what it takes to make a good cloud application, or even a good cloud software company.  Here, when I say “application”, I’m talking mainly about business applications, since I know more about those than about consumer apps.  But I also think that those of us who’ve worked more on the business applications side than on the consumer technology side can learn a lot from looking at consumer apps—this is where the trends are coming from, since all of your users are using iPhones and, so if your business applications don’t make sense for someone who has Amazon-like expectations, you’re going to have a problem soon.

So here’s a 4-step program for cloudifying your software company.  In short, you need to combat everything that sucks about traditional business applications.  Traditional enterprise systems are bloated with too much functionality, take too long to achieve value, cost too much, and take too long for the vendor to sell.  The implementation of these systems is akin to corporate root canal (I’m not the first one to say that—people seem to think the Wall Street Journal said it first, but I couldn’t find the article), and the risk of failure is significant.  This lengthens the sales cycle, and for a long time has been curtailing innovation in the software industry, since buyers wanted to play it safe and do what their colleagues were doing rather than be innovative, because the risks to their careers were too great if a major project failed.  So, given all of this, here are my four steps:

1)      Simplify the product – Ever used Basecamp?  The guys at 37 Signals took at look at MS Project and decided it was a bloated piece of crap that didn’t actually help you to…ummmm…manage projects.  So instead, they provided a bare-bones project management tool on the web.  They don’t provide fancy functionality such as letting you model the resources assigned to a project in order to “load balance” it.   (Ever tried to do that in MS Project?  Every time I’ve tried, I ended up determining that my project would get done in 2025 unless everyone worked 24 hours a day, in which case you could bring it in a couple of years.)  So your typical Project Management Office guy is going to think it’s a joke, because he went to the PMI course and they gave him a lot of fat binders that don’t look like Basecamp.  All Basecamp does is provide the ability for a team to collaborate over the web on a set of tasks.  That’s enough for a lot of people, and not just small company people.  Lots of individuals in larger companies use Basecamp too, and they just put it on their corporate credit card and expense it, completely circumventing their IT departments, who probably don’t even know it’s being used in the company.  So it turns out there’s a market for stripped down, simplified cloud services, and often times, less is more when it comes to business applications.

2)      Speed-up the time-to-value and remove barriers to adoption – A great example is, the personal finance service.  These guys just nailed one thing, and as a result they sold the company only two years after its founding to Intuit for $170 Million.  What they did was to remove barriers to adoption (as compared with traditional solutions), and in the process reduced the time for the customer to see some value.  When first appeared, their main competition was Intuit Quicken.   With Quicken, electronic banking was not supported for all banks, it was a pain to set up (as I recall, you needed to wait for something to happen at Citibank, so they could approve Quicken access to your account, and this could take a few days), and Quicken couldn’t access your brokerage accounts.  Even more annoying, you had to enter some transactions manually, and try to match them up to what was going on in your bank account.  Finally, the amounts Quicken thought were in your accounts would never quite match what was really in them, because you got some dividends from IBM and couldn’t be bothered to enter them into Quicken manually.  All of these things made it difficult to use Quicken and get any value out of it.  By contrast, if you logged into Mint, 15 minutes later you were staring at your total net worth on one screen.  Depressing, yes, but it was also amazing to users, who were able to see something useful right away.  With people using sites like Mint in their personal lives, users have little tolerance for applications that take a long time to show value.

3)      Think Freemium – Most great cloud services let you get started cheaply, or even for free.  This removes the risk for the customer that the damn thing won’t work as you expect, which is a very real risk with traditional enterprise software.  Dropbox is a great example of the “freemium” model.  They let you start out by storing 2 GB in the cloud for free.  They are betting that you’ll see value from the service quickly (point 2), dump a lot of files in there, and soon you’ll be paying for the service.  Well, it’s working.  I’m trying to figure out why I’d want to store things on my hard drive, rather than Dropbox.  The files look the same in Dropbox, except I can access them anywhere, which is really useful since I prefer to use my desktop at home, my laptop on the road, and sometimes a client gives me a PC to use when I’m at their site.  So anyway, back to my point—hook the customers for free and then charge them.  Just as in point 2, we want to remove barriers to adoption, and if we give the user a free trial, we’ve just knocked down one of the traditional barriers to the adoption of enterprise software—the high up-front cost.

4)      Rethink the Sales and Implementation Model – I need to credit Mark Benioff for this one.  The guys at 37 Signals also touch on it in their book, “Rework”, which is great if you haven’t read it.  In Benioff’s book, “Behind the Cloud”, he describes how the conventional wisdom in the enterprise software world is that you need a “bag carrying” sales force to sell the stuff, because it’s a big investment, the time-to-value is long, and therefore the customer is going to make the decision slowly, be risk-averse, and it’s going to go up to a high level in the customer’s organization for approval, which it turn further increases the lead time to make the sale, and not incidentally, the cost of sales for the software company.  And these high costs need to get paid by guess who?  In the end, the software buyer needs to pay for all of this, so it again reinforces the long decision cycle, with the sales process managed by “enterprise” sales people.  Benioff turned that conventional wisdom on its head, and found that “inside sales” (i.e., telesales) works for cloud apps.  It works because the up-front commitment the customer needs to make is low, so lower level managers can make a decision on the purchase, and since there’s little risk due to the ability to try it for free (point 3), and the time-to-value is quick (point 2).  So Benioff started out with telesales, and it worked, but a funny thing happened next.  Larger customers started buying Salesforce, and now with, you have a framework for customizing the platform.  So now you’ve got Salesforce Value Added Resellers (VARs) who are out there implementing customizations to Salesforce, which is a little like the traditional enterprise implementation model where VARs, consulting firms, and the vendors themselves would send high-priced consultants into the field to configure and customize the system for you.  But I don’t think it disproves the point—the sales and implementation models change with cloud software, and you need to move towards telesales and tele-implementation (a support team that works through a customer’s implementation issues over the phone and the web, rather than by using a traveling army of IT consultants).

The great thing about cloud applications is that they are opening up all kinds of opportunities to innovate, in a sector that’s been hidebound for the past decade.  Look at the supply chain software space—the companies that invented supply-chain software were innovators in the 1990’s–best-of-breed players who created the first transportation management systems, supply-chain planning systems, and warehouse management systems.  But in the 2000’s it was hard to be an innovator.  Customers were hesitant to take a chance.  “What if the system doesn’t work as advertised?  Do we really want to sign up for a long and tough implementation with an upstart vendor?”  Today, the cloud is changing that by reducing the costs and risks of going with an innovator.  That’s better for customers and better for software vendors as well (at least the innovative ones).

Tagged ,