Long-lived systems: decoupling

By Andrew Clifford

Systems that are clearly separated from each other live longer than systems that are coupled.

If two systems are coupled, then change in one system forces change in another. All too often the forced change is carried out in a hurry which undermines the structure and documentation of the system and reduces its life expectancy.

It works the other way too. Sometimes we need to rework a system to keep it running smoothly, but the impact on other systems is just too great and we do not bother.

Heavy coupling means you can not change one system without changing every system. It forces you into major redevelopments every few years. It stops you making the small, timely changes that can keep systems running indefinitely.

Coupling occurs when you connect systems, but of course you do need to connect systems to get them to work together. To keep systems decoupled, limit the knowledge that one system has of another to only the interfaces that they share. This gives you the freedom to change the internals of any system without affecting others.

There are many dimensions to decoupling.

• Technology. Any system should be free to change its technology without affecting others.
• Time. Any system should be free to change when it runs without affecting others. Sometimes two systems have to work at the same time because they co-operate in a single activity, but each system should degrade gracefully if the other is not running.
• Data. Any system should be free to change its internal data without affecting others.
• Process. Any system should be free to change its internal processing without affecting others.
• Location. Any system should be free to relocate without affecting others.

You can achieve a high level of decoupling by making decoupling a priority when you connect systems. See Minimal integration for some ideas on this.

Look out for other, subtle forms of coupling.

• Co-location. Often two or more systems are run on the same server to save costs. This creates subtle coupling because the systems are based on a shared environment. You can not change one system without risking an impact on the others. Server virtualization (where multiple server instances run on one physical server) allows you to run each system on its own server instance. This gives you many of the cost savings of a shared environment and the separation of different servers.
• Data integrity assumptions. Systems often make assumptions about the data in other systems, for example assuming a shared product listing. But this is a subtle form of coupling, and shows itself as inflexibility in changing scheduling and recovery arrangements. Removing the assumption of data integrity between systems by handling exceptions gracefully will help you make the incremental changes that you need to keep systems forever young.

Heavy coupling is a death sentence to systems. It is much harder to retrofit decoupling than to design it in. If you want long-lived systems, always make decoupling a high priority in design, and never give in to short-term pressures to bypass good decoupling discipline.

Subscription