What Is a System?

Parts, Relationships, Purpose

A system is not a collection of parts. A pile of engine parts on a workbench is not an engine. What makes it a system is the relationships between parts and the purpose those relationships serve. The crankshaft connected to the pistons connected to the combustion chambers, arranged to convert chemical energy into rotational motion — that's a system.

This distinction matters because it determines what you pay attention to. If you think in parts, you optimize components. If you think in systems, you optimize relationships. Digital engineering operates on the latter — forming associations across information streams means forming associations across the relationships that define the system.

System Boundaries

Every system analysis begins with a boundary decision: what's inside the system, what's outside (the environment), and what crosses the boundary (inputs, outputs, interfaces). This sounds straightforward. It isn't.

Consider a chemical reactor. If you draw the boundary around the reactor vessel alone, the heat exchanger is an external input — you treat its output as a given. If you draw the boundary around the reactor-plus-heat-exchanger, the heat exchange becomes an internal dynamic you must model. Same physical plant, different boundary, different analysis, different conclusions.

The same choice arises in every discipline. A civil engineer analyzing a building foundation can include or exclude the surrounding soil. Including it means modeling soil-structure interaction — a far more complex but more accurate analysis. A software architect can draw the service boundary to include or exclude the database. Include it and you own the data model; exclude it and you depend on an external contract.

Boundary placement is an engineering decision, not a physical fact. The right boundary depends on what questions you're trying to answer, what you can control, and what level of fidelity you need. Move the boundary outward and you capture more interactions but increase modeling complexity. Move it inward and you simplify the analysis but risk missing critical couplings.

Inputs, Outputs, and Interfaces

What crosses the boundary defines the system's interface with its environment. Inputs are what the environment provides: energy, materials, information, commands. Outputs are what the system delivers: products, waste, data, signals. Interfaces are the contracts that govern these exchanges — the specifications that both sides must respect.

In practice, poorly defined boundaries create poorly defined interfaces, and poorly defined interfaces are where integration failures live. If two teams disagree about where the boundary sits between their subsystems, they'll disagree about who owns the interface — and that disagreement will surface as a defect in integration testing, not in design reviews.

The Hierarchy of Systems

Systems nest. A gas turbine is a system. It's also a subsystem of the aircraft propulsion system, which is a subsystem of the aircraft, which operates within the air transportation system. Each level has its own boundary, its own interfaces, and its own emergent behaviors. Effective systems thinking means working at the right level for the decision at hand — and knowing when to zoom in or out.

Expand and collapse the subsystems above to see how a smart building decomposes into interacting layers. Notice that the Building Management Controller depends on data from the Sensor Network, which in turn monitors the HVAC and Lighting systems. The hierarchy is not just organizational — it reflects real data and control flows.

Assessment