Chapter 20 — Security architecture and engineering: engineering context | Engineering Security architecture and engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 20 — Security architecture and engineering: engineering context

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Regulatory and contractual context"]
  N2["20.2 Stakeholders and constraints"]
  N3["20.3 The context statement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 Regulatory and contractual context"]
  N2["20.2 Stakeholders and constraints"]
  N3["20.3 The context statement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 Regulatory and contractual context]
    |
    v
[20.2 Stakeholders and constraints]
    |
    v
[20.3 The context statement]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) describe the regulatory, contractual and organisational context of Corvia's architecture; (2) identify stakeholders and constraints; (3) write a context statement for a project.

20.1 Regulatory and contractual context

From year three Sofia works on a real-scale project: redesigning Corvia's fare back office. Daniel first asks her to understand the context. Card payments bring obligations from the payment industry; personal data brings privacy law; public funding brings audit requirements; and vendor contracts limit what Corvia can change in validators. She lists each obligation, its source and what it requires architecturally, such as segmentation of payment systems or deletion of personal data on request. Context constrains design before any technical choice is made, so ignoring it leads to designs that cannot be approved.

20.2 Stakeholders and constraints

Sofia identifies stakeholders: passengers, fare-collection staff, finance, the data protection officer, the operations centre, validator and payment vendors, auditors and the transit authority board. Each has needs and constraints. Finance needs accurate reconciliation; operations needs systems that work during outages; the data protection officer needs minimisation and access logs; vendors need stable interfaces. Constraints include a fixed budget, a three-year timeline and legacy validators that cannot be replaced until year five. She records each constraint because architecture is the art of meeting needs within constraints, not designing an ideal system.

20.3 The context statement

Sofia writes a two-page context statement for the project: purpose, scope, stakeholders, obligations, constraints, assumptions and out-of-scope items. Daniel reviews it with the project board, who correct two assumptions: payment tokenisation is already contracted, and the passenger app is out of scope. Correcting assumptions at this stage costs a meeting; correcting them after design costs months. The context statement becomes the first document in the architecture record and is referenced by every later decision, so reviewers can check whether a design still fits its context.

Worked example

Sofia lists four sources of obligations, maps eight stakeholders and constraints and writes a context statement corrected by the project board.

Synthetic case. Obligations, stakeholders and board decisions are synthetic.

Errors and limits

Legal interpretation needs qualified advice. Context changes during long projects and must be revisited.

Exercises

EX058 — Obligation example. Give one obligation and its architectural effect. Rubric: 3 = payment obligations require segmentation of payment systems; privacy requires deletion support;; 2 = one pair;; 1 = vague;; 0 = none.
EX059 — Legacy constraint. Which constraint limits validator changes? Rubric: 3 = legacy validators cannot be replaced until year five;; 2 = legacy;; 1 = budget;; 0 = none.
EX060 — Corrected assumptions. Which two assumptions did the board correct? Rubric: 3 = tokenisation already contracted; passenger app out of scope;; 2 = both;; 1 = one;; 0 = none.

Synthesis

Engineering context sets the obligations, stakeholders and constraints that every architecture decision must respect.

Continue studying — chapter 20 of 50

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →