What modernizing IT really means

Resolve the culture clash between business and IT, and you're halfway to bringing your IT operation into the modern era

What sends IT people into paroxysms of fear and loathing? The CIO -- or maybe even the CEO -- calls a meeting. After some throat clearing come the fateful words: "I've just read a Gartner report on [fill in the blank]. And here's what I think we should do..."

As voice is given to this big new priority, the blank expressions of the IT managers sitting around the table hide the furious calculations kicking into gear. What would be the minimum level of effort to get this done? What is the risk to my career if I say we don't have the bandwidth? If we do it, how will it affect the truly important stuff, like keeping the lights on after my budget has been ripped to shreds?

[ Cut straight to the key news for technology development and IT management, with our once-a-day summary of the top tech news. Subscribe to the InfoWorld Daily newsletter. ]

So goes the dysfunctional relationship between business management and IT. Business seldom seems to know what it's asking for, while IT lacks insight into what business drivers may be behind such proposals. To modernize IT, you must start by repairing that relationship.

Let's begin the healing process by banning forever the odious phrase "business-IT alignment." All it means is that IT should snap to it when a powerful business stakeholder wants to build something or cut costs or jump on some new trend -- without regard to the totality of the whole current operation. This "just say yes" approach has resulted in the mess many IT organizations now find themselves in, with siloed systems and applications maintained by separate staffs that the enterprise can no longer afford to maintain.

The business side has no business telling technologists how to build things or ramming through IT initiatives borrowed from analysts. Good IT begins with good business leadership and clear communication of business priorities. If there's a realistic sense of the current state of the business, what it's good at doing, and where it wants to go, then you have the underpinnings of a sound enterprise architecture right there.

That realization is the first principal in modernizing IT. But how you interpret those specific goals and priorities is critical. If you hard-code systems around a granular set of goals and priorities, you're screwed, because these things change constantly, especially in volatile economic times. IT management needs to work with business management to gain an intuitive sense of all the core business functions and how they are likely to be extended -- and build an agile architecture around all that, with the assumption that change never stops.

So the technical aspect of modernization is all about baking in "agility," which is just a fancy word for lowering the level of effort for change. Server, storage, and desktop virtualization all promise a more agile infrastructure (although the management tools to really reap the benefits are just emerging). Meanwhile, many organizations are modularizing the applications that handle core business functions, so those components can be shared across applications. Outside that core sphere, new lightweight solutions that reduce levels of effort beckon -- cloud computing apps, scripting languages like Ruby on Rails, mashups for non-critical projects, and so on.

Making such technology decisions and embracing agility is a process that never ends. Modernization adds a new time dimension to cost-benefit analysis: Not just assessing the value of individual projects, but of building and rebuilding an agile IT foundation of shared services over time, upon which may be launched any number of projects, which in turn can be managed together at a much lower level of effort than a bunch of one-off efforts.

So how does modernizing repair the relationship between business and IT? Well, if you build the agile architecture right, you start by modeling it on indivisible business functions. It begins with a vision that recognizes continuous change, but also provides a shared framework for what business and IT together can and cannot realistically do. Inside that framework IT can say "yes" to projects and incur much lower levels of effort than before. Outside that framework, everyone at the table can see the impact of big ideas that come out of left field -- and decide in a rational way whether they're worth the time and expense.