It's one of those ultimate questions, like the origins of chicken eggs: Does IT drive business or support business? The answer generally defines the attitude of CXO executives when dealing with their respective IT departments, and shapes the way IT is planned, handled and purchased throughout a company. If IT drives business, then you give IT everything they need to get the job done, and a little more just to make them happy. If they need a resource, you supply it. If they recommend a practice to increase efficiency and ROI, you listen to what they have to say. After all, they drive business and increase profit margin.
If IT is support, then the role is very different. The Finance/Accounting/Legal/Production departments are the ones making the money. IT is just there to help them do their jobs better. If Accounting needs something IT-related, IT better be there to support that. They don't have the resources? It isn't efficient? Doesn't matter. Accounting comes first, because they're the one's that drive business. It is the job of IT to make sure that happens. Whatever the cost. If IT recommends a piece of software, but the lawyers don't like the way it looks or feels, conversation over. Lawyers have precedence.
In a survey conducted by the Economist Intelligence Unit, sponsored by SAP, Cisco, and Capgemini, C-Level executives were polled to find out if the goal of their IT departments was cost-reduction (support) or revenue growth (business driver). 61% said cost-reduction and 39% said revenue growth.
Seeing as the corporate world is completely dependent on IT to run their business, and that without the support IT provides, most companies would simply buckle and implode under the weight of thousands of Blue Screens of Death, this discrepancy needs to be ameliorated. With IT quickly becoming the backbone of any successful company, C-level executives need to start understanding the true role of IT, and start taking heed of their opinions and needs.
What causes a company to go either way in this survey? It's a matter of understanding how IT functions. Let's start with the holy grail of IT. The ultimate goal of IT is what the academics like to call the 5 9s. 99.999% uptime. An IT system should work, always, with a fractionally small error rate of .001% coming from freak accidents. Herein lies the power of IT. Ideally, when a system is complete, no work needs to be done to keep that system running. It should be self-sufficient and fool-proof enough that all it needs is some monitoring and periodic updates. There is a whole lot of short-term front end work that goes into it, but the payoff is huge when the five 9s are accomplished. The manhours and cost of implementation are recouped very quickly. Unfortunately, the disadvantage of having a perfect system is that it will always be under appreciated until something catastrophic happens to it.
Let's take network infrastructure as an example. It's a good example because five 9s in a network (by network, I mean the physical network that transmits data through wires and routers and switches out to the Interwebs and back) isn't just a geeky pipe dream. It's considered normal to achieve five 9s in that IT domain. If you ask the average Accountant what kind of knowledge and training goes into designing and implementing a network, they'll probably just give you a blank stare, or maybe say something like knowing what all the wires do. A smart layperson may even throw out a term like IP or subnetting. But if I threw out some things like NAT, routing protocols, EIGRP, RIPv2, CHAP, OSPF, PAP, IpSec, ACL, Token Ring, SAS, Frame Relay, IS-IS, VPN, Kerberos, Spanning Tree, VLAN, VTP, OSI, ISO, IPv6, 10BaseT, plenum, multi-mode fiber, SONET, PAT, static routes, Dijkstra's algorithm, DUAL algorithm, QoS, and on and on and on (I could go on for at least another 20 terms), you might begin to start chipping away at the mountain of knowledge and planning that comprises network design and implementation. And that's just basics. You have to know that stuff (and configure and troubleshoot it all) and a whole lot more just to pass Cisco's entry level network certification.
This is what I'm getting at: A user doesn't check internet connection by checking outgoing and incoming packets for TCP acknowledgements, they just click on internet explorer, and wait for a page to show up. When it doesn't work, they can't get their work done, and they get pissed. So they call IT, and IT fixes the problem. In that scenario, the user had only one interaction with IT, and that was when things broke. In the user's mind, the same guy who carries multiple IT degrees and certifications and spend months laboring on the design of the network, is really just a glorified janitor. When there's a mess, IT is expected to clean it up. This is why a perfect system will never be noticed or appreciated. When IT's interaction with the user base is only when things break, IT becomes support when in reality they should have a more important role.
Enter the CIO. The above case is precisely why the position of CIO was created in large corporations. The "janitors" of IT knew that they were more important than just support and that they needed some clout in upper management to get stuff done. The CIO was supposed to be the experienced IT man who had some serious years of management under his/her belt, enough to be respected by other C-level colleagues. The CIO was supposed to relate the needs and recommendations of the IT staff to the people who needed to hear it but weren't listening. The CIO was also supposed to defend the IT staffers and try to get them some recognition as more than janitors.
Sadly, this only happened in a handful of companies. 69% of companies are still under the impression that IT is around to cut-costs. The CIO position only accomplished so much, and I believe that that position has been abused and misrepresented flagrantly. There are two kinds of CIOs not suited for the job. One is the CIO who doesn't know anything about IT. This guy usually was the CFO or the COO or a VP of some sort, and to make him happy, the board decided to give him governance over the IT department. Since this fellow is purely motivated by his own personal clout and politics, he doesn't care that he knows squat about IT, just that he has more power now. Therefore, he will actually end up crushing IT under the heel of his ego-inflated boot, all in the name of making the C-level executives happy. This CIO makes things worse for IT, because everyone knows that when you want something from IT, no matter how asinine or illogical, the CIO will make IT comply.
The other kind of CIO, not as bad but still not so great, is the kind with very little management experience. He was the IT guy when the company started and now runs the place just because he started it all. The problem with this guy is that while he may defend his people, stick up for them, and even respect them, he will never be able to properly defend the needs of IT to anyone who needs to listen. He will always be the geek in the room, and is still just a support guy. He isn't well-versed in the language of business and his opinion will therefore not be respected.
This leads me to believe that the CIO position is not the solution. In fact, I don't think there is a solution. In an environment where system self-sufficiency is the goal, the face IT will always be the desktop support grunts who clean up the messes users make. As the user experience becomes more streamlined and the backbones of these systems become more complex, the real geniuses in IT will recede even further into the background. The only saving grace is management that really understands the nature and business of IT. This could simply be a matter of time. Eventually, CEOs will have to be versed in IT just like the rest of population will have to be in order to live effective lives.
For now, we'll just do our work, pretend we care about your problems, and hate upper management for being n00bs.