The Curse of IT Infrastructure

Computerworld - In July, the General Accounting Office published what I consider a rare insight into IT spending. The agency broke down the $26 billion Department of Defense IT budget into the following categories: business systems, $5.2 billion; business infrastructure, $12.8 billion; mission support (including its own separate infrastructure), $8 billion.
Less than half of the total cost is accounted for by the share of spending that directly and visibly supports users. The lion's share goes toward the "infrastructure" -- the hole from whence bugs, disruptions and mysterious failures come.
Here we have an audit confirming what I have seen creeping up on IT for more than 20 years: It isn't the applications but the need to support a costly infrastructure that has been dampening the funding for technological innovation.
You can always get votes for adding another attractive application. But hardly anybody will sign up to support an infrastructure that may be serving customers who aren't paying their way. Selling tickets for seats in fancy rail cars was always easy. Finding money to pay for the track, switches, signal equipment and the fuel depot was always much harder.
The root cause of IT failures and excessive IT costs in large organizations lies in rickety infrastructures put in place one project at a time. What you usually have in large organizations is not a secure, low-cost and reliable infrastructure but a patchwork of connections cobbled together without sufficient funding and rushed to completion without sufficient safeguards.
The currently fashionable approach is to impose centrally dictated "architectures" to cure the pains from incompatible and redundant systems. Such architectures are just another way of achieving order through centralization and consolidation. Unfortunately, under rapidly changing conditions, such a cure may be worse than the original disease.
Invariably, centralization involves the awarding of a huge outsourcing contract to a vendor for whom a critical piece of the infrastructure is carved out, such as the management of desktops. Associated servers, switches and data centers may also be included in the IT territory ceded to the outsourcer, while the resident IT bureaucracy always keeps tight control of a few fatally critical components in order to retain its absolute power.
This approach to fixing infrastructure deficiencies is flawed because the sequence for fixing a broken setup is backward. Contracting for an infrastructure should be the last -- not the first -- step in putting improved systems in place.
First, IT managers should focus on determining which applications must be delivered immediately. The reliability, affordability and timing of application services