OpenCyber AcademyLesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Principles from requirements"]
N2["18.2 Architecture review"]
N3["18.3 Decision records"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Principles from requirements"]
N2["18.2 Architecture review"]
N3["18.3 Decision records"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Principles from requirements]
|
v
[18.2 Architecture review]
|
v
[18.3 Decision records]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) translate governance requirements into architecture principles; (2) review an architecture against them; (3) record architecture decisions for audit.
18.1 Principles from requirements
Nadia learns that architecture turns requirements into structure. Ardwell's governance requirements include keeping payment data in a small segment, separating control systems from office systems and controlling vendor access. She writes architecture principles from them: minimise the scope of sensitive data, separate zones by trust level, broker all external access through monitored points and design for recovery. Principles give architects a basis for choices and give auditors a way to check that designs follow policy. The principle of brokering external access through monitored points, for example, directly rules out the direct vendor connection found earlier.
18.2 Architecture review
Nadia joins a review of a proposed new meter data platform. She checks it against each principle. The design stores customer names with meter readings in a cloud service reachable from office laptops, which widens the scope of personal data and creates a new path into a sensitive store. She recommends pseudonymising readings and restricting access to an analytics zone. The review records each concern, the architect's response and the final decision, so the outcome can be traced later. Pseudonymising readings keeps the analytics value while removing customer names from the store reachable from office laptops.
18.3 Decision records
Ardwell adopts short architecture decision records: the context, the decision, the alternatives considered and the consequences, including risks accepted. Nadia writes one for the meter platform. She learns that decision records help auditors see that risks were considered rather than overlooked, and help future engineers understand why something looks the way it does. Without them, organisations repeat old debates or undo good decisions because nobody remembers the reasons behind them. The meter platform record, for example, lists keeping names with readings as a rejected alternative and pseudonymisation as the chosen one.
Worked example
Nadia derives four architecture principles, reviews a meter platform design against them and records the decision with alternatives.
Synthetic case. The platform and decisions are synthetic.
Errors and limits
Principles can conflict. Decision records go unread if too long.
Exercises
- EX052 — Principle list. Name two of Nadia's architecture principles.
Show marking criteria
Rubric: 3 = minimise sensitive data scope; broker external access;; 2 = principles;; 1 = vague;; 0 = none. - EX053 — Platform concern. What was wrong with the meter platform design?
Show marking criteria
Rubric: 3 = names stored with readings reachable from office laptops;; 2 = scope;; 1 = vague;; 0 = none. - EX054 — Record contents. What does an architecture decision record contain?
Show marking criteria
Rubric: 3 = context, decision, alternatives and consequences;; 2 = four parts;; 1 = vague;; 0 = none.
Synthesis
Architecture principles and decision records connect governance requirements to system design.
Continue studying — chapter 18 of 50
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →