Controlling IT Costs: Using a Maintenance ArchitectBy Bruce F. Webster | Posted 2008-07-24 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
If your organization is spending more than 50 percent of its IT budget on maintenance, give serious consideration to setting up a position and staffing it with an outstanding IT engineer.
Software rots over time.
Of course, it doesn’t literally decompose, but it often becomes fragile, harder to support and more likely to break when something else in the enterprise’s IT environment changes—another application, the hosting platform and operating system, a third-party product with which it communicates, a database schema.
When a defect is fixed, or new functionality is added, it is usually done with the least possible analysis and effort and without much consideration for the secondary implications of the changes. That, in turn, makes the next defect or request for functionality even more difficult to handle, and so on.
Compounding the problem is the unpleasant truth that software engineers typically view maintenance programming as an unpleasant and unrewarding task. As such, the work is often left to two groups. The first comprises entry-level programmers, who have to “earn” their way out of maintenance and onto new projects.
The second comprises less-than-stellar IT engineers, who have—consciously or not—become the resident experts on one or a few legacy systems. By so doing, they have worked themselves into a niche that their peers don’t want, but that still provides value to the enterprise. In some cases, members of the first group become members of the second group without ever leaving software maintenance tasks. The general effect is often a slow but steady decline in the overall quality of the software being maintained.
This effect is compounded by the ever-growing number of software systems being maintained, as well as the new ones being created or installed. The interdependencies among these systems, direct or indirect, can be myriad; a fix or change in one system (or its hosting environment) can have a ripple effect throughout several other systems. Fixing those can in turn generate new ripples, and so on. In those cases, the resulting patches are often even more of a kludge than the original fix. In a phrase, the software rots.
Collectively, these are the reasons why so many large organizations spend a significant portion of their IT budget—usually well over half—on IT maintenance costs. But there is, I believe, a solution: Appoint a maintenance architect.