Decomposing a Complex System Into Testable Subsystems

When I encounter a design problem too large to hold in one head — say, a solar-powered water purifier for a remote village — I use a technique called **system decomposition**. Decomposition means deliberately splitting the whole system into smaller, named chunks called **subsystems**, each responsible for one well-defined job. In this purifier example I define four subsystems: Power (converts sunlight to usable electricity), Filtration (removes contaminants and physically moves the water), Sensing (measures water quality), and Control (reads the sensors and decides when to switch the pump on or off). The boundary between two subsystems is called an **interface**. At every interface I write down exactly what crosses it: a voltage level, a flow rate, a digital on/off signal. That explicit contract is what makes independent testing possible — the Filtration team can bench-test their membrane with a pump simulator, without waiting for the real Power subsystem to exist. A key insight I always share: the best decomposition is not the only one — it is the one that minimizes surprise across interfaces. If a design change inside subsystem A forces a design change inside subsystem B, the two are **tightly coupled**, which is a warning sign. Good boundaries keep changes local. Here is the hint I give every student: when you draw a subsystem box, ask yourself two questions. First, can I test this box alone by feeding it fake inputs and checking its outputs? Second, if I change something inside this box, do I have to change anything outside it? If both answers are yes-then-no, your boundary is in a good place. One more thing to remember: the pump is Filtration's actuator — it physically moves the water through the membrane. The signal that Control sends to switch the pump on is the **interface** between Control and Filtration. The pump itself belongs inside Filtration, not inside Control.