Chapter 2 — Security architecture and engineering: service and stakeholder context
Lesson map
Lesson 02 published. Map, example, EX006.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Services and owners"]
N2["2.2 Stakeholder needs"]
N3["2.3 Conflicting needs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX006"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Services and owners"]
N2["2.2 Stakeholder needs"]
N3["2.3 Conflicting needs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX006"]
[Learning outcomes]
|
v
[2.1 Services and owners]
|
v
[2.2 Stakeholder needs]
|
v
[2.3 Conflicting needs]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX006]
Learning outcomes
You will (1) map Thornbury's services and stakeholders; (2) record their security needs; (3) handle conflicting needs.
2.1 Services and owners
Owen lists Thornbury's main services and their business owners: the tenant portal owned by customer services, repairs owned by the property team, rent owned by finance, the call centre owned by operations and case management for vulnerable tenants owned by the safeguarding lead. Each service also depends on IT and on outside suppliers. Naming owners matters because architecture decisions involve trade-offs that only the business owner can accept, such as slower sign-in in exchange for stronger protection of tenant data.
2.2 Stakeholder needs
Owen interviews each owner for twenty minutes using the same questions: what data the service holds, what would hurt most if it failed or leaked, who uses it and from where, and which rules apply. The safeguarding lead stresses that a leak of a tenant's new address could endanger someone fleeing domestic abuse. Finance worries most about payment fraud. Customer services wants the portal to stay easy for elderly tenants. Recording needs in owners' own words builds trust and keeps architecture grounded in real consequences.
2.3 Conflicting needs
Needs conflict. Customer services wants simple portal sign-in; the safeguarding lead wants strong protection of addresses. Owen proposes a design where most portal functions use simple sign-in, while viewing or changing contact details requires an extra verification step. Both owners accept it. He records the agreement and the reasons in a short decision note. Ines points out that many conflicts disappear when a design treats different data differently, rather than applying one level of protection to everything in the same way.
Worked example
Owen maps five services to owners, records needs from short interviews and resolves a portal conflict by protecting contact details more strongly.
Synthetic case. Services and people are synthetic.
Errors and limits
Short interviews miss detail. Owners may not foresee all consequences.
Exercises
- EX006 — Why name owners. Why name business owners for services? Rubric: 3 = only they can accept trade-offs;; 2 = trade-offs;; 1 = vague;; 0 = none.
- EX007 — Safeguarding concern. What did the safeguarding lead stress? Rubric: 3 = a leaked new address could endanger someone fleeing abuse;; 2 = address;; 1 = vague;; 0 = none.
- EX008 — Portal compromise. How was the portal conflict resolved? Rubric: 3 = extra verification only for viewing or changing contact details;; 2 = step-up;; 1 = vague;; 0 = none.
- EX009 — Dissolving conflict. Why do many conflicts disappear in good designs? Rubric: 3 = different data is protected differently;; 2 = differentiate;; 1 = vague;; 0 = none.
- EX010 — Interview method. How did Owen keep stakeholder interviews comparable? Rubric: 3 = twenty minutes with the same questions for every owner;; 2 = same questions;; 1 = vague;; 0 = none.
Synthesis
Mapping services, owners and needs lets designs protect what matters most while keeping services usable.
Continue studying — chapter 02 of 12
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →