Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
24 April 2007

Long-lived systems: change

By Andrew Clifford

Change is inevitable. Long-lived systems must be insulated from change, but must embrace change when the time is right.

Business constantly evolves, and changes to business processes and requirements force change on IT systems. Even if your business is stable, changes in your business partners will force change on you.

Technology constantly improves. You need to upgrade to the latest technology to give you the capacity and performance to meet growing business needs. You need to keep on supported versions, and that means you have to keep upgrading all your technology in step. Suppliers fail, and their products need to be replaced.

There is a never ending need to comply with new rules, both external regulations and internal standards and policies.

You can reduce the impact of change. Decoupling stops changes in other systems affecting your system. You can pick technologies that make it easy to stay current. You can design your system to evolve elegantly. But eventually your system will come under pressure to change.

For long-lived systems, the rule is simple. Change as soon as the requirement is clear. Keep up to date. Do not leave it until later. Your system may cope elegantly with, say, out-of-date technology or data differences, but this is not a reason to let your system slip behind. It is an opportunity to keep your system up-to-date even if other systems are not so flexible.

When you are updating your system, do a proper job. Do not just tack add-ons to the code, but refactor the code as if it had been designed to work in the new world. Change the documentation. Change the test packs.

Sometimes systems are not changed because it is not "justified". This is wrong thinking. You can not justify maintenance in the same way that you can justify projects. There is no obvious payback for many changes. Instead, you have to consider the cost of not making the change. If you do not keep a system up-to-date, the system will die and will need to be replaced prematurely. Your fifty thousand pound upgrade needs to be compared with a two million pound replacement.

Some find that keeping up-to-date is unacceptable because it is expensive and disruptive. I understand this, but avoiding maintenance is not the answer. If keeping up-to-date is too expensive or disruptive, put more priority on managing system life span, decouple more, select technology more carefully, design more carefully. This lets you keep up-to-date at low cost, with little disruption. Using cost and disruption as excuses for letting systems fall behind is completely irrational because the cost and disruption of not doing so are much higher.

To keep up-to-date, you need to understand when and where change is needed. Although it is easy enough to look at one factor (like database version) on one system, it is hard to keep an eye on everything across all your systems, all of the time. Next week I will cover what measurement and monitoring you need to identify when and where you need to change.

Next: Long-lived systems: monitoring


To subscribe to the newlsetter, simply send an email to
Privacy policy

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Try it for free!

Find out more