What Is a System and Why Do We Care?

We hear the word “system” used quite often in the media, in discussions, and, if we are technically-oriented, related to our work. But what is a system, really? Why should we care about a definition of the term?

In common usage, we can be casual about what a system is (although this can lead to issues), for example, a school system or a healthcare system. However, if you are engineering systems or, equivalently, performing systems engineering, then you absolutely must care what a system is and what a system is not! Note that we are distinguishing “engineered systems” from other types of systems such as “natural systems.”

In this post, I want to examine what a system is and what it is not. This will become important for subsequent posts, which assume a working understanding of the term. We’ll start with an “official” definition according to the International Council on Systems Engineering (INCOSE) and use that as a basis for a different, more formal definition. From there, we will start to look at how the definition is operationalized and can eventually lead to more mathematically formal considerations such as reasoning about the system from an architectural, complexity, governance, or failure perspective.

The INCOSE Official Definition

Officially, INCOSE defines a system as “…an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements.”¹ So we see that there are things that interact with a purpose and those things can include a variety of entities. There is quite a bit in this definition to understand. However, I want to approach it differently by reducing this definition down to a minimal structure which we can operationalize.

A Minimal Structure Definition

We can reduce the official definition to a more fundamental level by identifying that systems consist of

Elements: identifiable constituents
Relations: structured interactions among those elements
Boundary: a distinction between what is “inside” the system and what is “outside”
Purpose or function: intended or emergent behavior

If we were to remove any one of these, then we no longer have a system

Without elements: no substrate
Without relations: no structure
Without boundary: no identity
Without purpose: no evaluability

What you should know about this intentionally minimal definition is that it is structural and not procedural. We haven’t said anything else about the system, just what it is. There are other things related to systems engineering that follow from this definition but we will discuss those later.

To presage future discussions, at this point I want to declare some more formal definitions. In the minimal definition we can make the following identifications

A system is a tuple where
- $E$ represents elements
- $R \subseteq E \times E$ represents relations²
- $B$ represents a boundary operator inducing a partition between internal and environmental variables
- $\Pi$ represents the purpose as either an objective function or performance criterion³

With this minimal structure definition in our pocket, let’s revisit a concept I introduced upfront which was a distinction between engineered and natural systems. Based on this structural definition an engineered system is teleological (externally imposed design), while a natural system is teleonomic (apparent goal-directedness via selection).

The Boundary: What is It?

One of the concepts above frequently overlooked in conversations about systems engineering is the nature of the system boundary. It’s easy to think of the boundary as a physical thing – a container of components, a building, etc. However, systems exist for which physical boundaries are non-existent. To incorporate this, we say that a system boundary is not necessarily a physical thing, rather it is a modeling decision.

When we define a system boundary, we

Select what is treated as internal variables
Declare what constitutes environmental inputs/constraints (what is outside of the boundary)
Establish what we control as system designers

This is epistemological in nature and not metaphysical. The physical world does not have pre-labeled system boundaries, much as we might desire that. So boundaries become modeling commitments connected to the system’s purpose.

Different stakeholders will draw different boundaries around the same physical reality, i.e., the system. For example, a propulsion engineer, a program manager, and a regulatory agency may define the “system” differently.

This matters because we often see conflict arising from these mismatched boundaries or misalignment of the boundary definitions. This will be important later.

Hierarchical Structure and Decomposition

If we consider it long enough, we can see that systems exist at multiple levels of abstraction and scale. A propulsion subsystem is itself a system. An aircraft containing a propulsion system is a system. The enterprise designing and producing the aircraft also constitutes a system. We can even extend this to say that the regulatory ecosystem governing certification of aircraft systems can be considered a system.

This leads to an important observation:

Systems are compositional

Systems may contain subsystems which themselves satisfy the minimal definition. Likewise, a system may be embedded within a larger system. Another extension of this concept is a System of Systems (SoS) in which the elements are systems that can have identity independent of the SoS to which they belong. This is an extension that we will not spend much time with but it’s worth mentioning since it is a system but the relationship between the SoS elements is somewhat different and this affects how we engineer and manage such systems.

