Future proofing

By Andrew Clifford

There's no such thing as a future proof IT system. Good design can prolong the life of your systems, but what's really important is that you care and know about the state of your systems.

Over the years, I have often tried to sell advice on the promise that it would future proof the system. Here are some examples.

• Open systems let you change hardware and system software, without the lock-in of proprietary technology.
• Layered architectures let you change one part of a system without impacting other parts of the system.
• Decoupled integration lets you changes one system without impacting other systems.
• Data normalisation lets you extend a database without invalidating what is already there.
• Standards-based programming languages minimise the impacts of new versions, unlike many proprietary languages.

Looking back, I was wrong to think that these could future proof systems. These design decisions help minimise the impact of change, but they are never enough. It only takes one bad decision to mess it up. I used to work with large mainframe systems with well designed databases that could be extended easily. But because the systems were not well modularised, the programs became impossible to change. The good efforts on database design were wasted.

And there are lots of things we just can't design out. A system might fall out of favour with management, and not be maintained. It might be much more successful than originally assumed, and hit dreadful performance problems. Documentation and test packs degrade because of constant maintenance. We can only guess what technology changes will happen a few years from now.

There is a good body of knowledge on Software Evolution that looks into why software declines through time, the impact of this, and how to manage it. There's a lot of good stuff there. But just understanding is not enough.

There are two things you really need to future proof your systems.

• You need to care. Most businesses value new IT projects much more than their existing IT. They presume obsolescence in a few years, and a lack of management attention makes this self-fulfilling. But the opposite is also true. If you believe your systems should last for 20 years, it will drive you to manage them differently, and you have a good chance that they will.
• You need to know. When you are changing a system, you need to know what to do to keep it viable. Whether or not you are changing the system, you have to know how well it now meets the evolving business and technical environment. If you know, you can do something about it.

At Metrici, we have been developing ideas on system governance. System governance captures what's important to you about your systems. It enforces this when you implement or change your systems, so you don't build in obsolescence. It monitors your existing systems to check that they are keeping up with your business and your technology.

System governance gives you a framework that helps you care for your systems. It tells you what you need to know to keep your system viable. You can't future proof your systems. But with system governance you can give them a long and fruitful life.

Subscription