Failure to Launch - Cloudsourcing Can Blow Up On Take-Off

Published: by

Surprise, surprise. NASA's attempt to "go to the cloud" has led to major security gaps. According to a report on TheVerge, an internal NASA review discovered that of its five major cloud sourcing contracts, not even one came close to meeting NASA's own data security practices and standards.

When I was studying for my MBA, we studied the classic Carter Racing case study. The short form: a car racing team has to decide whether or not to race. Most of the time when the weather is below a certain temperature, the engine fails. Today, it is in that range. Do they race or not? If they race and they complete the race, they win big. If they don't race, they lose somewhat. But if they race and the engine blows, their team is abandoned and they lose really big! The question they asked? Under what temperatures does the engine fail? The question they didn't ask? Under what temperatures does the engine not fail? Only when you ask both sides of the question do you actually see how closely engine failure is related to the temperature, and that they should not have raced. The critical lesson is that as often as not it is the inverse question that must be asked.

Carter Racing is particularly relevant, as it was based on a true NASA story... (anyone know?)

I am not privy to NASA's internal review. But the glaring omission here is the question not asked, probably because it wasn't in the review's remit: of NASA's top five existing hosting facilities - internal or external - how many come close to meeting NASA's own data security practices and standards? I suspect the answer is very close to none.

The problem with cloudsourcing is the same problem that has existed for any form of outsourcing from time immemorial. It is the same problem that has existed with automation. Automation doesn't fix bad processes; it makes bad processes fail faster. If you want to automate, you must first fix your processes so that they do the right things, and only then can you automate them to make them faster and more cost-effective.

Outsourcing has always suffered from the same problem. Companies suffering from high internal costs due to inefficient processes and poorly described deliverables try to solve their "cost" problem by outsourcing to lower-cost providers. But their problem, at least their largest problem, never was the cost of their resources; it was the inefficient use of those resources and the cost of constant adjustment and "returns." Outsourcing actually exacerbates the problem, because beforehand, much of the dysfunction is resolved informally through relationships between peers in the different groups. Once you outsource a function, informal resolution and internal relationships do not exist, by definition. Offshoring makes it even worse, since the physical distance, timezone difference and cultural discrepancies amplify the dysfunction.

Does that mean outsourcing or offshoring doesn't work? Of course they do. But you have to fix your internal processes first. You need to get to the point where your internal group is working as efficiently and independently as possible, and only then compare outsourcing. In the simplest form, you need to get to the point of comparing apples to apples, or you will wonder why you ordered 100 apples and received 200 rotten oranges.

Cloudsourcing is about flexibility, but, like all business processes, it is about revenues and expenses. Companies don't cloudsource because it is "cool" or "edgy", or for any other reason. They do it because it saves them money and/or creates new revenue opportunities.

NASA's move to the cloud should have been preempted by first treating their existing hosting solutions as if they were in the cloud, enforcing and tightening their processes until it became an apples to apples comparison.

Unfortunately, optimizing, fixing and cleaning a company's internal processes with existing providers is very hard work. It is extremely hard even to identify where the weaknesses are. I have often seen organizations attempt to outsource out of a (sub)conscious desire to avoid the internal hard work. It has failed, every single time. If you really want to succeed, you need to first clean up internally, and only then evaluate and potentially outsource.