Remoting, Components, and Interoperability

Abstract

As the backwash of technical progress is sucked from the shoreline, it leaves hundreds of little rock pools, each teaming with technologies that are destined to dry out unless habitually supervised by support teams. While writing well-factored, object-oriented code can go a long way to reducing future maintenance costs, the reality is that development shortcuts are often made to reduce initial project costs. This, in effect, saddles an unavoidable burden of debt on system maintenance. Coupling these issues with the personnel factor—the older a system becomes, the harder it is to find staff who are able or willing to work with the technologies of yesteryear—it’s easy to understand why industry analysts suggest that keeping these rock pools filled with water can be significantly more expensive than developing new technologies. And if supporting mature systems wasn’t enough, the need to modernize aging but functional systems, integrate systems from different vendors running on different operating systems, and show at least an inkling of interest in the latest technical fashion are frequently the straws that not only break IT managers’ backs but also rupture their dreams, constipate their sanity, and induce their early retirement.

“If they introduce interoperability without a deal with us, it’s a hack, and it doesn’t really work.”

—Barry Schuler, president of AOL Interactive Services