Of the rest, a lot will go into tablets -- a technology that's (1) fun, (2) personal, and (3) integrated, but not very much. Mostly, we're talking about the email, directory and calendar systems, and that integration will be part of the 10 percent growth going to IT -- if IT is lucky and the CIO is politically adept.
That leaves big data/NoSQL for the rest. And NoSQL poses a problem for a lot of IT professionals.
The NoSQL challenge
Relational database management technologies and the data normalization techniques associated with them aren't just tools used for certain kinds of jobs. The RDBMS is baked into the IT culture by now -- it's How We Do Things Around Here.
It should be -- when the job is transaction processing. When it isn't, data designers have, over the past few decades, developed a number of techniques for finessing the shortcomings of this meat-and-potatoes technology. It's How We Do Things Around Here.
But these are finesses rather than elegant solutions. Enter the hugely countercultural family of technologies known as NoSQL.
InfoWorld's Andrew Oliver wrote an excellent snapshot of various NoSQL technologies a few weeks back. In it, he explained the sorts of data design challenges each of them addresses.
The missing piece: Data design challenges are one thing. Business situations are another, and I've yet to run across a clear, concise explanation of what business challenges each NoSQL technology is optimized for, let alone a clear account of what the complete packages look like that let you load data into them, then process it so as to address those challenges.
How this NoSQL challenge shakes up IT
More to the point from where you sit as an IT professional: If your CIO were to ask you to explain how your company might take advantage of NoSQL technology -- of the business challenges the company faces, which NoSQL datastore could help address them and how, and what would be required to integrate that NoSQL technology into the rest of the enterprise technical architecture -- could you answer the question?
If so, good for you. My guess, based on the informal contacts and conversations I've had on the subject, is that fewer InfoWorld readers can than can't, and InfoWorld's readers are more sophisticated than most on average.
If you're among those who can't, you have two alternatives. One is to keep on doing what you've been doing and hope someone else gets the question. That is, you can hide behind the herd and hope a different antelope gets picked off.
Or as W.C. Fields once said, you can take the bull by the tail and face the situation: You can approach your boss and explain what NoSQL is about. You can also state that, right now, not only does your IT organization lack competence in NoSQL, it doesn't have enough knowledge to say what competence might look like. In other words, you don't know what you don't know.
Propose to fix this -- to do the research, thinking, and planning needed to figure out which ones might matter to your company, why they might matter, and what it would take to bring them in and integrate them. You'd like four hours a week for a month to invest in this research, which would potentially be highly beneficial to the company, not to mention for your career.
If IT doesn't make this investment somehow or other, here's what will happen instead: A business executive -- the CMO, perhaps -- will get a sales pitch from a company that "does NoSQL" or hear a speech from one at a conference. He'll sign a contract with them to bring it in and make it happen.
They'll do it. Part of making it happen will be dumping tasks into the IT request queue (the integration parts), at which point any delays will lead to IT being blamed for the resulting overruns in the NoSQL project.
All in all, getting ahead of the game seems better, don't you think?
This story, "NoSQL: Shadow IT that could sink you," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.