In "Why Things Bite Back," Edward Tenner talks about the unintended consequences of technology. Football helmets were supposed to protect players; instead, they armed them with metal hats to launch into one another, and injuries skyrocketed. The desktop computer was going to give us a paperless office; instead, it made word processing trivial and we now use more paper than ever.
That's because technology is part of a cycle. The tools we can use change what we can do, but at the same time, what we do changes the tools we can use. Technology isn't static, much as IT professionals would like it to be, and we live in a world of constantly changing expectations.
Consider, for example, IT in the 1990s. Procurement and provisioning took months, and even a single server was above the threshold of an individual employee's expense report. That introduced friction--in the form of time, since it wasn't worth a month-long order for a one-week campaign, and in the form of money, since it was a hassle to deal with budgeting.
Cloud computing has lubricated both of those obstacles, letting a business user spin up a machine in a day and pay for it on a consumption basis. Public clouds make this process even easier. I've spoken to many "shadow IT" developers who work outside the central IT organization, expensing cloud costs until their application has traction, at which point they simply make IT an offer it can't refuse: "Run my app. It's mission-critical and driving sales."
Most CIOs have, by now, lubricated their processes. This has unintended consequences, though, and wise CIOs will consider them:
• A move up the stack. With time and money obstacles removed, business users are now bumping into a complexity obstacle. There's little value in their managing the individual machines, setting up servers, and dealing with patches. That means they're going to ask for services instead of servers. They want to write code, test, launch, and iterate without worrying about scale or availability.
• A move to analytics. Without the friction that slowed innovation, CIOs will soon face application sprawl. With a dozen initiatives, running on public and private infrastructure, CIOs will have to decide which one wins. And they'll make those decisions using analytics: Which applications are most profitable, most adopted, most resilient?
• Bigger, more frequent spikes. Developers are learning to build for cloud infrastructures, just as they learned to code for multi-core processors. That means the next version of their application will scale up and down opportunistically, taking control of as many machines as possible for less and less time.
So what can a CIO do to anticipate these changes?
First, start looking at services and getting developers to code to them. Giving coders an API for sending mail, or storing images, or quickly searching time-series data, means they won't build their own version. This is good because central IT can get economies of scale (and skill) by centralizing common functions like these. That also means looking at private platforms as a service, and post-SQL tools like Hadoop, sharding, and shared-nothing, eventually consistent data storage.
Second, start collecting usage data to become more data-driven. The ROI analysis before launching a costly project might be fading, but the review once the application has been running needs to become much more disciplined.
Third, factor bigger, more frequent usage spikes into your capacity-planning equations, using them to evaluate backplane, storage, and WAN architectures as well as the tradeoffs between public and private architectures.
Ultimately, today's private clouds built on virtual machines are a stepping stone. There's no doubt click-and-drag is better than rack-and-stack, but now that the line of business has a taste of what's possible, the demands have only just begun.
Alistair Croll, founder of analyst firm Bitcurrent, is conference chair of the Cloud Connect events. Cloud Connect will take place in Santa Clara, Calif., from Feb. 13 to 16.