Long-lived systems: technology

By Andrew Clifford

Long-lived systems need to be based on long-lived technology. This often means picking less fashionable options.

The hardware, operating system, programming language, database and user interface of your system has a big impact on how long your system will last. If you choose technology with no future, your system will die with it.

It makes sense to pick popular technologies, because without a large user base no product will last. The history of IT is littered with good technology that never made it commercially. Stick with the big guys such as Microsoft, Oracle, IBM and Sun, and major open source initiatives such as GNU, Linux and Apache.

But being fashionable is not enough. You also have to commit to keeping on current versions, which means you have to choose technologies that can be upgraded easily. Some suppliers make upgrades easy, some make them very hard.

IBM has an excellent track record, in my experience. I started on IBM mainframes, and the COBOL systems I wrote 20 years ago will still run largely unchanged on the latest mainframes and operating systems.

Over the same 20 years, Microsoft has put out half a dozen server and desktop operating systems with varying degrees of incompatibility, has run through multiple incompatible versions of programming languages, data access methods, operating environments, user interfaces, and so on. I never recommend Microsoft for long-lived systems because of the amount of work required to keep current on their technologies.

Most major suppliers fall somewhere between IBM and Microsoft. I have found occasional difficulties moving from one version of Oracle to the next. I was initially sceptical about Java, but it has a strict approach to removing features between releases which works well.

As well as the major technologies, consider the viability of more minor components. The long-term credentials of some of the currently fashionable frameworks, such as Ajax and Struts, are not yet proven.

Standards compatibility helps a lot, as it allows you to interchange products as long as you stick rigorously to the standards. Support for standard SQL lets you swap relational databases, but is meaningless as soon as you use a proprietary extension.

Look out for management barriers to taking upgrades. Large, incompatible upgrades, which attract increased licensing, can turn into a major business decision. Eventually you fall off the upgrade path, which is a death sentence to your system. Smaller, compatible upgrades, which are not connected to licensing costs, are much easier to handle managerially. Free and open source software presents few management barriers to keeping current.

Picking viable technologies is just common sense. You need to balance popularity with a critical assessment of how easy it will be to keep current. You need to look at track record, standards compliance, and management barriers. This rules out the latest fashionable products, and pushes you back to more established, less fashionable ones. We curse ancient COBOL systems, but they can teach us a lot about long-lived technology.

Subscription