The Metaphor … continued

The cable TV metaphor I introduced a couple of weeks back (in this post) has been extremely helpful in explaining the benefits of Utility Computing – along with the cost and support structures. As such, I thought it would be worthwhile to explore this a little further – with some more concrete examples. For these examples, I will use the offerings from Hoolipot to illustrate how this works:

Cable Television	Package	Utility Computing
Basic Cable Limited Basic Starter	Basic Business	Email Word processing Spreadsheets Presentation Calendaring Webpage creation Instant messaging Video sharing Web and message security
Expanded Basic Digital Preferred Premium Channels	Enhanced Business	Basic Business plus: Small business accounting capabilities Online payment (credit/debit card capabilities) Online Payroll
Sports Package Movie Channels Cable Latino	Specialized	Either Basic or Enhanced Business plus your own specialized business applications. These applications might be specific to your vertical or they may be custom built applications that you use to run your business.
Pay-per-view	On Demand	Applications required for short-term use only. This may include marketing, design or CRM tools

As you can see, the offerings line up extremely well – and you can even include the use of “pay-per-view” applications which may only be required on a temporary basis.You can even use this metaphor to answer a question I saw posed during the week about the software vendors, and where they will fit in this new model. The software vendors will be the “TV networks” in this model. They will continue to produce content (in the same way that ABC, CBS and HBO do) which will be “broadcast” to customers who have “subscribed” to their “channels”. Some software vendors will refuse to make this transition – possibly to their detriment.

Is this description in line with how you view Utility Computing? I would love to hear your thoughts on this!

Utility Computing SLAs

When comparing Utility Computing to “traditional computing” (for want of a better term), a question that often comes up is around service level agreements, and service level management in general. ITIL (and other IT process guidelines) have ensured that most IT professionals have understood the value of Service Levels, and have used them as a way to broker an agreement between themselves and the rest of the business. The cynical observer would see this just as a way for IT to cover it’s ass, but the smart organizations with SLAs in place actually use them to the benefit of both the business (they know what to expect) and the IT department (they know what is expected of them). SLAs are usually performance and/or availability based (although there are plenty of other ways that service levels can be measured). A performance-based SLA will often state something like:

“A priority one call placed to the Service Desk between the hours of 8am and 6pm will be acknowledged within 5 minutes, and will have a support engineer working on it within 15 minutes”

… while an availability-based SLA might look like this:

“The Oracle Financials application will be available 99% of the time during normal business hours and 99.99% of the time during the end-of-quarter period”

So, when you move to a UC model, what are the SLAs? Who maintains them? What are the consequences of them not being met? If many different businesses are all getting their computing utility from the one resource, how are different SLAs maintained? So many questions … but the answer is pretty simple.

Since a UC provider is just about providing business applications as a utility, there can only be one real measurement – application availability. No other measurement matters. The business (consumer) of a UC service doesn’t care about servers, databases or networks … they just need their business application available when they need it. They don’t even care about how long it takes someone to respond to their call or provide a workaround – because they are just determining factors of application availability. If the application is available as it should be, then everything else will fall into place.

So, if there’s only one measurement … what should it be? As one of the pioneers in the Utility Computing space, Google obviously would have put a lot of thought into this … and they came up with 99.9% availability as their SLA commitment. This means that their applications can be unavailable for 8.7 hours per year – just over one business day in a whole year. If they exceed that, they start giving free service (as defined here) to each of their 1.75 million business customers! 99.9% (often called “three-nines”) seems like a pretty realistic expectation for a UC customer … considering this is probably FAR less downtime than they experience with their self-maintained applications.

So there’s one more thing that UC makes easier for it’s consumers. No complex SLAs to wade through; no IT department trying to use those SLAs to defend itself from the business it is supposed to be supporting; just a simple, measurable, actionable number that actually means something to the business.

Bulletproof Utilities

One of the most common arguments used against Utility Computing is one that states “because my IT is mission critical to my business, it needs to be bulletproof … and I can’t rely on a third-party to provide that level of service”. When using this argument, people even cite examples like the recent GMail outage (which some wags called “GFail”) as an example of why Utility Computing won’t work.

But in reality, how different is this to the expensive corporate email systems many companies use? According to Osterman Research, corporate e-mail systems in mid-size and large organizations have a mean of 53 minutes of unplanned downtime in a typical month. That works out to almost 11 hours a year … and that’s just the UNPLANNED downtime. Also, don’t forget that those corporate email systems are maintained by expensive corporate IT staff. Compare that to GMail – who have just had just a few outages this year (all of which they fixed quickly) on a system that is free for the majority of its users, and very affordable for those businesses who pay for it. Its not hard to see which side of the argument makes the most sense.

Its also interesting to observe the reactions of people after this incident. Most of the comments on the articles written about “GFail” were sharply divided into the two camps of “Business” and “Technical”. The technical guys were indignant that they had lost their email, and threw about suggestions that fellow geeks should “maintain an IMAP client” or “enable POP access” and there were some genuinely worried people out there … “Words and phrases like “apocalypse” and “digital terrorism” really did come to mind when I realized the #gfail” … perhaps a little dramatic? The business perspective was much more level-headed, with people commenting that while the outage was inconvenient, Google’s response was quick and professional. It was the business people making comments like “We use Google Apps for our small consulting business. The outage affected us, but not critically. The question for a business has to be – what do you get in return for the money you pay?” … and this is the crux of the matter. Email – like other Utility Computing applications – is a business tool. It does not exist for the gratification of the “techies”, and it is not about them that we should be worried when an outage is experienced. On the contrary, it’s their job to get things back up and running so that business is impacted as little as possible.

So – if you want to talk about Utility Computing, don’t talk to a techie (at least, not at first) … talk to a business person who understands why these applications exist in the first place. They will tell you that they don’t need bulletproof, just reliable … and there’s a big, and expensive, difference!