Chapter 45 — Independent design review
Lesson map
Lesson 45 published. Map, example, EX133.
flowchart TD
N0["Learning outcomes"]
N1["45.1 Reviewers"]
N2["45.2 Findings"]
N3["45.3 Responses"]
N4["45.4 Disagreement"]
N5["45.5 Record"]
N6["45.6 Learning"]
N7["Second round"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX133"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["45.1 Reviewers"]
N2["45.2 Findings"]
N3["45.3 Responses"]
N4["45.4 Disagreement"]
N5["45.5 Record"]
N6["45.6 Learning"]
N7["Second round"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX133"]
[Learning outcomes]
|
v
[45.1 Reviewers]
|
v
[45.2 Findings]
|
v
[45.3 Responses]
|
v
[45.4 Disagreement]
|
v
[45.5 Record]
|
v
[45.6 Learning]
|
v
[Second round]
|
v
[Worked example] --> [Exercise EX133]
Learning outcomes
You will (1) submit the capstone design for independent review; (2) respond to findings; (3) revise; (4) record decisions.
45.1 Reviewers
A platform engineer from another team and a security architect from a partner university review the design package.
One reviewer knows how Solent's platform is run day to day; the other brings a wider view of security architecture from outside the company. Neither worked on the project, so they do not share Elena's assumptions. Both receive the same package: requirements, threat analysis, design, templates and test plan. They review independently before meeting, so one reviewer's opinion does not shape the other's first reading.
45.2 Findings
The reviewers raise four points: quotas may be too small for data jobs; the workflow's own permissions are broad (it can create any namespace); monitoring setup assumes one log destination; templates lack versioning for rollback.
The quota point comes from experience with data jobs, which use far more memory than the web services Elena had in mind. The permission point is a security flaw in the service itself: a tool that creates secure namespaces must not be able to weaken the existing ones. The logging point would tie the design to one setup, and the missing versioning would make a bad template hard to roll back.
45.3 Responses
Quotas become size options; the workflow's identity is limited to creating namespaces with an approved label prefix and applying templates; log destination is a parameter; templates are versioned and namespaces record which version created them.
Each response states what changed and how it will be verified. The narrowed identity is tested by asking the workflow to change a namespace without the prefix and expecting a refusal. Size options are checked against the memory needs of two real data jobs. Recording the template version in each namespace means that, if a template is found faulty, a simple query lists every namespace created from it, so all of them can be fixed.
45.4 Disagreement
One reviewer suggests separate clusters per team. Elena explains the chapter 26 decision and criteria; the reviewer accepts, noting it as a future option.
The earlier decision compared a single shared cluster, clusters per sensitivity tier and a cluster per service on blast radius, cost, upgrade effort and regulator expectations, and chose a high-sensitivity and a standard cluster with dedicated node pools, because a dozen clusters would be more than four engineers could keep upgraded. Elena shows the criteria and the evidence rather than simply restating the conclusion. The reviewer's concern is reasonable for teams with very different risk levels, so it is recorded as a condition under which the decision should be revisited.
45.5 Record
A review log captures each finding, response and change.
Each entry holds the finding as the reviewer wrote it, its severity, Elena's response, the change made and the test or document that shows the change works. Disagreements are recorded with both sides' reasoning, not only the outcome. The log goes into the evidence dossier, where an assessor can trace any design choice back to the review that shaped it, and the reviewers confirm the final version. A finding without a recorded test stays open in the log.
45.6 Learning
Independent review catches issues the designer cannot see.
A designer reads the design knowing what she intended, so gaps between intention and what is written are hard to see. The workflow's broad permissions are an example: Elena knew it would only create namespaces for valid requests, but nothing in the design enforced that. Reviewers read only what is there. Elena adds a line to her design checklist asking what each component's own identity could do if the component misbehaved. The question is now asked of every new design.
Second round
After revisions, Elena sends the updated package back to both reviewers. They confirm the changes address their findings, and one adds a minor note about naming conventions for the label prefix, which Elena adopts. The two-round process takes three weeks but avoids rework later in implementation, when changes would cost more. Elena notes in her dossier that the review found a serious permission issue no internal test had covered.
Reviewer selection
Reviewers are chosen from outside the project so they bring fresh assumptions, and they receive the requirements and threat analysis with the design.
Worked example
The workflow permission finding is the most important: as first designed, a bug could have let the workflow modify system namespaces. The fix narrows its role, and a verification test confirms it cannot touch namespaces without the prefix.
Synthetic case. Review details are synthetic.
Errors and limits
Reviews only help if findings are acted on and verified.
Exercises
- EX133 — Four findings. List the four findings. Rubric: 3 = quotas, workflow permissions, log destination, template versioning; 2 = three; 1 = one; 0 = none.
- EX134 — Most important. Which finding mattered most and why? Rubric: 3 = workflow permissions; could modify system namespaces; 2 = partial; 1 = vague; 0 = none.
- EX135 — Disagreement. How was the disagreement handled? Rubric: 3 = explained decision criteria; noted future option; 2 = partial; 1 = vague; 0 = none.
Synthesis
Independent review strengthens designs when findings are verified.
Continue studying — chapter 45 of 50
← Chapter 44 (draft) · Course chapter index · Chapter 46 (draft) →