AR3: Decisions and risks: ADRs, weighted scoring, risk registers and fitness functions
Options and weighted scoring
🎯You'll be able to
Compare options against weighted criteria, check the arithmetic, and recognise when scores are judgement rather than measurement.
🏠The everyday picture
Choosing a flat, you might weigh rent most, then distance to work, then light. Scoring three flats on each, weighted, helps you compare. But if you secretly want the second flat, you can always find scores that make it win.
📘What it really is
-
Criteria come from the decision drivers (AR1's ranked quality attributes): fault isolation, deploy independence, operational simplicity, team fit, cost.
-
Weights add up to 100 and say how much each criterion matters. Agree them before scoring, so they aren't tuned to a favourite.
- Scores (for example 1 to 5) say how well each option meets each criterion. The weighted total is the sum of weight × score.
- Scores are mostly judgement. Say so, say who scored and when, and back scores with evidence where you can.
- Check sensitivity: if a small change to one weight flips the winner, the options are close and other factors deserve attention.
📝A worked example
Input: weights fault isolation 25, operational simplicity 25, deploy independence 20, team fit 15, cost 15; four options.
Steps:
- Score "Modular monolith, with notifications as a service": deploy independence 3, fault isolation 4, simplicity 4, team fit 4, cost 4.
- Total: 20×3 + 25×4 + 25×4 + 15×4 + 15×4 = 60 + 100 + 100 + 60 + 60 = 380.
- Score "Microservices for every module": 5, 4, 1, 2, 1. Total: 100 + 100 + 25 + 30 + 15 = 270.
- Sensitivity: raising deploy independence to 40 and lowering simplicity to 5 narrows the gap to 360 against 350, so the result holds unless running costs stop mattering almost entirely. Note that in the ADR.
Expected output: a Scores table with a checked Weighted total row, and a note on how sensitive the result is.
🌍Where it's used
- Procurement teams score vendors against weighted criteria agreed before bids arrive.
- Architecture boards ask for options and scores before approving a large change.
- Start-up founders score build-or-buy choices for core tools.
📝Case scenario
A team scored three databases and the one they already liked won by 2 points out of 400. A reviewer asked them to agree weights with the operations team first. The re-scored result was a tie, which led to a two-week trial of both: a better decision than a falsely precise score.
🖱️Try it
Score three options for a decision you face (a laptop, a course, a framework) on four weighted criteria. Then change one weight by 10 and see whether the winner changes. Success: your totals add up, and you write one sentence on sensitivity.
⚠️Common mistakes
- Weights set after scoring. Sign: the favourite always wins. Fix: agree weights first, with others.
- Arithmetic errors. Sign: a total that doesn't match. Fix: recompute, or let a test do it (Project 1, test 4).
- Treating scores as facts. Sign: "380 proves it". Fix: label scores as judgement and give the evidence behind them.
🛠️For your project
Project 1's test 4 recomputes every weighted total, and test 5 checks each criterion appears in a decision driver.
✅Quick check
Why should weights be agreed before scoring?
Show the answer
So they reflect what matters, rather than being adjusted to make a favourite option win.
What does a sensitivity check tell you?
Show the answer
Whether a small change in weights would change the winner, which means the options are close.