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.