Chapter 25 — Design studio I
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 The brief"]
N2["25.2 First design"]
N3["25.3 Critique"]
N4["25.4 Revision"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 The brief"]
N2["25.2 First design"]
N3["25.3 Critique"]
N4["25.4 Revision"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 The brief]
|
v
[25.2 First design]
|
v
[25.3 Critique]
|
v
[25.4 Revision]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) produce a first design for governed leakage data; (2) present it for critique; (3) revise after feedback.
25.1 The brief
The first design studio asks Kofi to produce a governance design for the leakage chain in two weeks: owners, rules, lineage, monitoring and reporting. He works with two classmates who play the roles of network operations and billing owners. The brief requires a one-page summary, a lineage diagram, a rule catalogue and a monitoring dashboard sketch. The studio format mirrors professional practice, where designs are presented to peers and stakeholders before resources are committed to building them. Each student also writes a reflection.
25.2 First design
Kofi's design places all rules in a central quality service that every data set passes through. The service records results in one database and feeds a single dashboard. Owners receive daily emails with their figures. He argues that centralisation gives consistency and one place to look. His classmates question whether one service could handle sensor data arriving every minute alongside monthly billing extracts, and whether owners would read daily emails for very long. Kofi notes both questions for the panel and admits he has no answers yet.
25.3 Critique
The studio panel, led by Prof. Varga, praises the lineage and ownership work but challenges the central service as a single point of failure. If it stops, no data are checked. They also note that daily emails would quickly be ignored. One panellist suggests running rules close to each source, with results flowing to a shared store, and alerting owners only when thresholds are breached, alongside a weekly summary that shows trends over time. The panel gives written feedback within two days of the session.
25.4 Revision
Kofi revises the design: rules run within each pipeline using a shared rule library, results go to a common store, alerts fire only on threshold breaches and owners receive a weekly trend summary. He records the original design, the critique and the reasons for the changes in a decision record. He reflects that the critique improved the design because the panel looked at failure and human behaviour, which he had underweighted while focusing on technical consistency. The panel accepts the revised design at the next session.
Worked example
Kofi's first centralised design is critiqued as a single point of failure with ignorable emails, and he revises to distributed rules, a common results store, breach alerts and weekly summaries.
Synthetic case. The studio is synthetic.
Errors and limits
Defending a design instead of listening wastes critique.
Exercises
- EX073 — Central weakness. What weakness did the panel see in the central service? Rubric: 3 = single point of failure;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX074 — Alert change. How were owner notifications changed? Rubric: 3 = alerts only on breaches plus weekly summary;; 2 = partly correct;; 1 = partial;; 0 = none.
- EX075 — Underweighted. What had Kofi underweighted? Rubric: 3 = failure and human behaviour;; 2 = both;; 1 = one;; 0 = none.
Continue studying — lesson 25 (chapter 25 of 50)
← Chapter 24 · Course chapter index · Chapter 26 →
Continue to the next authored lesson.