OpenCyber AcademyLesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Generating alternatives"]
N2["26.2 Weighted evaluation"]
N3["26.3 Documenting the choice"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Generating alternatives"]
N2["26.2 Weighted evaluation"]
N3["26.3 Documenting the choice"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Generating alternatives]
|
v
[26.2 Weighted evaluation]
|
v
[26.3 Documenting the choice]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) generate architecture alternatives for the back office; (2) evaluate them against weighted criteria; (3) document why the chosen option won.
26.1 Generating alternatives
For the fare back office, Sofia generates three alternatives. Alternative A keeps a single on-premises cluster with improved segmentation. Alternative B moves processing to a cloud provider with managed key services. Alternative C splits the system: tap ingestion and fare calculation stay on-premises, while reporting and analytics move to the cloud with only pseudonymised data. Daniel insists on at least three options, because comparing only two often hides a better middle path, and a do-minimum option provides a baseline against which the value of change can be judged.
26.2 Weighted evaluation
Sofia and the stakeholders agree criteria and weights: security of personal data, resilience during outages, cost over five years, migration risk and fit with the legacy validators. Each alternative is scored by three people independently, then scores are discussed where they differ. Alternative C scores highest overall, mainly because it keeps personal data on-premises while gaining cloud scalability for analytics. Sofia records how sensitive the result is: if cost weight doubles, A wins. Sensitivity shows stakeholders which assumptions drive the decision, inviting debate on those rather than on the final number.
26.3 Documenting the choice
Sofia writes an architecture decision record for alternative C, listing the options, criteria, weights, scores, sensitivity results and consequences, including new risks such as the pseudonymisation process being a single point of failure for privacy. The record also states conditions under which the decision should be revisited, such as a change in cloud pricing or regulatory guidance. Daniel explains that decisions documented this way can be audited and revisited calmly, while undocumented decisions are reopened repeatedly whenever a new manager arrives with a different preference.
Worked example
Sofia generates three back-office alternatives, scores them on five weighted criteria with sensitivity analysis and records alternative C with its new risks and revisit conditions.
Synthetic case. Alternatives, weights and scores are synthetic.
Errors and limits
Weighted scoring can hide disagreements behind averages. Pseudonymised data may be re-identifiable when combined with other data.
Exercises
- EX076 — Three options. Why does Daniel insist on at least three alternatives?
Show marking criteria
Rubric: 3 = two options hide middle paths; a do-minimum gives a baseline;; 2 = middle path;; 1 = no reason;; 0 = none. - EX077 — Sensitivity result. What happens to the decision if the cost weight doubles?
Show marking criteria
Rubric: 3 = alternative A wins instead of C;; 2 = A wins;; 1 = C still;; 0 = none. - EX078 — New risk. What new risk does alternative C introduce?
Show marking criteria
Rubric: 3 = pseudonymisation process becomes a single point of failure for privacy;; 2 = pseudonymisation;; 1 = vague;; 0 = none.
Synthesis
Comparing several alternatives with explicit weights and sensitivity makes architecture decisions transparent and revisitable.
Continue studying — chapter 26 of 50
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →