Chapter 16 — Systems engineering
Lesson map
Lesson 16 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Lifecycle view"]
N2["16.2 Interfaces and dependencies"]
N3["16.3 Trade studies"]
N4["16.4 V&V planning"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Lifecycle view"]
N2["16.2 Interfaces and dependencies"]
N3["16.3 Trade studies"]
N4["16.4 V&V planning"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]
[Learning outcomes]
|
v
[16.1 Lifecycle view]
|
v
[16.2 Interfaces and dependencies]
|
v
[16.3 Trade studies]
|
v
[16.4 V&V planning]
|
v
[Engineering note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) apply a systems lifecycle to a multi-year migration; (2) manage interfaces and dependencies across organizations; (3) use trade studies; and (4) plan verification and validation from the start. It builds on Chapter 14 and prepares requirements (Chapter 21).
16.1 Lifecycle view
A port-wide migration spans concept (why and what), requirements, architecture, implementation, integration, verification, validation, operation and retirement. Lifecycle standards such as ISO/IEC/IEEE 15288 describe these processes. Cryptographic migration differs from most system changes because it touches every interface at once and because partners outside the organization must change in step.
For BPA, retirement is a real phase: RSA keys and certificates must be withdrawn and old algorithms disabled once every partner has moved, otherwise downgrade paths remain open indefinitely. Planning retirement from the start, with a target date per interface, keeps the programme from ending with both old and new algorithms permanently enabled.
16.2 Interfaces and dependencies
BPA depends on shipping lines (VPN peers), the customs agency (export formats), vendors (appliances, HSMs, crane firmware) and browser makers (TLS clients). An interface control document lists, per interface, the current algorithms, the target, who must change and by when. Dependencies explain schedules better than effort estimates.
For the customs export, the control document records RSA-OAEP today, CMS with ML-KEM-768 as target, the customs agency as the party that must change first, and a date agreed in a joint letter. A dependency like this sets the schedule regardless of how quickly BPA's own developers finish their part.
16.3 Trade studies
A trade study compares options against weighted criteria. For BPA's VPN: (a) hybrid IKEv2 with ML-KEM now, (b) wait for vendor native support, (c) add a pre-shared-key layer as an interim mitigation. Criteria: security gain, availability risk, cost, partner readiness, standards conformance. Weights come from requirements, not preference.
Fixing weights before scoring stops a team from adjusting them to favour the option it already prefers. BPA's team publishes the weights in the requirements review, scores each option independently, and then checks whether a modest change in any weight would change the winner. If it would, the result is recorded as close, and the decision cites the deciding factor explicitly.
16.4 V&V planning
Verification asks "did we build it right?" (requirements met); validation asks "did we build the right thing?" (stakeholder needs met). Plan both before implementation: for example, verify that the VPN negotiates ML-KEM-768 or stronger in every tunnel, and validate that shipping-line operations continue without delay.
Verification here is a log query: every tunnel's negotiated algorithm is recorded and any tunnel without ML-KEM-768 or stronger fails the check. Validation needs the shipping lines' operations staff, who confirm that document exchange times and connection setup are unchanged after cut-over. Writing both checks before implementation ensures the logging needed for verification is built in.
16.5 Worked example
The trade study scores option (a) highest on security and standards, (b) highest on availability, (c) as a cheap interim. Decision: (c) immediately for the two highest-value partners, (a) in a pilot with one partner, (b) for others when vendors deliver — documented with review dates.
Each option has a review date so the decision does not freeze: the pilot is reviewed after three months to decide whether (a) can extend to more partners, and the interim pre-shared keys are rotated and checked at the same time. Writing these dates down turns a compromise into a plan that moves forward.
16.6 Common errors and limits
- Planning migration as an internal project when partners must change too.
- Trade studies with weights chosen after scoring.
- V&V invented after deployment.
Partners own half of every external interface, so a plan with only internal tasks will stall at the first VPN or export format. Weights chosen after scoring make the trade study an argument for a decision already taken. V&V invented after deployment usually lacks the logs needed to verify anything, as the tunnel algorithm check showed.
Engineering note
Systems engineering also asks when to stop. A migration has an exit criterion per interface — for example, "classical-only negotiation below 0.5% of tunnels for 90 days and partner confirmation received" — after which the old path is removed rather than left as permanent fallback. Without exit criteria, transitional configurations become permanent, and the organization carries both the old risk and the new complexity. Record exit criteria in the interface control document so that progress reviews can close work packages objectively.
Exercises
- EX031 — Interface list. Draft five rows of BPA's interface control document. Rubric: 3 = current, target, owner, date for each.
- EX032 — Trade study. Score the three VPN options with explicit weights. Rubric: 3 = weights justified before scoring; sensitivity noted.
Synthesis
Migration is a systems problem dominated by interfaces and partners; trade studies with prior weights and early V&V planning keep decisions defensible.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →