Virgin's cloud failure: Rebuttal and a deeper perspective

Yesterday's post characterized Virgin Blue airline's downtime as a "cloud" failure. Several informed readers, especially among my colleagues inside the Enterprise Irregulars, believe that assessment was misguided and limited.

Related: Cloud-based IT failure halts Virgin flights

Serial entrepreneur and generally smart enterprise guy, Bob Warfield, was among those who took issue with my post. Given the strength and clarity of his disagreement, I invited Bob to write a guest post, which is presented here.

In this guest post, Bob links success in the cloud to business strategy and people issues.

In comments about Oracle's recent OpenWorld conference, Gartner BPM analyst, Elise Olding, articulates a similar view:

Cloud is a strategic conversation, not just a technical one. Corporate strategy and leadership need embrace and understand what those changes are and prepare the organization. Internal roles and skills will change and customers will continue to expect more. One of the speakers suggested that the cloud will significantly impact collaboration, decision making and particularly knowledge work. He stated how fast a company can solve a problem will become a competitive advantage. However at the conference, the focus feels heavily slanted towards the technology with very little consideration of how to tackle these issues.

The cloud question. Regarding the narrow issue of whether Virgin Blue actually constitutes a "cloud" failure, one Enterprise Irregular noted:

Beware false clouds.

If this was truly a shared cloud, why did the outage affect only one airline? What would [outsourcing provider] Navitaire have done if its system brought down four airlines instead of one? Would Navitaire have designed its system differently?

In this case, at worst, Virgin Blue will leave Navitaire. If Navitaire were a real cloud, many of their customers would be angry and the company would do MORE to avoid such failures.

Outsourcing is not cloud computing. Private clouds are not cloud computing.

Thanks to Bob Warfield for writing this guest post.

===============

Articles about Cloud disasters are popular these days. The Cloud is relatively new and people realize they don't know what they don't know. Although Michael's post on Virgin Blue is informative, I disagree with his perspective.

It's all fine and well to wring our hands about another "Cloud" disaster with a "seamy underbelly", but it is more interesting and useful to explore several deeper questions.

The Virgin Blue incident raises broad questions that go beyond the Cloud. For example, how can you perform proper diligence, and prepare disaster recovery and failover options, when a third party substantially controls your infrastructure?

Viewed from that broader perspective, I don't see Virgin's, and many other similar incidents, as Cloud issues at all. I don't even think it is a "Hosted" issue, though that came up as a question in the Enterprise Irregulars' discussion of the Virgin Blue situation, as another fellow Enterprise Irregular, David Dobrin, writes.

I'm coming from a perspective of having dealt with large Enterprise customers who had the software on their own machines in their own data centers, but it was all being operated by so few of their own employees (Accenture or some provider was doing the work) that it may as well have been in a Cloud.  The company employees had very little idea or control over what was going on.

Companies who follow such a course can easily find that have the same problem as Virgin:  the system goes down and a third party was at the controls, did the design, setup the software, yada, yada.  Tell me you haven't seen situations like that?  Heck, I have seen a very prominent SI get thrown out of a Fortune 500 IT account for 2 years over a screw up that cost a lot of money.  That company was not just down for a couple days, it took nearly 9 months to get that project back on track.

There is a seamier side to outsourcing of any kind that has little to do with the Cloud, hosting, or indeed technology in general.  It's already here and breathing down your neck in IT whether you've even lifted a finger to move into the Cloud.

At a very high level, you've got to ask why the Out-sourcer / Cloud-sourcer / SaaS-sourcer will do a better job than you can.  Maybe it doesn't matter because you can't afford to do the job or don't have the talent, but it still does matter in terms of asking why the vendor you pick can do a better job than the others.

Scale and experience matter a lot in that kind of evaluation too.  Many IT departments are faced with doing it for the first time if they do it themselves.  Presumably, your vendor is not.  Scale means they can afford to do things like build multiple data centers with your data guaranteed to be in more than one of them at all times, something that may be prohibitive for a smaller organization.  It means they've had to combat things like DOS and other attacks on a larger scale than your organization may have, though it also means they may be exposed to more of it than you have.

Be that as it may, scale and experience are also not the whole story.  You need to know what decisions they've made on disaster recovery and so on. How do they ensure their people are not looking to steal vital information?

But even after all that is said, and you've done your homework, you are going to be placing yourself in a situation where if an outage occurs (and no matter how good the story is, one will eventually occur), the real problem is that you will feel powerless. You won't have the information about what's going on, the ability to make the decisions, or the ability to individually beat on people to get it fixed that you have when it is your own shop.   That's a psychological factor, by the way, that may have little to do with whether those things matter towards getting past the disaster.

Outsourcing is the ultimate delegation.  You better be sure you hired the right people, because in the end, it is people, not a Cloud that you will have to blame if it fails.

===============

Thank you to Bob Warfield for writing this guest post.