Decomposition and Interfaces

How You Decompose Determines What You See

Every complex system must be broken into manageable pieces for engineering teams to work on. But decomposition is not neutral — the way you cut determines what problems become visible and what problems hide at the seams.

Two canonical strategies exist, and they rarely produce the same result.

Functional Decomposition

Ask: what does the system do? You get functions — propulsion, thermal management, guidance, power generation, structural support. Each function describes a capability the system must provide. Functions map cleanly to requirements because requirements describe what the system must do, not what it's made of.

Physical Decomposition

Ask: what is the system made of? You get components — engine, chassis, circuit boards, housings, cables. Components map cleanly to procurement, manufacturing, and assembly because those activities deal with physical things.

The mismatch between these two views is where engineering difficulty concentrates. A single function often spans multiple physical components (thermal management involves the heat exchanger, the coolant pump, the radiator, and the control software). A single component often participates in multiple functions (an aerospace structural bulkhead provides structural support, thermal isolation, and pressure containment simultaneously). This many-to-many mapping means that functional teams and physical teams will naturally see different problems — and integration is the activity that reconciles them.

Interfaces: Where Integration Fails

An interface is the contract between two subsystems. It specifies what crosses the boundary: data formats, energy flows, physical connections, timing requirements. Interfaces are more important than the subsystems themselves for a simple reason — most integration failures happen at interfaces, not inside components.

A component team can test their subsystem exhaustively and still deliver a system that fails at integration because the interface was underspecified, misunderstood, or changed without notification.

Interface Types

Different disciplines encounter different interface types, but they fall into consistent categories:

• Data / Information: signal formats, communication protocols, data rates, message schemas. Dominant in software and electrical systems.
• Energy / Power: voltage levels, power budgets, thermal loads, vibration transmission. Critical in electrical and mechanical systems.
• Material / Fluid: flow rates, pressures, chemical compatibility, contamination limits. Central to chemical and environmental systems.
• Mechanical / Structural: mounting points, load paths, dimensional tolerances, fastener specifications. Foundational in aerospace and civil structures.

A single interface between two subsystems can involve multiple types simultaneously. The interface between a turbine and its nacelle is mechanical (mounting loads), thermal (heat rejection), electrical (power and signal cables), and fluid (cooling air paths) — all governed by one contract that both sides must respect.

The N-Squared Diagram

For N subsystems, there are potentially N(N-1) directed interfaces (each pair can exchange in both directions). The N² (N-squared) diagram is a matrix with subsystems on the diagonal and interfaces in the off-diagonal cells. Row i, column j contains what subsystem i provides to subsystem j.

This systematic enumeration forces teams to consider every pair. Without it, obvious interfaces get defined (engine-to-transmission) while subtle ones get missed (engine-thermal-effects-on-avionics). The missed ones surface late — and late interface discovery is the single most common cause of integration schedule overruns.

Why Interface Definition Matters Early

There's a persistent temptation to defer interface definition until the subsystems are better understood. This is backwards. Early interface definition constrains the solution space — which is the point. A well-defined interface lets teams work independently with confidence that their pieces will fit together. A deferred interface means teams make assumptions, those assumptions diverge, and reconciliation at integration is expensive.

In digital engineering terms, interfaces are the associations between subsystems. Defining them early means the digital thread captures these associations from the start, making impact analysis possible throughout development rather than only during integration.

Expand both views above. Notice how the functional tree organizes by capability (what the vehicle does) while the physical tree organizes by assembly (what you build). A single physical component like the engine block participates in multiple functions (propulsion and thermal management). A single function like thermal management spans multiple physical assemblies (engine, electronics, cabin). This many-to-many mapping is exactly why interface definition matters.

Assessment