Resistance to change is rooted in many factors from fear of the unknown to resentment of forced mandates. Oftentimes, the underlying resistance lies in the sheer magnitude of the challenge. Many enterprise IT projects are massive undertakings with big payoffs when they succeed and huge downsides when they don’t. What follows is a situation routinely encountered at large firms and often results in an outpouring of change phobia.
It’s common to find companies using many legacy software applications running on outdated hardware. Those systems are frequently powered by old mainframes or minicomputers sold by IBM, DEC, DG, Wang, HP or Honeywell. Often these ancient beasts are interconnected in such a fragile manner that changing anything, anywhere, results in unintended consequences.
The people that developed the systems are usually long gone — laid off, retired or off to better situations. The technical documentation is usually sparse and outdated. The procedures for operating the systems are brittle and must be followed carefully and precisely.
Sounds like an accident waiting to happen, right?
Faced with such complexity, many IT departments freeze. They lock down everything to prevent change. They try to extend the life of the systems for as long as possible. Eventually, either the business folks get fed up with the lack of technological progress or hardware failures become overly disruptive and intolerable.
Is there any way out of this mess?
The biggest fear factor in these situations stems from the size of the problem. Overhauling major enterprise systems is a huge undertaking by any measure. First, ask yourself what it’s costing the company not to change. Old systems are expensive to maintain and service. In addition, the business may not be able to leverage modern cost efficiencies putting profit margins under stress.
The cost of doing nothing might be much more than you think and might even outweigh the cost of replacing those relics. Time to move on? There are really just two options for moving forward and they both carry significant, but manageable, risks and costs.
- Select a production system to be replaced. Build a parallel system that will ultimately take over all of the functions performed by the older system. Operate both systems for a brief period of time to give everyone a chance to get accustomed to the new software. Once you’re convinced that the new system does everything it needs to do, decommission the old system.
- Decompose the legacy system into its major component parts, for example, database, batch processing, user interface, etc. Replace one major part at a time by building a new component and connecting it to the remaining legacy components via a software wrapper or emulator. Repeat until the entire legacy system has been replaced.
Neither approach is necessarily more agile, lower risk or lower cost than the other. The most important message is to get started. You can’t finish if you don’t start.
In my next post, I’ll offer a few guidelines for approaching these types of projects in an agile way.