An architecture principle nobody could ever break is useless: writing principles that decide

The list was presented to the committee two years ago. Around ten principles, each a single sentence: data is an enterprise asset; reuse before buy, buy before build; security is everyone’s business; the information system must be agile and adaptable; the user is at the centre. It was approved without debate, published on the intranet, and appended to every architecture file since.

Today, a difficult choice comes up. One division wants to subscribe to an online service that holds its own customer database; IT would rather extend the existing tool. Each side quotes a principle from the list, and both quotations are accurate. The first invokes “buy before build”, the second “data is an enterprise asset”. In the end the committee decides on schedule and budget, exactly as it would have without a list.

Nobody broke a principle. That is precisely the problem. A principle nobody could break decides nothing, because it rules nothing out. Lists of principles do not wear out through lack of application: they are born useless, because they are written to be approved rather than to arbitrate. A useful principle is a decision taken in advance for a category of cases. Like any decision, it has to cost someone something.

Why the lists end up as decoration

The causes are well known, and they have more to do with how the lists are produced than with the good faith of those who write them.

Consensus is the approval criterion. A list of principles is usually submitted to a committee on which divisions with diverging interests sit. Every wording that bothers one of them is softened until nobody objects. What comes out is the text everyone can sign — and therefore the text that commits no one.

The principles are written in the abstract. They are drafted in workshops, far from any real decision, without anyone asking which recent file they would have changed. A principle that has never been confronted with a case has no reason to settle one.

Nothing says which one wins. A list of ten principles with no precedence rule can justify almost any decision: you only need to pick the one that fits. The list becomes a stock of arguments, drawn on after the decision to legitimise it, not before to steer it.

Nothing says what the principle costs. “Prefer market solutions” sounds reasonable as long as the counterpart stays unspoken: that the organisation will adapt its processes to the package, and that some business requests will be turned down for that reason. Without that clause, the principle is approved by the very people who will oppose it at the first concrete case.

The negation test

A simple criterion sorts an existing list in a few minutes. A principle only carries information if its opposite is a position a reasonable organisation could hold.

“Data is an enterprise asset” fails the test: nobody argues that data has no value. The sentence is not wrong, it is empty — it describes a shared conviction, not a choice. The same goes for “security is everyone’s business”, “the IS must be agile” or “the user is at the centre”. Their opposite is absurd; asserting them therefore rules out no option.

“Each piece of reference data is written by a single system; the others read it” passes the test. Its opposite — each application keeps its own copy of customers or products, and the versions are reconciled afterwards — is not absurd. It is the situation of many organisations, and it can be defended: it lets each domain move at its own pace, at the price of permanent reconciliation. Choosing one over the other is a real decision. The principle takes it once and for all, instead of leaving it to be reopened, file by file, project by project.

The test does not condemn convictions. “Data is an asset” can sit in the preamble of a strategy document. But a conviction is not an architecture principle until it has been translated into a choice. The translation almost always comes down to one question: if we really believe this, what are we going to forbid ourselves? For data, the answer might be a named owner for each reference dataset, a single system allowed to write it, a ban on creating a master copy inside a business tool. That answer is what deserves to be written down.

What a principle must contain to arbitrate

The most widespread format, popularised by TOGAF, already provides the essentials: a name, a statement, a rationale, implications. The format is not the problem; the problem is that the last two headings are often filled with generalities. A principle that arbitrates takes them seriously, and adds two further elements.

A statement that excludes something. The negation test applies here: it must be possible to name at least one reasonable option the statement rules out.

A rationale specific to the organisation. Not a general truth about IT, but the reason why this organisation makes this choice now: a regulation, a dependency suffered in the past, a capability judged strategic, a skill that is lacking. The rationale has a precise function: it states the conditions under which the principle will stop being valid. A principle justified by a regulatory constraint becomes open to question the day that constraint changes; without a written rationale, nobody thinks of reviewing it.

Implications that are owned. This is the decisive heading. It states what the organisation commits to doing and, above all, what it accepts to lose: the requests that will be refused, the costs that will be borne, the divisions that will have to change their practices. An implication that costs nobody anything is not one.

A scope. Almost no principle holds everywhere. “Buy before build” is defensible for support capabilities, much less so for those that differentiate the organisation — which is the whole point of the trade-off between package and custom build. Writing where the principle does not apply makes it more credible where it does.

An exception procedure. Who can decide to depart from it, on what basis, and how the departure is recorded. A principle without an exception procedure is bypassed in silence; a principle with one leaves a trace, and that trace says something about the principle itself. It is the same logic as the signed exception: nobody’s right to override is taken away, but the choice must have an owner.

