Speaking out in support of legacy systems and solutions

Vendors often rely on the tactic to attack legacy systems and solutions in the hopes of replacing them with their own technology. Should enterprise decision makers listen to them?
Written by Dan Kusnetzky, Contributor

I've come here today to support legacy systems and software not to condemn it. I know that many vendors would say that this is heresy, but in this time of cost cutting and outsourcing, it is something that just needs to be said again.

What Vendor marketing folks are saying

Vendor's Marketing folks have long been out to eliminate established systems, software and processes even though they are usually doing what they were asked to do. Why is this?

Enterprises using technology are addressing their business requirements and needs. For the most part, they will continue to use this technology until it no longer serves their purposes. Only when the enterprise decides to leave a specific market or sell a business unit do those systems go dark. On many occasions, those systems continue to do their work, just for the new owners.

Vendors, on the other hand, want these enterprises to purchase their products and services. One of the vendor's time-proven tactics is to declare established systems and tools as "legacy" and urge enterprises to toss them out regardless of whether they are succeeding at the mission assigned to them.

Legacy - a vendor tactic

I can't tell you how many vendor briefings on their products or services begin with a verbal attack on systems and tools already in use at customer and potential customer sites. Mainframes, midrange systems, databases, development tools, security software, storage systems, networking equipment and even power and air conditioning are subject to this unrelenting attack.

Real revenues, real costs

These Vendors go into elaborate detail about the failures of currently installed systems and established processes. They point out that they're expensive, time consuming and complex.

What often goes missing is a discussion of the real costs of a specific technology and the revenues the use of that technology has produced over time. They seldom point out that these IT solutions are solving problems enterprises face and have been built up over a long period of time, perhaps many decades. Oh yes, they seldom mention the costs that can be attributed to the disruption changing out one technology and replacing it with another. They don't mention training costs, costs to re-architect systems, processes and complete solutions.

What are they really doing?

When a vendor relegates something to the Legacy category, they are trying to convince their customers to focus on older technology that is quietly doing its job in the data center and see a problem rather than a solution. The Vendor, of course, is hoping that if they can convince decision-makers that the solution that is in place is really a problem in disguise, they can guide that person down a path to replace the solution with something else.

It would be wise for the decision-maker to stop for a moment, step back and take the time to closely examine what is being said.

  • Is the vendor trying to convince the listener that earlier choices were wrong? Can the decision be really wrong if the installed solution has been quietly supporting the business for all this time?
  • Would the enterprise's limited IT budget be best served by replacing something that is working or building something new that the organization needs?
  • Is the vendor trying to convince the decision-maker that new approaches are too complex or new to be understood and used by the enterprise's own IT personnel? Their real goal is to convince the decision-maker that their own IT people aren't reliable, don't understand today's technology, and, of course should be ignored. Only the vendor's people truly understand what is happening in the industry now.

The Golden Rules of IT should be considered

It would be wise for decision-makers to become familiar with the "Golden Rules of Technology" before jumping to conclusions or believing everything the vendors say.

The following rules are how IT has worked successfully for decades and should be considered even in today's market. Here's a snippet from the post, Reprise of the Golden Rules of IT" that was published here back in 2007.

  1. If it's not broken, don't fix it. Most organizations simply don't have the time, the resources or the funds to re-implement things that are currently working.
  2. Don't touch it, you'll break it. Most organizations of any size are using a complex mix of systems that were developed over several decades. Changing working systems that are based upon older technologies, older architectures and older methodologies has to be done very carefully if the intended results and only the intended results are to be achieved.
  3. If you touched it and it broke, it will take longer to fix and, in all likelihood, cost more than you think to fix. Most of today's systems are a complex mix of technology. If your organization is going to be updating part of that tower of software, be prepared for unexpected consequences and see Rule 2.
  4. Good enough is good enough. Although it would be nice to have the luxury of unlimited amounts of time, resources and funding and be able to develop every conceivable feature, most IT executives know that they are only going to be allowed the time, the resources and the funding to satisfy roughly 80% of requests for new capabilities.
  5. Don't make major changes unless people are screaming! If they're not screaming, see Rule #4, good enough is good enough. If they are merely asking for changes, see Rule 2, don't touch it, you'll break it, and Rule 3, if you touched it and broke it, it will take longer to fix than you think. If they begin screaming, you'll have to do something to respond, just touch things as lightly as possible.
  6. Embrace your "jerkdom." We all know that we have to move forward and help our organization be as efficient and successful as possible. In short we must do the best we can with the resources, the time and the funding available and accept the fact that years from now someone will look at what was done and come to the conclusion (based upon what they know then) that what was done was insufficient in some way or didn't properly forecast future events and requirements.

Do these rules, rules written over a decade ago, still work? The answer is yes.

Editorial standards