* The risk inherent in legacy systems
If non-mainframe legacy systems are likely to go away quickly, it might not mean much that there are a few lurking in the data centers. But what if there is no plan in place for their replacement?
We ask IT executives about platforms they support in their production systems, and get results you might expect: lots of Windows, less Linux and Unix, a sprinkling of “legacy” systems and mainframes. The exact numbers shift over time (Linux waxes, Unix wanes) but they don’t tell the whole story, because often data center managers and others aren’t telling us the whole story.
Sometimes, though, they do go into the gorier details, and what they say is no surprise to anyone who has run a data center that has been in operation for a long time. Hidden within “legacy,” or sometimes simply not mentioned, is a surprisingly large world not just of old mainframe code but also of many other platforms that were at some time important to the business in question – or, and this is where things have really gotten ugly for some large companies, any system that was ever important to any other company the big company bought or merged with.
If these non-mainframe legacy systems are likely to go away quickly, it might not mean much that there are a few, or a few dozen, lurking in the data centers. But what if there is no plan in place for their replacement? If the applications are not on deck for rewrites or migration?
When the policy is a “let sleeping dogs lie” averted gaze, then the data center has to cope with the consequences. Those consequences include added complexity, of course, which in turn draws down disproportionate amounts of IT resources. Options for such things as single sign-on with strong authentication and automated, agile management will be severely limited the more such systems there are.
This problem is difficult to resolve because it can be hard to show a return on migrating ancient long-used applications to less ancient platforms as long as they are still doing their jobs. The arguments to marshal for change should be broad, based not just on inefficiency and complexity in IT operations, but also on risk. Risk is the means by which to link those operational difficulties to the larger business.
The CIO should point to the business risk of the fragility of older systems: the older they get, the less likely it becomes that they will have any vendor support, either for hardware or software, or that IT will be able to stock spare parts, or keep skilled support techs on staff. The CSO should lean hard on the risk to the business based on security – if the system is running on an older version of Windows, for example, it may be especially vulnerable not only because of the unpatched and unpatchable OS problems ,but also because of application code that may simply be unsecurable.
The CIO and the CSO should both lean hard on the compliance argument, if it applies: Can the enterprise determine that the systems are in compliance in how they manage information or authenticate access to it? If they are not in compliance, is it even possible to bring them up to speed?
Such arguments don’t always work. Sometimes the stocks of aftermarket spares are large, or the fines for being out of compliance are small relative to the cost of replacing the systems. In such cases, IT can explore second-best solutions, techniques for at least mitigating the risks, such as using newer systems to wrap the old ones, or moving the old systems (if possible) onto virtual machines.
It is crucial, though, that leadership both in IT and outside it know and accept the trade-offs involved. Although the Sword of Damocles (not the kind of blade server we want!) will be hanging above IT, it’s not IT alone that suffers if the sword should fall.