Applied to the reference-data principle, the exercise produces a short text a committee can read. The statement: each piece of reference data — customer, product, third party, organisation — is created and modified in a single system; the others consult it or receive a read-only copy. The rationale: reconciliations between systems currently tie up teams and produce diverging figures in management dashboards. The implications: any new tool that carries a notion of customer will have to be fed from the reference system, which may exclude some solutions or require interface development; divisions that currently enter customers in their own tools will have to go through the reference system. The scope: shared reference data, not data specific to a single process. The exception: decided by the owner of the data concerned, recorded with a review date.

Written this way, the principle is not unanimous. At least one division will see it as a constraint. That is the sign it is useful, and this is the moment to discuss it — once, when it is written, rather than at every project.

Principles contradict each other, and that is normal

Difficult decisions almost never fall within the scope of a single principle. They arise precisely where two legitimate principles point in opposite directions.

Preferring a cloud provider’s managed services reduces the operating burden; preserving reversibility argues against services specific to one provider. Favouring packages speeds up delivery; keeping control over the capabilities that differentiate the organisation argues for building. Pooling platforms cuts costs; isolating systems limits how far an incident spreads. None of these principles is wrong. But a list that contains them all while saying nothing about their conflicts lets each side pick its principle, and brings the decision back to a balance of power.

It is neither possible nor desirable to remove these tensions: they reflect real objectives of the organisation. It is, however, possible to write them down. Two forms are common.

An explicit order of precedence. When two principles conflict, one wins by default, and the other can only prevail through a reasoned exception. For example: reversibility takes precedence over reducing the operating burden, except for services whose exit has been estimated and judged acceptable.

Conditional precedence. The order depends on the nature of what is being decided. The business capability map is the most natural tool here: for a support capability, the market wins over control; for a differentiating capability, the reverse. The rule is then read capability by capability, rather than principle against principle.

Either way, writing the precedence rule forces a debate the original list had carefully avoided. It is uncomfortable. It is also the only way to get principles that work on the day they are actually called upon.

Testing a list against decisions already taken

The best way to assess a list of principles is not to reread it, but to confront it with real decisions. The exercise is simple, and requires no particular tooling.

Pick a handful of structuring decisions taken over the past few years — a package selection, a hosting choice, a rebuild, the use of a cloud service. If the organisation keeps a register of architecture decisions, it provides the material; if not, executive committee minutes and project files will do. For each decision and each principle, ask a single question: would this principle have steered the decision, was it set aside, or was it silent?

Three findings almost always come out of this exercise.

Principles silent throughout. They steered no decision, because no decision could go against them. They are the ones that fail the negation test. They should be rewritten as choices, or removed from the list and kept as convictions.

Principles set aside without a trace. The decision went against the principle, and nobody recorded it. Two readings are possible, and one must be chosen: either the principle was right and governance failed, or the decision was right and the principle needs revisiting. Either way, the missing record is the real defect.

Principles that contradict each other on the same case. This signals a missing precedence rule. The real case is in fact the best starting point for writing it: it is easier to agree on what should have won in a concrete decision than on an abstract hierarchy.

The exercise has a further merit: it shifts the discussion. People no longer debate the wording of a principle in general, but what it would have changed in a decision everyone knows.

Few, short, and reviewed

A few rules of upkeep follow from the above.

Few principles. A principle only acts if it is present in the minds of those deciding, at the moment they decide. Beyond what a committee can keep in mind without rereading the document, the list stops being a decision tool and becomes a reference consulted after the fact. A few principles that decide are worth more than many that reassure.

Principles that are cited. Every recorded decision should state the principles it applies and those it departs from. After a year, a principle that has never been cited is a candidate for removal; a principle that is repeatedly departed from is a candidate for rewriting. The decision register thus becomes the instrument for revising the list.

Principles reviewed when their rationale changes. Not only on a fixed date, but whenever the written reason for the principle shifts: a revised regulation, a replaced vendor, a capability that is no longer strategic. That is the value of a rationale specific to the organisation: it carries its own expiry condition.

A principle is a decision taken in advance

The value of a principle rests on a simple idea: it spares the organisation from making the same trade-off on every project. It concentrates the debate into a single moment — when it is written — instead of scattering it across dozens of committees, where it is replayed each time under the pressure of a schedule and a budget.

That saving has a price, and there is no way around it. A decision taken in advance that rules nothing out has decided nothing; a decision that rules something out disappoints someone. Writing principles that arbitrate means accepting that the disagreement happens when they are written, among the people who have the mandate to settle it, rather than later, case by case, among those who have only the list to argue with. A list approved without debate has probably not yet decided anything.