Conceptual IntegrityBy Bruce F. Webster | Posted 2008-07-24 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce 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.
Fred Brooks set forth the compelling need for a chief software architect more than 30 years ago, arguing for the essential quality of conceptual integrity within a given software system. The role I’m proposing is more of a conceptual clearinghouse for all systems currently in production.
The maintenance architect would have the responsibility of learning—and documenting, if necessary—the essential architecture of all production systems, with a special focus on their interdependencies and interfaces. He or she would have to review all proposed changes to those systems or their operating environments (hardware, operating system and so on), including retirement or replacement of a given system. This architect would then issue an “environmental impact statement,” listing all the significant potential or actual repercussions and costs of the proposed bug fix or feature addition. This impact statement does not need to be lengthy or complicated, though it may well be. It would be circulated to the engineers responsible for the affected systems, as well the business stakeholders for those systems.
This is clearly not a simple or a “make-work” position. It requires—or would development—a significant technical breadth and depth. It would also have a real impact on the enterprise’s IT budget by allowing a better approximation of the true cost for a given change in a given system. Equally important, it would help to avoid the cascading chain of errors that often occurs when a fix or an improvement is hastily (and often silently) slipped into production.
This role would be a great training position for chief software architects. Someone who has spent a year or two in this position would have a tremendous understanding of the existing enterprise technical architecture. He or she would also have a great appreciation for the interconnectedness of systems and the often-large and sometimes-intractable consequences of seemingly small decisions regarding software architecture, design and implementation. Most important, the maintenance architect would keep all these production systems in mind when developing a new program, lowering the barriers to integration and deployment.
Almost as important, since this job would be seen as the fast track to becoming a software architect—the most prestigious job in software engineering—you’d have your best and brightest IT engineers competing to fill that slot. If your enterprise is large enough, you might even want to make this a team of two or three maintenance architects. That would make it easier to deal with the vast IT production infrastructure; it would train more software architects; and—if you stagger promotions in and out of the group—it would maintain continuity and ease knowledge transfer.
So, if your organization is spending more than 50 percent of its IT budget on maintenance, give serious consideration to setting up this position and staffing it with an outstanding IT engineer—the position will likely pay for itself within the first 12 months. And if your organization is spending less than 50 percent of its IT budget on maintenance, look around carefully—there’s a good chance that you’ll find someone who is, in effect, filling this role already.
Bruce F. Webster is a consultant specializing in reviewing and rescuing large-scale IT projects. You can reach him at email@example.com or via his Web sites at brucefwebster.com and bfwa.com.
©Bruce F. Webster 2008