Thursday, August 14, 2008

Quick response to a silly blog

Normally, I have my own plans for what I want to post on my blog and I leave the fencing for the US women's Olympic team.
BUT, this morning I received an email from a friend who is also a CEO of a SaaS company, pointing out a new post with an outrageous title Why You Should Steer Your Customer Away from SaaS, for Now asking me to comment on it in my blog.

Frank's argument was that since Goggle's Gmail had an outage " just mention Google and Amazon's problems and a shadow of doubt can be place over the whole hosted applications market" He goes on to say that cloud computing (SaaS) "is just a pipe dream" and that we should resort to good old reliable client server technology.

I told my friendly CEO that it is such a non-issue that I don't think I should waste a good posting on it, but I did add a comment to the blog.
As the day went by and my comment was neither posted nor acknowledged, I decided to use this forum to respond.

So, my comment went something like this:
  1. I can't believe we are even having this discussion. This is not 2003 when people were discussing the merits of this novel delivery system. As Dave Rosenberg pointed yesterday in his Negative Approach blog "Software-as-a-Service is so common it's actually boring at this point"
  2. Frank's argument is as valid as steering customers away from motor cars back to horse drawn carts, because accidents happen.
  3. SaaS companies make a living out of providing these services. Although I do not have the statistics, I know from numerous interactions with many companies that your average SaaS uptime figures are far better than your average IT department's.
  4. Part of the success of SaaS has to do with the fact that IT was simply not delivering the goods, not in performance nor availability, so the business units went out looking for someone who could deliver a better service, NOW.
There. I don't think I need to splash in the mud much more. I must say though that I feel like I'm playing out a scene from Back to the Future IV.

Thursday, August 07, 2008

Your Typical SaaS Operations

Personal note: For those avid fan(s) that have wondered why I have disappeared for such a long time. I took a long, forced vacation, having been sucked into what is not commonly known as the SaaS Operations Black Hole. I went under the radar as VP Operations and Services in a SaaS company, and although it did not leave me time to write blogs or visit the bathroom, I have collected an arsenal of good stuff from hands-on experience, both good and bad, which I intend to share, time allowing.
(One of the reasons I changed my vocation as a consultant to on-premise companies who were contemplating going on-demand, was my realization that it was mostly a futile attempt. It is the equivalent of turning slow moving, cold-blooded dinosaurs into fast, warm-blooded mammals without the benefit of a few hundred million years of evolution. But more on that in a future blog.)
Very well, back to the subject at hand. I have been visiting, talking to, sharing with, advising many SaaS startups in the SF Bay Area in the past year and a clear (actually murky) state of affairs seems to emerge
Company Profile:
Name: YTSC (Your Typical SaaS Company)
Age: 3-4 years in the making.
Staff: between 20-40 people, possibly a small dev team offshore in Southeast Asia or one of the former Soviet Union republics.
Technology: Being relatively fresh, YTCS technology is multi-tenant, customer-centric, with (hopefully) an automatic customer on-boarding mechanism, and they surely have an integration with Salseforce.com (or perhaps NetSuite, SugarCRM, MSDynamics, etc.). Some fancy configuration capabilities should be built into the product and Web Services integration options are available.
Platform: most probably a LAMP shop. Let’s start with all the free stuff and hope to reach profitability before loading the heavy guns. And, hey, we’re big advocates of open-source.
Sales force Compensation: Hmm, we read all the papers, attended the webinars. We think we’re getting it right, but why does the Sales department feel like Grand Central Station?
Customers: A lot of mom & pop shops, a bunch of WEB 2.0 companies with flamboyant logos, a number of departmental customers with big names that we flash on our web site.
Profitability: Surely by next year.
YTSC is now poised for accelerated growth. The customers seem to like the service and the price, and it looks like the numbers will grow rapidly; at least this is what YTSC’s newly acquired VP of Sales has projected.
So how is YTSC prepared for this rapid growth? Do they have the People, Practices and Programs (P-cube) in place? Are they ready to scale from dozens of customers to hundreds and, hopefully, thousands?
My guess is NO. Let me think about that for a moment… Naw.
So why does it look unpromising? Being typical, YTSC Operations has the following traits:
  • Operations is under the auspices of Engineering. There is no VP of Operations; there is no Operations group. A Sys Admin is managing the production servers and probably doing office IT on the side.

  • The CTO is responsible for uptime, availability and performance. Does the CTO have an Operations background? I'll bet my lunch money that he doesn't. Is there a Staging platform? Probably not. Can the engineers log into production servers and modify configurations? Yeah. Actually we just fixed that nasty bug during lunch break.
  • There is no application-level monitoring in place, or trend analysis.
  • Is Customer Churn being tracked and analyzed? (What? What was that?)
  • There is no 24X7 support, although YTSC claims it is a 24X7 shop.
  • Are the following crucial practices defined and followed?
Change management – the cause of over 60% of downtime is caused by good intentioned modifications to the platform. Is there a proper process in place? Is there an RFC (Request For Change) form and procedure? A change committee?
Incident Management – are Support, Operations and Engineering aligned in a well rehearsed routine; roles and responsibilities defined? Is there an Incident management system in place? How about a knowledgebase?
Configuration Management – are hundreds of moving parts accounted for? Are they linked into the Change Management process – actually, we don’t have a Change Management practice.
Availability Management – how do you analyze unavailability? How do you “budget” downtime? Do you know where to invest your next Dollar to ensure optimal availability? It should be all tied into an Incident management system. But, wait we don’t have one.
Release Management – how, when, how often, naming conventions. How does it tie into Change Management and Configuration Management?
SLA Management – Are we providing what we promised? Are we tracking effect of incidents on customers? Are we compensating them according to our contractual commitments? Is it tied into our (hosted) CRM solution? Hard to do without an Incident Management system.
Are we any better than we were last month, last year? Can anybody tell?
No doubt, parts of these practices have been in place with less fancy names. Otherwise YTSC would not have survived this far. But Excel and Notepad will not suffice for a large scale operation.
Most companies understand that (or maybe that is wishful thinking), but when having to chose between investing the next Dollar in great features that customers have been begging for, or that ugly, boring, misunderstood, 800 pound gorilla, they will opt for the former. Pay now or pay later.
I will cover some of these practices in future posts, Google willing.