The parts are worth more than the whole

Some number of years ago, I would attend computer fairs. There was a particularly nice one near Trenton, NJ. The fair had a large flea market with people selling old, used hardware (and some software). Just about anything would be available, from PC parts to old eight-inch floppy disk drives to telephone equipment to minicomputer line printers... lots of things.

One of the most frustrating things was looking at old hardware that had been built for a specific system configuration. The device (whatever it was) would have various connectors; some for data and some for power. These connectors were not standard but custom, used only by that device (and the thing to which it attached).

Such custom connectors may have made sense -- perhaps there was no standard, or the standard did not meet the needs of the system. Or perhaps the manufacturer used a non-standard connector to lock customers into their hardware. Whatever the reason, the non-standard connectors effected the components when the system was decommissioned: they were unusable.

In contrast, the IBM PC used standard parts (the IBM PC set a new standard, but it was adopted by the industry) and parts, when a system was decommissioned, were still usable. When one upgraded from an IBM PC to an IBM PC-AT, one could swap in the old video and accessory cards. One could keep the display monitor, and the printer. The parts had value after the system lost its value.

Software systems have similar behavior. Software systems are built with components and layers (or so the pretty architecture diagrams lead us to believe) but these "components" often have the equivalent of the custom connectors of the old one-system-only hardware. Such custom components can be used within the system, but when the system is decommissioned, the components cannot be used elsewhere. Thus, when the system is decommissioned, the value of the components drops to zero. A component that can be used by one and only one system has no value outside of that system.

A good system architect will see not only the system but the components, and ensure that the components (as well as the system) have value. That means that the components must use standard APIs and be able to stand alone, so other systems can use them. A re-usable component must accept data in a reasonably neutral format, not one that is specific to a system or one that uses obscure object types. A re-usable component must run with a minimal number of dependencies, not the entire system. A re-usable component must be tested independently of the one system, to ensure that it can be run independently of the one system.

Building re-usable components helps retain value of software, and also retains value of people. Re-usable components can be used in other systems. (By definition.) Using components in other systems leverages the knowledge of the development team across multiple systems. In the long term, this can reduce your staffing costs.