Long-lived systems: design

By Andrew Clifford

Long-lived systems do not just happen, they are designed that way. Long-lived design involves keeping things simple, and being risk-averse to the point of paranoia.

Long-lived design is common sense, but we rarely do it. The key to long-lived design is to assume that everything within and around your system will have to change. Nothing, not even your system, will stay unchanged.

Reduce the impact of change by decoupling your system from all other systems. Make no assumptions about the technology, data, location, processing or timing of any other system, except for defined flows of data and control. Do not take a short cut because your system is "short term" or the other system is "strategic". Be paranoid: your system or any other system could change tomorrow, or last for ever.

Do not expose the internal structure of your system to other systems, but do decouple the main internal parts of your system from one another. Clearly separate data, processing and user interaction. Base the interfaces between these on well-established standards. For example, communicate with your database using standard SQL - do not use proprietary access methods or extensions.

In longevity terms, not all designs are created equal. Client/server designs are particularly brittle. They require a strong coupling between the client software and the client machine, and a very chatty interface between the client and the server which is difficult to decouple. A simple web-based design is likely to be much longer lived.

Often your design will include commercial off-the-shelf (COTS) products as part of the system. Use established standards to integrate these, rather than the proprietary methods of the COTS product. This makes it easier to swap to another COTS product if you need to.

When designing decoupling (between your system and other systems, or within your own system), use established standards. It makes sense to encapsulate interface access points so that interfaces can be changed easily, but simple hand coded programs are usually best. Do not write your own decoupling framework.

As well as decoupling, design your system so that it can be clearly owned. If any part can not be clearly owned, it will not have the clarity of direction and decision required to keep it current. Designing architectural layers (such as "web servers", "application servers" and "databases") that are shared by multiple systems means that nobody can properly own the systems. It is OK to physically share hardware or server instances, provided that the systems within them are clearly separated and can be clearly owned.

Lastly, remember that every part of your system will have to be changed. Chances are, it will be changed by someone who is not half as clever as you. If you keep things simple and standard, they will do a good job and keep the system in good condition. If the design is too sophisticated, they will mess things up and condemn the system to early retirement. Simple design is long-lived design.

Subscription