The problem isn't always where you're told to look

Everything works.

The software responds. The sensor measures. The data flows. The unit tests pass.

And yet the system isn’t working properly.

The natural reflex is to look for which component is faulty.

What if none of them were?

A system is not the sum of its parts #

Breaking a complex problem down is excellent engineering. It lets you isolate, measure and validate each function.

But it has a limit: the behaviour observed at system level can come from the interactions between its components, not from any one component taken in isolation.

Systems engineering is precisely about those relationships: interfaces, dependencies, sequences, physical constraints, timing, environment.

INCOSE speaks of emergent properties to describe phenomena that appear at system level without being present in any of its parts taken separately.

A sensor can be perfectly compliant with its specification. So can the software that uses its data. So can the communication between them. And their combination can still produce an incorrect result.

Look for the cause, not the culprit #

Faced with this kind of problem, asking “which component isn’t working?” can close the analysis down too early.

A more useful question is often: “what conditions have to be met to produce the behaviour I’m observing?”

You’re no longer looking for a culprit straight away. You’re reconstructing a causal chain.

That sometimes means crossing several domains: software, electronics, mechanics, radio, signal processing, networks — or simply human behaviour.

It’s often at the boundaries between these domains that assumptions become invisible.

• Data considered reliable may only be reliable under certain conditions.
• A latency that’s negligible on its own becomes critical in a full sequence.
• Two compliant components can hold incompatible interface assumptions.

Test the relationships #

The consequence is very concrete.

Testing a system’s components separately validates the components. It doesn’t necessarily validate the system.

You also have to test the interfaces, the sequences and the end-to-end behaviour. This is exactly why systems-engineering practices distinguish verifying the elements from their integration and the validation of the complete system.

When a technical project seems stuck despite individually functional components, keeping on improving each of them can be exactly the wrong strategy.

Sometimes you have to stop looking at the parts. And start looking at what happens between them.

Perspective 02 — next Monday: A working PoC doesn’t prove you have a product.

Sources #

• NASA — Systems Engineering Handbook, Product Integration & Verification/Validation.
• INCOSE — work on emergence and complex systems.