Featured Featured

From Systems Engineering to System Family Engineering

Virtual

Virtually all systems engineering is performed in the context of a product line – a family
of similar systems with variations in features and functions. Hardly anyone builds just
one edition, just one flavor, just one point solution of anything. When presented with
this hypothesis, the initial reaction from systems engineers is often disagreement.
However, when pressed for examples where organizations build a complex system
without deriving from an existing similar system and without the intent of building
other similar systems, examples are not readily forthcoming.

Because of the inherent assumption in the system engineering community that systems
engineering is primarily a methodology for building a single system, systems
engineering methods and tools have traditionally focused on how to build the
individual point solutions within a family rather than how to engineer a system family
as a whole. This mismatch comes with significant risks. A recent study by the analyst
firm Tech-Clarity, involving surveys of nearly 200 company leaders engineering
products and systems, the number of product and system configurations is largely
viewed as the top and growing source of complexity, which results in one of their top
two business challenges. Engineering complexity slows progress and leads to defects,
errors, and omissions, which in turn leads to the business risks of delays, budget
overruns, recalls, system failures, and opportunity losses.

When systems in a system family are engineered as individual point solutions,
techniques such as clone-and-own, branch-and-merge, and reuse repositories result in
ever-growing duplicate and divergent engineering effort. Trying to manage the system
family commonality and variation among these individually engineered systems relies
on tribal knowledge and high bandwidth, error-prone interpersonal and document-
based communication among different subject matter experts. Furthermore, when each
engineering discipline adopts a different ad hoc technique for managing variations
among the members of the system family, the result is error prone dissonance when
trying to translate and communicate across the lifecycle.

Share