Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 The whole system"]
N2["16.2 Boundaries"]
N3["16.3 Interfaces"]
N4["16.4 Traceability"]
N5["16.5 Change management"]
N6["16.6 Interfaces as risk"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 The whole system"]
N2["16.2 Boundaries"]
N3["16.3 Interfaces"]
N4["16.4 Traceability"]
N5["16.5 Change management"]
N6["16.6 Interfaces as risk"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 The whole system]
|
v
[16.2 Boundaries]
|
v
[16.3 Interfaces]
|
v
[16.4 Traceability]
|
v
[16.5 Change management]
|
v
[16.6 Interfaces as risk]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) treat an application and its pipeline as one system; (2) define system boundaries and interfaces; (3) trace requirements to components; (4) manage change across the system.
16.1 The whole system
ticket-web is not just code: it includes the source repository, CI, artifact storage, deployment, servers, third-party services (payments, maps) and the people who operate them. A weakness anywhere can affect riders. Systems engineering looks at all parts together and at how they connect.
Treating the system as a whole reveals risks that no single team sees. The developers may write careful code while the deployment tool accepts any artifact, or the servers may be hardened while the CI system holds production credentials. Kwame's diagram shows people as well as machines, since an engineer with deployment rights is part of the path from source to rider.
16.2 Boundaries
Kwame draws the system boundary: Coastline controls source, CI, mirror and servers; the payment provider and public registry are outside. Interfaces across the boundary (registry downloads, payment API calls) are where trust must be checked, because Coastline cannot inspect what happens beyond them.
Drawing the line makes ownership clear: inside it, Coastline can inspect, test and change things; outside it, Coastline must rely on contracts, checks and evidence supplied by others. The public registry is a good example: Coastline cannot audit every maintainer, so it checks hashes, mirrors approved versions and watches advisories.
16.3 Interfaces
Each interface has an owner and a contract: what is sent, how it is authenticated, what happens on failure. The registry interface's contract says downloads must match lockfile hashes; the payment interface's says requests are signed and responses verified.
The failure clause matters most and is often forgotten. If the payment API times out, ticket-web must not issue a ticket as if payment had succeeded. If a lockfile hash does not match, the build stops rather than continuing with a warning. Owners update contracts when either side changes and confirm that tests still exercise each clause.
16.4 Traceability
Requirements such as "only reviewed code is deployed" are traced to the components that enforce them (repository branch protection, CI policy, deployment check) and to tests that prove them. A requirement with no traced component is a gap.
The table runs in both directions. From a requirement, the team finds the controls and tests; from a component, it finds the requirements that depend on it, which shows what is at risk if that component is changed or removed. Auditors use the same table to pick samples, so keeping it current saves effort during reviews.
16.5 Change management
Changes to one part, such as a new CI runner, are checked for effects on others. A change board reviews changes to the pipeline itself, since a pipeline change can affect every future release.
The board does not slow ordinary code changes, which go through normal review. Pipeline changes get extra scrutiny because they change how every later change is checked: a mistake in the CI policy could let unreviewed code through for weeks before anyone notices. Each approved pipeline change has a rollback plan.
16.6 Interfaces as risk
Many supply-chain attacks in the Ladisa et al. (2023) taxonomy target interfaces between stages: source to build, build to distribution, distribution to install.
At each handover, one stage trusts what the previous stage produced. If source is altered after review, the build compiles the altered code faithfully. If a build is compromised, distribution publishes the result. If a distribution channel is hijacked, installers receive the substitute. Checks at each interface, such as signed commits, provenance and signature verification at install, break this chain of assumed trust. Coastline's traceability work focuses on these handovers first, since an unchecked interface lets one compromise pass silently into every later stage.
Worked example
Kwame's traceability table finds that "only reviewed code is deployed" is enforced by branch protection, but an emergency hotfix path in the deployment tool skips the check. The team keeps the hotfix path but requires a second approver and an after-the-fact review within 24 hours.
Synthetic case. The system and table are synthetic.
Errors and limits
Large systems change constantly; keep diagrams and tables current or they mislead.
Exercises
- EX046 — System parts. List five parts of the ticket-web system. Rubric: 3 = source, CI, artifacts, deployment, servers, third parties, people (five); 2 = three; 1 = one; 0 = none.
- EX047 — Traceability gap. What does a requirement with no traced component mean? Rubric: 3 = a gap; 2 = partial; 1 = vague; 0 = none.
- EX048 — Hotfix fix. How was the hotfix path handled? Rubric: 3 = second approver; review within 24 h; 2 = partial; 1 = vague; 0 = none.
Synthesis
See the application and its pipeline as one system with owned, checked interfaces.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →