Week 2: risk register and iteration plan
Goal: turn uncertainty into concrete technical risks and decide what to de-risk first.
In the practical session
- create an initial risk register with 8-12 technical risks in
/risk/risk_register.adoc; - include identity/auth risks, integration risks, availability/scalability risks, auditability/privacy risks, and interface evolution risks;
- prioritize risks by likelihood and impact;
- define one possible mitigation, validation step, or design activity for each important risk;
- sketch a coarse iteration plan and state which risks each phase addresses;
- write a first ownership sketch for major future containers/services.
Deliverables due before Week 3
/risk/risk_register.adocwith prioritized risks;/docs/iteration_plan.adocwith phases/iterations and the risks addressed by each;/docs/ownership_sketch.adocwith initial ownership assumptions.
Minimum expected content in risk_register.adoc
- 8-12 risks;
- each risk has an ID, statement, likelihood, impact, and treatment;
- each important risk uses the form: "If [condition/event], then [impact]";
- at least one risk related to identity/authentication;
- at least one risk related to authorization/delegation;
- at least one risk related to integration with external organizations;
- at least one risk related to auditability or privacy;
- at least one risk related to availability, scaling, or failure handling;
- at least one risk related to interface evolution.
Minimum expected content in iteration_plan.adoc
- 3-5 project phases or iterations;
- the main artifact produced in each phase;
- the risks each phase reduces;
- what evidence would show that the risk has been reduced.
Questions to answer
- What could make the architecture unsuitable even if all visible features are present?
- Which risks should be addressed before the team commits to a structure?
- What evidence would make a risk less worrying?
- Which containers or services would need clear ownership in a real implementation?
- Which risks are caused by organizational or external-system dependencies?
Quality bar
- risks should be technical enough that architecture work can reduce them;
- "we do not know technology X" is weaker than "if technology X cannot provide property Y, then system goal Z fails";
- treatments should name an architecture/design activity, not only "research more".