Architecture Decision Lab
A decision-structuring workspace for comparing architecture choices against the constraints that matter most. It helps senior engineers make trade-offs explicit and produce a defensible starting point for an Architecture Decision Record.
Who this Lab is for
Designed for
- Architects and principal engineers
- Technical leads comparing platform options
- Teams preparing an ADR or design review
Use it when
- Several technically viable options have different trade-offs
- A decision is expensive or difficult to reverse
- Stakeholders disagree about the most important constraint
A complete run, step by step
Frame the decision
Describe the capability, boundaries and irreversible part of the choice without embedding a preferred answer.
Weight the constraints
Set the relative importance of reliability, operability and cost for this specific context.
Assess reversibility
Consider data gravity, contracts, migration effort and organisational coupling.
Record the evidence
Save the result and use it to shape an ADR, proof of concept and review plan.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Decision under review
Describe the capability and the irreversible part of the choice.
Reliability importance
Weight in the final decision score.
Operability importance
On-call and maintenance burden.
Cost importance
Infrastructure and engineering cost.
Reversibility
How easily the decision can be undone.
Choices: High · Medium · Low
What the result tells you
Your report includes
- An explicit constraint profile
- A reversibility and decision-risk assessment
- Recommendations for evidence and review
How it is determined
The Lab combines stated constraint weights with reversibility to identify the decision's dominant concerns. It does not select a vendor automatically; it shows which evidence an option must satisfy before commitment.
Constraint weights and reversibility structure discussion but do not compare actual options or evidence.
Model assumptions
- • Reliability, operability and cost are the relevant top-level constraints.
- • Weights are agreed by accountable stakeholders.
- • Reversibility is assessed consistently.
Authoritative references
Multi-region event platform
Situation
Reliability and operability are weighted above short-term cost, and moving stored events later would be difficult.
Result
The result treats the choice as high-consequence and recommends failure testing, an operational ownership model and an exit strategy before selection.
Use the result with engineering judgement
- It does not benchmark specific products or vendors.
- The quality of the outcome depends on a neutral decision statement.
- Financial, legal and data-residency reviews may still be required.
Questions before you begin
Is this a complete ADR generator?
It creates the decision frame and recommendations. You should add evaluated options, evidence, the final decision and consequences to your organisation's ADR template.
Who should set the weights?
Set them with the service owner and the people accountable for operations, security and cost—not by one architecture stakeholder alone.
Can the result be changed later?
Yes. Architecture decisions should be revisited when constraints or evidence materially change.
ADR Lab is under review
This legacy judgement-based Lab has been retired. Existing saved reports remain available, but new execution is disabled.
Open deterministic utilities