Welcome back. In the previous lesson, you defined a system boundary, distinguished the system of interest from external systems and environmental influences, and used a context diagram to make that scope visible. That boundary now gives us a place to look inside: not merely at a list of elements, but at how they are arranged, connected, and collectively behave.
This lesson develops four closely related ideas: hierarchy, interactions, interdependencies, and emergence. These are central to INCOSE-style reasoning and to later MBSE work in Cameo. A model that lists blocks but omits their meaningful relationships is not yet a useful system model.
By the end, you should be able to read a practical scenario and identify: the level of hierarchy being discussed, the relevant interactions, dependencies that may create system-level risk, and behaviors that arise only from the whole system in its context.
A system is more than its inventory of parts
A component list is often necessary, but it is never sufficient. A refrigerated vehicle, a driver, a temperature monitor, a dispatch process, and a receiving clinic do not automatically constitute a functioning vaccine-delivery service merely by existing in the same region.
They become a system when their relationships are organized to deliver a purpose: transporting and handing over viable vaccines within specified conditions.
SEBoK emphasizes this shift from parts to wholeness. Read the two short sections below before continuing.
Read SEBoK's “Concepts of Systems Thinking” to establish the systems-thinking meaning of interaction, hierarchy, and emergence. It provides the vocabulary used throughout this lesson.
In the section “Wholeness and Interaction,” read from the argument for wholeness. Focus on why interactions can matter as much as the elements themselves. Then go to “Hierarchy, Emergence and Complexity.” Read the hierarchy discussion. Notice the distinction between increasing variety, reducing variety, and the idea that higher-level behavior arises from combinations of lower-level behaviors.
The following SEBoK map is useful as a vocabulary reminder. It is a map of concepts, not the architecture of one particular engineered system.
A practical systems thinker repeatedly moves between two questions:
- What elements make up this system at the chosen level of abstraction?
- What relationships among those elements produce the observed capability, limitation, or failure?
The first question supports decomposition. The second restores the whole-system view.
Hierarchy: systems within systems
A hierarchy organizes a complex system into levels. At a given level, an entity can be treated as one coherent whole; at a lower level, it can be decomposed into its constituent elements and their relationships.
For the vaccine-delivery example, one possible hierarchy is:
| Level of abstraction | Example entity | What is emphasized |
|---|---|---|
| Regional health-service level | Regional vaccine-delivery service | Delivery capability, coverage, service performance |
| Operational-system level | Transport and delivery operation | Dispatch, transport, handover, temperature assurance |
| Subsystem level | Temperature-monitoring subsystem | Sensing, recording, alerting, communication |
| Element level | Sensor, controller, display, power supply | Specific physical or software elements |
A key point for an exam scenario is that the same entity can be a system at one level and a system element at another.
For example, the temperature-monitoring subsystem may be a system of interest when its developer is analyzing calibration, power use, and alarm behavior. But in the wider vaccine-delivery service model, that same monitoring subsystem is only one internal system element.
Hierarchy is not the same as organizational reporting
Do not confuse a system hierarchy with:
- an organizational chart;
- a budget or ownership structure;
- a physical location;
- a manufacturing bill of materials;
- a sequence of work steps.
A driver may report to a fleet manager while being modeled as an internal element of an operational service. A maintenance provider may be owned by the same organization but remain an external enabling system if it is outside the selected delivery-service boundary. Conversely, a sensor located inside a vehicle is physically contained within it, but it also participates in functional and information relationships extending beyond the vehicle.
A useful hierarchy tells you what contains what for the purpose of the model. It does not, by itself, explain behavior. For that, we need interactions.
Interaction: what elements do to and with one another
An interaction is a relationship in which one element affects, exchanges with, controls, constrains, or responds to another. It may involve information, energy, materials, forces, authority, timing, or human action.
In the vaccine-delivery service, consider these interactions:
- The temperature sensor provides measurements to the monitoring controller.
- The controller evaluates those measurements against configured limits.
- The controller presents an alarm to the driver or sends an alert to dispatch.
- Dispatch changes the delivery plan in response to the alert.
- The driver may inspect the refrigeration unit, protect the shipment, or proceed to an approved contingency location.
- The receiving clinic accepts or rejects the delivery based partly on the temperature record and handover procedure.
None of these elements can be understood properly in isolation. A sensor’s accuracy matters only in relation to the controller’s interpretation, alarm thresholds, data timing, calibration procedure, and the decisions made when an alarm occurs.
Interfaces are visible interaction points, but not the entire relationship
The previous lesson introduced interfaces: locations where defined exchanges cross a system boundary or connect internal elements. Interfaces are important because they make interactions explicit and testable.
However, not every important relationship is captured by a single connector or message. Consider these less obvious interactions:
- A driver’s training affects whether an alarm is acted upon correctly.
- A maintenance schedule affects the reliability of the refrigeration system.
- The routing algorithm affects how long the vehicle is exposed to high ambient temperature.
- Clinic receiving hours constrain dispatch decisions.
- A shared cellular network affects both location reporting and alarm notification.
These are interactions because a change in one element or condition can influence the behavior or performance of another.
In Cameo, connectors, ports, item flows, activities, and state transitions can represent different kinds of interactions. At this stage, the important discipline is semantic rather than diagrammatic: name the elements, specify the relationship, and identify what effect it has on the system purpose.
Interdependency: when a relationship creates reliance
An interdependency is more than the existence of an interaction. It means that an element’s ability to perform, or the system’s ability to meet an objective, relies on another element, condition, resource, or decision.
A simple distinction is useful:
| Term | Core question | Vaccine-delivery example |
|---|---|---|
| Interaction | What is exchanged or affected? | The monitor sends a temperature alarm to dispatch. |
| Dependency | What relies on what? | Dispatch relies on timely alarm notification to coordinate a response. |
| Interdependency | How do multiple elements mutually or collectively constrain one another? | Monitoring, refrigeration, driver response, communications, and delivery schedule jointly determine whether vaccine viability can be assured. |
Dependencies may be one-directional. The display depends on electrical power; the power supply need not depend on the display to generate power.
Interdependencies are often reciprocal or networked. For example, dispatch needs reliable location and temperature data to make sound decisions. Yet the value of those data also depends on dispatch having an approved contingency plan and the authority to direct the driver. The monitoring technology, operating procedure, and human decision process therefore constrain one another.
Hidden dependencies are a frequent source of system failure
A team may verify each individual element and still encounter a system-level problem because it failed to recognize a dependency. Common hidden dependencies include:
- Resource dependencies: shared power, bandwidth, storage, fuel, spare parts, or staff time.
- Timing dependencies: one action or message must arrive before another decision can be made.
- Information dependencies: an actor requires complete, current, correctly interpreted information.
- Control dependencies: one element must be authorized or configured before another can act.
- Environmental dependencies: performance relies on temperature limits, road access, positioning signals, or available infrastructure.
- Life-cycle dependencies: installation, calibration, maintenance, training, and disposal affect operational performance.
For instance, a temperature-monitoring unit can meet its laboratory accuracy requirement while the overall assurance process fails in operation. The battery may be replaced late, the clock may be misconfigured, an alert may be delayed by lost connectivity, or a driver may not have a practical response procedure. The system failure is not necessarily “the sensor failed.” It may be a failure in the network of dependencies that turns sensor data into a safe operational outcome.
This is why systems engineering examines interfaces, procedures, support systems, and operating context together.
Feedback, delays, and structure-driven behavior
Interdependencies become especially important when an effect eventually influences the condition that produced it. This is feedback. In practical systems, feedback often includes delays, incomplete information, or competing goals.
Watch this short MIT OpenCourseWare segment for a systems-thinking explanation of why actions should not be considered in isolation.
System Dynamics: Systems Thinking and Modeling for a Complex World
In “System Dynamics: Systems Thinking and Modeling for a Complex World,” MIT OpenCourseWare introduces feedback, delayed effects, and the need to choose a purposeful system boundary.
Watch feedback and delay. Focus on the claim that a decision can affect other parts of a network and later influence the original decision context. Then watch defining a system. Note the practical need to establish a boundary based on the system objective rather than attempting to model everything.
Consider a simplified operational pattern:
- An increase in delivery exceptions increases the time dispatchers spend resolving problems.
- Reduced time for proactive route planning can increase the likelihood of future delivery exceptions.
- The effect may not be visible immediately because the workload, schedules, and corrective actions accumulate over days or weeks.
The engineering lesson is not that every system requires a formal system-dynamics model. It is that repeated behavior often reflects underlying structure: interfaces, rules, resource limits, information delays, incentives, and feedback. Blaming an individual operator may miss the actual system condition that made an undesirable action likely.
Emergence: behavior at the level of the whole
Emergence describes a behavior, capability, or property that arises from the organized interactions of system elements. No individual element possesses the whole-system behavior on its own.
In the delivery case, “maintaining a viable cold chain from warehouse release to clinic acceptance” is not a property of:
- the refrigeration unit alone;
- the sensor alone;
- the driver alone;
- the dispatch function alone; or
- the clinic alone.
It emerges from their coordinated behavior under real operating conditions.
SEBoK uses synergy, or weak emergence, for the idea that the whole can have greater variety or capability than the isolated parts. In engineered systems, this is usually not mysterious. It should be understandable, modeled, and verified. But it cannot be determined merely by inspecting a list of components.
Emergent behavior can be desirable or harmful
Emergence is not automatically beneficial.
Desirable emergence might include reliable end-to-end temperature assurance: monitoring detects a deviation, communications convey it, procedures guide a response, and the service protects the shipment before viability is lost.
Harmful emergence might include false confidence: all local indicators appear satisfactory, but a combination of an overdue calibration, a delayed alert, and a rushed handover permits compromised vaccines to be accepted.
The following service-system view makes the distinction between internal structure and wider dependencies visible.
Read this diagram carefully:
- The Product Systems cluster is a nested system within the larger service system. That is hierarchy.
- The links among service management, people, product systems, and enabling systems indicate interactions.
- The involvement of delivery organizations, clients, regulations, and natural conditions reveals dependencies that extend beyond the immediate product.
- Reliable service delivery is an emergent result of the entire arrangement, not an inherent property of any one oval.
A practical recognition method for scenarios and models
When faced with a scenario, do not begin by hunting for a diagram type. First read for structure.
1. Identify the level
Ask: What is the system of interest at this moment? Then identify what is one level above it and one level below it.
If the scenario focuses on the temperature-monitoring subsystem, the vehicle may be external. If it focuses on regional vaccine delivery, the monitoring subsystem is internal.
2. Identify the relationships that matter
Look for verbs and conditions such as:
- sends, receives, controls, monitors, authorizes;
- supplies, consumes, shares, constrains;
- schedules, delays, triggers, inhibits;
- trains, maintains, repairs, configures.
These often reveal interactions and dependencies that a component list conceals.
3. Test the consequence of loss or change
For each important relationship, consider the effect of it being unavailable, late, incorrect, overloaded, or misunderstood. This exposes whether the relationship is merely incidental or system-critical.
4. Look for a whole-system outcome
Ask whether the behavior described belongs to an individual element or requires coordinated relationships among multiple elements. If it requires the latter, you are likely dealing with emergence.
5. Preserve both decomposition and holism
The following SEBoK reading captures this balance: systems engineers separate concerns to manage complexity, but must integrate their views to retain understanding of the whole.
Principles of Systems Thinking
Read the relevant SEBoK material to connect hierarchy and interaction with the practical need for multiple, consistent views of a system.
Start with the table at the beginning of the page. Compare the principles named “Holism,” “Interaction,” “Layer Hierarchy,” and “Relations.” Then read the “Separation of Concerns” section, beginning with the nested-system framing. Continue through the paragraph beginning the explanation of views. Focus on why structural and behavioral views must remain separate enough to be understandable, yet integrated enough to describe one coherent system.
In Cameo terms, a Block Definition Diagram can help communicate hierarchy and composition, while Internal Block Diagrams can show parts, ports, and connectors. Requirements, activities, states, and parametric relationships add further views as the model matures.
One caution: the broad engineering idea of a dependency is not identical to every use of the formal SysML «dependency» relationship. Model a formal dependency only when it expresses the intended semantics. More generally, make the real reliance visible through composition, interfaces, allocations, constraints, traceability, and behavior models as appropriate.
Key takeaways
A hierarchy structures systems into levels of abstraction. An entity may be a system at one level and a system element at another.
An interaction is an exchange or influence among elements or between a system and its environment. A dependency exists where successful performance relies on another element, resource, condition, or decision. Interdependencies form networks, often involving feedback and delay.
Emergence is a system-level behavior or property produced by the organized interactions of elements. It can be beneficial, such as an integrated delivery capability, or harmful, such as a failure that appears only when individually adequate elements operate together.
The practical habit is to examine both what the system contains and how its relationships create outcomes. In the next lesson, you will use that habit more actively: applying holistic systems thinking to identify life-cycle consequences that a proposed system change might otherwise overlook.
Can't find a good explanation? Sign up and we'll make it for you
Sign up