Parameters

The following parameters are the twenty-one proposed rules the design has to follow. Each one is written so a reviewer can point at something and judge whether it complies. Six of the parameters must be built in from the start; they cannot be added once the work has started.

What a parameter is

A parameter is something a system must comply with. A parameter must be check-able; it must be possible to check whether the system complies to it. To make sure that these rules are parameters, every entry below ends in a question you can put to a running system and get a wrong answer to.

The set makes three claims:

1. Every parameter is necessary: take one away and the design loses something nothing else supplies.
2. No two overlap: nothing is said twice.
3. And together they carry what the architecture is trying to do.

Each entry below demonstrates the first two claims. The third rests on an argument against a list of intents, and it is the weakest of the three, because another architect could reasonably draw some of these lines elsewhere.

The set

All twenty-oneMust be right firstAdded since the source

The record

• N01 Every fact is dated and has a source
• N02 Parts of the system share facts and decisions, not raw data

Boundaries between parts

• N03 Each part keeps its own picture of the data
• N04 Rules live with the data they control
• N05 Only one system can change a record at a time

Copies and corrections

• N06 Every copy can be traced, and every correction reaches it must be right first
• N21 Limits on how information may be used travel with it must be right first

Making a decision

• N07 The calculation uses only what it is given must be right first
• N08 The decision record is complete on its own
• N09 A decision records the moment its facts were read must be right first

Interfaces and buying

• N10 The interface outlasts the system behind it
• N11 Buy common tools, and have someone else check any choice to build

Keeping and destroying records

• N12 How records are destroyed is decided before anything is stored must be right first
• N13 The system knows whose record it is

Moving back

• N14 Every move can be undone, and what is lost is written down must be right first

Access for everyone

• N15 Everyone can use the service, whatever their ability or way in

Recovery and separate duties

• N16 Each service has recovery targets, proven in practice runs
• N17 Different people decide, review and pay

Legal time limits

• N19 The system tracks legal time limits

Challenging a decision

• N20 Each benefit records whether and how a decision can be challenged

Catching a breach

• N18 Every rule comes with a way to catch it being broken

Six cannot be added later

You can satisfy most of these late, at a price. Six you cannot. Each one has to be in place before a particular first event. Once that event has happened, the fix is a rebuild rather than a repair.

1. Before the first rule is written N07

   The engine is sealed off from live data. A rule authored against a service it can call has already fixed the shape of every rule after it.

2. Before the first event is written N12, and the third date in N01

   How records are destroyed is decided per class of fact. Events are immutable, so a date can be added with a default but never filled in afterwards.

3. As the first copy is made N06, N21

   Where a copy came from, and what its source bars it from, are written at the moment of copying. Neither can be reconstructed later.

4. From the first decision N09

   The point in the event sequence a decision read from goes into its record. Earlier decisions cannot be tied to a consistent view of the world.

5. Before the first group of clients moves N14

   Moving them back is proven rather than claimed, and what the return trip loses is written down and approved.

Do first only what cannot be done later.

Where the twenty-one came from

Every principle in the architecture is accounted for. Seven carried across, with their wording narrowed or widened. Three split, because each held two ideas that could stand apart. One took in a clause from another, and one became more general. So twelve principles turned into fourteen parameters, and seven more joined them.

• P1 split N01 · N02
• P2 narrowed N08
• P3 split N03 · N06
• P4 absorbs P3(a) N03
• P5 carried N04
• P6 extended N11
• P7 carried N10
• P8 narrowed N07
• P9 carried N05
• P10 generalised N18
• P11 split N12 · N13
• P12 carried N14

Added N09 · N15 · N16 · N17 · N19 · N20 · N21

Those last four are the interesting ones, because nobody found them by thinking harder about the architecture. They came from reading what the ministry already tells its own staff to do. Policy sets time limits, and missing one changes what a client is owed. It names which entitlements a client can appeal, and to whom. It keeps the person who decides apart from the person who reviews. And it bars certain uses of information the ministry may lawfully hold. The twelve could not express any of that.

Where a parameter restates one of the architecture’s twelve principles, the architecture’s own wording wins if the two ever differ. The seven new ones are recorded as amendments to the architecture, each with a decision record. N16 is still a proposal.

A rule nobody can check is not a rule

One parameter is not about the system at all. N18 ranges over the other twenty. It makes each of them name how you catch a breach, and it says that anything you could write as a lint rule or a compatibility check has to be written as one.

It stands on its own rather than folded into the others. File a rule about enforcement among the rules about behaviour, and enforcement stops being anybody's job without anyone deciding that it should.