Chapter 35 — Design studio II | Engineering Identity and access management

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 35 — Design studio II

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Reviewing what was built"]
  N2["35.2 Divergences"]
  N3["35.3 Critique and decisions"]
  N4["35.4 Recording outcomes"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX103"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 Reviewing what was built"]
  N2["35.2 Divergences"]
  N3["35.3 Critique and decisions"]
  N4["35.4 Recording outcomes"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 Reviewing what was built]
    |
    v
[35.2 Divergences]
    |
    v
[35.3 Critique and decisions]
    |
    v
[35.4 Recording outcomes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) review what was built against the design; (2) present measured outcomes; (3) agree improvements for the second half of the project.

35.1 Reviewing what was built

Halfway through implementation, Sana runs a second design studio with Dr Hale, two council engineers and the service desk leader. The first studio reviewed plans; this one reviews what was actually built. She presents the deployed architecture, measured outcomes, divergences from the design and the exceptions that accumulated during rollout. Comparing the built system with the design shows where reality differed from intention, and those differences are where the most useful lessons for the second half of the project are found.

35.2 Divergences

Three divergences stand out. Exceptions grew faster than planned, with 140 active exceptions, a third without a clear business reason. Two legacy applications planned for proxies remain on scripted checks because a vendor upgrade slipped. And conditional access has eleven policies rather than the planned five, as special cases were added during rollout. Each divergence is presented with evidence and its cause, without blame, so the group can decide whether to accept it, correct it or change the design to reflect a better understanding.

35.3 Critique and decisions

The group agrees three decisions. Exceptions will be reviewed in a focused campaign, with approvers confirming or removing each within four weeks. Conditional access policies will be consolidated, with test cases written first so consolidation cannot silently change behaviour. The legacy applications remain on scripted checks with monthly owner sign-off until the vendor delivers. The service desk leader adds that recovery requests are rising, so Sana adds a second-passkey campaign to reduce lost-device recoveries. Each decision has a named owner and a date for completion, recorded in the studio notes.

35.4 Recording outcomes

Sana records the studio as before: attendees, material, divergences, decisions, owners and dates. She updates the design documents so they describe the system as built, not as originally imagined, and notes each change in the decision log. Keeping documentation in step with reality is easy to postpone and costly to neglect: an engineer who trusts an outdated design document during an incident may take exactly the wrong action under pressure. Participants confirm the record within a week, and it is filed with the earlier studio notes so the design's history stays in one place.

Worked example

Studio II finds 140 exceptions (one third unexplained), eleven conditional policies and two delayed proxies; decisions include an exception campaign, policy consolidation with tests first and a second-passkey campaign.

Synthetic case. Counts, decisions and participants are synthetic.

Errors and limits

Leaving design documents describing the intended rather than the built system misleads engineers during incidents.

Exercises

EX103 — Exception growth. How many exceptions were active, and what share lacked a reason? Rubric: 3 = 140, about a third;; 2 = 140;; 1 = few;; 0 = none.
EX104 — Consolidation safeguard. How is policy consolidation kept safe? Rubric: 3 = test cases written first;; 2 = tests first;; 1 = vague;; 0 = none.
EX105 — Recovery response. What campaign addresses rising recovery requests? Rubric: 3 = second-passkey registration;; 2 = second passkey;; 1 = password reset;; 0 = none.

Synthesis

Reviewing the built system honestly and updating documents keeps a programme aligned with reality.

Continue studying — chapter 35 of 50

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →