Decomposition, Aggregation & Model Views

Decomposition replaces one hard question about a whole with coordinated questions about parts and their interactions. Aggregation moves the other way: it replaces many detailed variables with a smaller macro description. Both are transformations of a model, not facts about where reality naturally divides.

flowchart TD
  S["Order-fulfilment system"] --> I["Intake"]
  S --> P["Payment"]
  S --> F["Fulfilment"]
  S --> N["Notification"]
  P -.->|"authorization result"| F
  F -.->|"inventory reservation"| I
  N -.->|"delivery state"| I

The tree answers “what is contained?” The dotted cross-links answer “what can defeat independent reasoning?” A decomposition without interaction edges is an inventory, not a system model.

Choose the decomposition axis #

The same SoI can be partitioned by:

• physical components;
• functions or transformations;
• behavior and modes;
• information and authority;
• lifecycle stages;
• geography or deployment;
• ownership and responsibility;
• failure containment zones.

No single tree preserves all of these. A physical sensor, for example, participates in measurement, diagnostics, safety and maintenance views. Forcing every concern into a containment hierarchy either duplicates the sensor or hides a cross-cutting relation.

Use a viewpoint to state the concern, stakeholders, notation and consistency rules for a view. A view is then one representation built under that viewpoint. “Architecture diagram” is not a viewpoint unless it says what question the diagram answers and which relations it intentionally omits.

The cut creates interfaces #

Every cut transfers complexity to interfaces. For each child model, define:

• responsibility and invariant;
• inputs, outputs and side effects;
• units, reference frames and semantics;
• ordering, capacity, delay and timing assumptions;
• allowed states and error behavior;
• ownership, versioning and validation evidence.

If two submodels can be solved independently only by assuming a value supplied by the other, record the coupling and iterate or solve jointly. Hiding that dependency does not make the modules independent.

Aggregation and information loss #

An aggregate variable $z=h(x)$ maps detailed state $x$ to a lower-dimensional description. The aggregation is adequate only for a specified question. Mean queue length may predict storage consumption while hiding the tail distribution that determines user latency. Average power can size energy use while hiding peak current that trips protection.

Aggregation is closed when the macro state evolves without needing discarded detail:

$$z_{k+1}=F(z_k,u_k).$$

Often no such exact $F$ exists. Then the macro model needs error bounds, stochastic closure, additional state or a restricted operating domain. Test it against detailed simulations or observations specifically at regimes where heterogeneity matters.

Consistency across views #

Views are useful only if their shared claims reconcile. Maintain explicit correspondences:

A model repository is not consistent merely because all diagrams open in the same tool.

When to stop decomposing #

“Elementary component” has no universal meaning. Stop a branch when:

1. the decisions assigned to that branch can be made;
2. its external contract is precise enough for integration;
3. critical behavior and failure modes can be verified;
4. further detail would not change the parent conclusion at required fidelity;
5. ownership and evidence are available.

Continue when an unexplained residual, unsafe state, disputed responsibility or sensitivity to hidden detail could change the decision. Different branches may stop at different depths. Symmetric diagrams are less important than justified fidelity.

Decomposition buys tractability; aggregation buys economy. The price is the interaction and information each transformation discards. Good systems work accounts for that price explicitly.