Formally, the compositional nature is represented by

$S = (E,R,B,\Pi)$

then there may exist subsystems

$S_i = (E_i, R_i, B_i, \Pi_i)$

such that

$E_i \subset E$
$R_i \subset R$
Boundaries $B_i$ are nested within $B$ (Note that we don’t represent this as a subset because that would imply that parts of the boundary of the subsystem are a part of the system boundary)

However, the purposes $\Pi_i$ of subsystems need not, and often will not, align perfectly with the larger system purpose $\Pi$ .

This is not just theoretical. It is one of the most common root causes of system failure.

Subsystem optimization does not guarantee system optimization!

Organizational units, disciplines, or stakeholders may define boundaries and purposes differently. When those internal purposes diverge from the overall system objective, structural tension emerges. This tension may remain latent, or it may surface as schedule slips, cost growth, technical debt, program/project failure, or operational failure.

We will revisit this idea when we examine governance, architecture, and failure mechanisms more formally.

For now, though, just observe that a system is not just structure, it is structure in service of purpose bounded by a modeling decision.

Up to this point, we have treated the system as an objective structure. However, engineered systems are not purely physical constructs. Every engineered system simultaneously exists in two domains

The physical domain with hardware, software, energy, signals, other materials
The cognitive domain as the mental models of the various stakeholders, including the system designers

Failure frequently occurs, not because the physical system fails (it might), but because the shared mental model collapses. When teams no longer agree on

What the system is
What its purpose is
Where its boundary lies

then coordination deteriorates. We will see this observation become central later as we discuss

Consensus formation
Cognitive divergence
Representational fidelity
Architectural debt

Systems Are Structured, Not Merely Complicated

We have seen, then, that a pile of components is not a system. We impose structure on that pile of components via interfaces, constraints, control relationships, and allocation of responsibilities. Then, structure determines behavior. Changing the structure changes the emergent properties of the system: often in a dramatic way! We will discuss this further when we start to examine architecture in the next post. I intend to show that architecture is not just documentation or pretty pictures in a binder. It is structural control!

Emergence and Evaluation

Just as a pile of components is not a system, a system’s behavior is not reducible to its elements alone. Behavior emerges from the relations. This is a key insight and affects

How integration risk can dominate component risk
How coupling predicts fragility and brittleness
Why change cost grows nonlinearly with increased structural entanglement

Later, I will formalize this via measurable constructs such as

Coupling metrics
Change propagation cost
Complexity growth indices

But note that the foundation is here: emergence arises from relational structure.

A Working Definition

Finally, we have enough context to establish a good working definition. For our purposes then

A system is a bounded set of elements and relations organized to achieve a purpose, whose behavior emerges from its structure and whose operational identity in engineered contexts depends on sufficiently aligned stakeholder mental models.

Note that this definition includes structure, boundary, purpose, emergence, and cognitive agreement. The cognitive agreement clause is deliberate because in practice, loss of shared understanding often precedes failure.

A Bridge to Architecture

In the next post we will start discussing architecture. For now, though, note that if a system is defined by structured relations within a boundary for a purpose, then architecture is the deliberate specification of that structure. Architecture determines

Allowed interactions
Coupling patterns
Allocation of responsibilities
Degrees of freedom for change

Thus, the point of this post is that we need to understand what a system is to be able to discuss architecture responsibly.

The next post will examine where architecture sits within systems engineering and why confusion here results in governance failures.

Footnotes:

Introduction to Systems Engineering ↩︎
We are simplifying by representing the relation as a binary relation but in many engineered systems, relations are n-ary, typed, directed, weighted, and/or dynamic (time-dependent). We will generalize this later. ↩︎
We are representing the objective function as a single objective, but engineered systems often have multiple, competing objective functions. ↩︎