Are you tired of the phrase “perfect storm”?

Me too. But tired or not, one is hitting IT right now. Several interconnected trends are affecting the business world in ways that will … and should … radically redefine IT’s role. Among them:

Cloud 3.0

Cloud 1.0 was playing with cheap or free stuff, notably but not limited to Amazon Web Services. Because Cloud 1.0 services were cheap or free, the IT pundit class concluded Cloud computing was going to be dramatically more economical than owned infrastructure.

Cloud 2.0 consists of (present tense because it’s going strong) important but standalone systems. Salesforce is an example. While Salesforce is integratable, most Salesforce implementations were and are standalone “islands of automation” to use a quaint phrase from a bygone era. Cloud 2.0 wasn’t/isn’t cheap or free.

Cloud 3.0 is serious enterprise-class computing that makes use of Cloud services and architecture. By serious, I mean it has the same characteristics as projects IT is accustomed to dealing with. Cloud 3.0 provides systems that are integrated into the rest of the applications and information portfolio; they make use of the enterprise directory service for identity management; and they’re subjected to the same rigorous software quality assurance and change control protocols as systems that run on owned infrastructure.

IT could ignore Cloud 1.0 and Cloud 2.0. Cloud 3.0? IT will be neck-deep in Cloud 3.0 projects whether it takes the lead or is dragged into them, kicking and screaming.

Shadow IT

Shadow IT isn’t so much a second, separate trend as it is the flip side of the Cloud coin.

Gartner has famously predicted that by 2017, marketing departments will have bigger IT budgets than IT departments and marketing isn’t the only department outside IT that buys information technology independently. Sales is an obvious example, routinely signing contracts with Salesforce.com without asking IT’s permission first (see Cloud 2.0, above).

Here’s what’s rarely mentioned: Companies have invested large amounts of time, effort, and political capital developing IT governance processes. Depending who you ask and after how much beer, this is either because companies want to gain maximum business advantage from their investments in information technology, or because business executives don’t trust IT do anything other than play with the latest and greatest shiny ball unless the rest of the business supervises it closely.

So here’s the question: Given that Marketing doesn’t, in most companies, have a strong reputation for tight cost discipline, does anyone really think CEOs are going to give Marketing, or any other department for that matter, a free rein when it comes to its non-IT IT spending?

Me neither.

The digital enterprise

Okay, okay. Yes, this is one of those so-visionary-it-might-be hallucination buzzphrases. Except that, shorn of its buzzphrasey trendiness there’s a lot of current reality behind it. In particular, there’s the rise of smart products that don’t keep their smarts to themselves — products that constantly collect data and communicate it to what I sure hope we soon stop calling “big data” repositories through what I hope even more we stop calling “the Internet of things.”

From IT’s perspective, this is a big, big deal, because …

Back in the day, most companies that sold technology products kept internal IT and product-development IT separate. Merge them and either the company would soon consist of nothing but cobbler’s children as product development sucked all of the priority out of internal support projects, or products would become second-rate as internal priorities had the opposite impact.

That worked when product IT and internal IT had no technological point of contact.

But smart products that send data to internal databases for use in customer support and marketing analytics are seriously smudging the line separating internal and external IT.

Politically, CIOs might win biggest by sitting this dance out, watching product development, marketing, and customer service duke it out in the silo wars, then riding in as the white knight that can pull it all together. After all, most business executives value solutions much more than they value prevention.

Another reason to wait on the sidelines: The most obvious organizational solution for all this — a dramatic expansion of central IT — would look like empire building should you propose it.

But waiting on the sidelines is the opposite of leadership.

Fortunately, there’s a better solution. Unfortunately, we’re out of space for this week.

So stay tuned.

* * *

Six years ago I published one of the most important columns I ever wrote — “The portal,” describing a better way to think about personal computers, although if I wrote it today I’d add tablets and smartphones.

And eighteen years ago, in InfoWorld’s “IS Survival Guide,” I took my first shot at the difference between productivity and effectiveness.

Here’s something to celebrate: Saturday, NASA’s Opportunity rover celebrated the tenth anniversary of it’s landing on Mars and it’s still going strong, even though its planned mission life was only three months.

This isn’t a fluke. Cassini, an international collaboration managed by NASA that originated in 1982, launched in 1997, entered orbit around Saturn in 2004, and completed its planned mission in 2008. It’s still going strong.

Then there are the two Voyager probes, the Curiosity rover, the Chandra orbiting X-ray observatory … what’s interesting about NASA projects is that these sorts of spectacular successes have become ordinary.

Unlike, say, the Department of Health and Human Services (HHS), whose most noteworthy large-scale projects in the same span of years — those would be Medicare Plan D and Healthcare.gov — were, shall we say, challenged.

As pointed out in this space when Healthcare.gov’s problems became newsworthy, using Healthcare.gov, and for that matter challenged state exchanges like Minnesota’s MNSure, as evidence that “government can’t do anything right,” is just plain ridiculous. If that was the case, NASA’s string of successes would have been a string of failures, NASA being a part of the federal government and all.

Were we to conclude that the Department of Health and Human Services should never be entrusted with a large-scale project, we’d at least have a sample size of two on our side. But even then, other than the joy we all experience when we’re able to point our fingers at someone else to say, “Aren’t they just awful?” there’s nothing interesting about a conclusion like this.

It gets interesting when we ask what the difference is between NASA and HHS. There are two. The first is that, following two embarrassing missions to Mars that failed, NASA decided to find out what it was doing wrong, and to fix it. It commissioned an in-depth investigation and took the results seriously.

Following Medicare Plan D and Healthcare.gov, the investigation, if that’s the proper term, came from a Congressional committee. Even if we eschew (gesundheit!) the easy, snide comment, there’s still an obvious contrast to be drawn: NASA’s investigation was led by experts in managing large programs. Congressional investigations are run by elected representatives, whose nearest equivalent of a large program is a re-election campaign.

So that’s the first difference. The second, and more important one, is that NASA is in the big projects business. Big projects … missions … are what NASA does for a living.

HHS is, in contrast, in the operations business, and it’s actually quite good at it. For example, Medicare’s administrative overhead is either one or six percent of total expenditures, depending on whether the metric includes the administrative overhead of the private contractors the Medicare program uses. For comparison, the Affordable Care Act establishes a ceiling of 18% for health insurers, a restriction that created quite a stir in the industry.

The point being that HHS isn’t in the large projects business, so it shouldn’t be all that surprising that it isn’t very good at them.

We can go deeper than that. The leadership, management, and cultural traits that make an organization good at operations are in many respects antithetical to those that make an organization good at project management.

Operations is about keeping things the same. Think of a factory and you get the picture: the job is to do the same thing over and over again, in very much the same way, so as to minimize variation and incremental cost while maximizing throughput.

Operations planning is all about matching capacity and staffing to anticipated demand. It’s a day-to-day thing.

Projects are about making things different. Project planning is all about figuring out what the tasks are to change things or build something new, how they have to be sequenced, who is best equipped to take each one on, and how long they should be expected to take.

Operations tasks, that is, are known because they’re repeated over and over again. Each project task is, in contrast, in some respect unique. They’d better be, because each one would have already been done by someone else. The project should use that result instead of creating an identical copy.

Operations never finishes. No matter what gets done today, we’ll do more of it tomorrow. Projects, by definition, are supposed to end.

I am oversimplifying. NASA is also in the operations business. Otherwise there wouldn’t be anyone around to receive all the data its successful missions keep sending back to Earth.

Interestingly enough, it doesn’t describe things that way. Its operations are considered part of the mission, and while missions may be extended, they’re never considered eternal.

There’s always an end date.