Architecture principles that change decisions

Architecture principles are often confused with organisational values. The difference is practical and consequential.

A value expresses what the organisation believes. "We value our customers" is a value. It describes an attitude. It does not tell an architect what to do when two viable approaches conflict.

A principle shapes what the organisation will and will not do when architectural choices become difficult. "Every published number must carry a state, date context, and authority trail" is a principle. It creates a specific constraint on data architecture that can be tested, enforced, and used to resolve disputes.

The distinction matters because many organisations produce principles documents that read like corporate values. They are filed, approved, and forgotten because they create no design constraint. TOGAF makes this visible through a specific structure that forces each principle to declare its real-world consequences.

TOGAF C220 Part 3 defines a specific structure for architecture principles. Each principle must have four components. Without all four, the principle cannot do governance work in practice.

Name. A short, memorable label that identifies the principle. The name should be distinctive enough that people can reference it in conversation. "One published truth per date" is a good name. "Data quality" is too generic to be useful as a name.

Statement. A concise rule that can be applied repeatedly and understood quickly. The statement should be specific enough that two people reading it would agree on what it permits and what it forbids. Think of the statement as the rule itself. It should be one or two sentences at most.

Rationale. The explanation of why the rule exists and what enterprise consequence it is protecting or enabling. The rationale connects the principle to business reality, not to abstract aspiration. It answers the question: "Why does this rule matter to us?" A rationale that says "because data quality is important" is too weak. A rationale that says "because inconsistent data publication has eroded regulatory trust and caused three formal challenges in the past two years" has teeth.

Implications. The consequences for design, governance, reuse, exceptions, evidence, or delivery choices when the principle is applied seriously. Implications are where the principle earns its place. They answer the question: "What changes in practice because this rule exists?" Without implications, a principle is a statement of intent. With implications, it is a governance instrument.

Consider a complete example:

• Name: One published truth per date
• Statement: Every published number must carry a state, date context, and authority trail. Where multiple channels publish the same figure, all must reference the single authoritative record for that date.
• Rationale: Inconsistent data publication erodes regulatory trust, creates confusion for planning decisions, and undermines public confidence in the distributor's evidence base.
• Implications: Every data-publication channel must reference the single authoritative record. Derived or cached versions must be declared as such and carry refresh timestamps. Exception requests must go through the Architecture Board. Compliance will be checked at each governance review.

That is a working principle. You can test it. You can enforce it. You can use it to resolve a dispute between two teams that want to publish the same figure in different formats.

TOGAF C220 Part 3 provides a set of 20 example architecture principles grouped into five categories. These examples are not mandatory. They are starting points that organisations can adopt, adapt, or replace with their own principles. The value of the examples lies in their structure: each one follows the name, statement, rationale, and implications format, showing what a complete principle looks like.

The five categories cover:

1. Business principles (such as "Primacy of Principles," "Maximize Benefit to the Enterprise," "Information Management is Everybody's Business," "Business Continuity," and "Common Use Applications"). These establish the overarching rules that connect architecture work to business priorities.
2. Data principles (such as "Data is an Asset," "Data is Shared," "Data is Accessible," "Data Trustee," and "Common Vocabulary and Data Definitions"). These govern how the organisation treats data across the enterprise.
3. Application principles (such as "Technology Independence" and "Ease-of-Use"). These shape how applications are designed and selected.
4. Technology principles (such as "Requirements-Based Change," "Responsive Change Management," and "Control Technical Diversity"). These govern the technology landscape.
5. Additional principles that address cross-cutting concerns like interoperability and security.

The important point is not to memorise all 20 examples but to understand the pattern they follow. Every example has a name that is distinctive, a statement that is specific enough to test, a rationale that connects to business reality, and implications that change what architects and delivery teams actually do. If your own principles do not follow that pattern, they are likely too weak to govern real decisions.

A principle that cannot survive contact with a realistic trade-off is not ready for governance use. Here is a practical stress-test method you can apply to any principle:

1. Place the principle in front of a realistic trade-off. Not a generic aspiration but a concrete scenario where two viable approaches conflict. For example: "A delivery team wants to cache regulatory figures and update them weekly. The principle says one published truth per date."
2. Ask what a team would have to do differently if the principle were enforced. If the answer is "nothing changes," the principle is too broad. A good principle creates a specific obligation that the team must address.
3. Ask what evidence would demonstrate compliance or justified exception. If the team cannot describe what compliance looks like, the principle lacks measurable implications.
4. Ask whether the principle could ever be legitimately overridden. If overriding is unthinkable, the principle might be a constraint rather than a principle. If overriding is easy and costless, the principle has no teeth. Good principles sit in between: they can be overridden, but only through a formal exception process with a waiver that records the justification.
5. If the answer is still vague, the principle is not ready. Send it back for rework. It is better to have four sharp principles than fourteen decorative ones.

Recognising weak principles is as important as writing strong ones. Here are the most common patterns:

• They sound universal but create no design constraint. "We will use best-in-class technology" sounds good but cannot tell an architect what to do when two vendor options each claim to be best-in-class.
• They cannot be tested during a governance review. If a reviewer cannot look at a design proposal and determine whether it complies with the principle, the principle is not specific enough.
• They duplicate corporate values without architecture implications. "We value innovation" is a corporate value. It does not tell the architecture team what reuse policy to follow, what diversity to tolerate in the technology landscape, or what evidence to require when a team wants to introduce a new platform.
• They conflict with one another because nobody has defined which consequence matters most. "Minimise cost" and "Maximise resilience" will inevitably conflict. Without a priority hierarchy or a mechanism for resolving conflicts, the principles cancel each other out.
• They have a statement but no implications. This is the most common structural failure. The principle sounds reasonable as a rule but does not specify what changes in practice when it is applied. Without implications, there is no accountability.

The London case needs principles that address the specific tensions the architecture will face. These are not generic principles borrowed from a template. Each one responds to a real pressure visible in the London context.

Principle 1: Evidence before exposure

• Statement: No data, model, or figure shall be exposed to external audiences (including the regulator, NESO, or the public) until it has passed through a defined evidence-quality gate.
• Rationale: London Grid operates in a regulated environment where published data carries legal and reputational weight. Publishing unvalidated data has previously led to formal regulatory challenges and public confusion about network capacity.
• Implications: Every external data publication must have a named data steward. Quality gates must be defined and documented before the publication channel is created. Systems that bypass the quality gate require a formal exception from the Architecture Board.

Principle 2: Safety and operability first

• Statement: Architecture decisions must not degrade the safety or operability of the live electricity network. Where a design change creates operational risk, the risk must be assessed and accepted by operations leadership before implementation.
• Rationale: London Grid distributes electricity to millions of premises. Any architecture change that compromises network safety or operability could endanger life and cause widespread service disruption.
• Implications: All architecture proposals that touch SCADA, DMS, or operational telecoms must include an operability impact assessment. Operations leadership holds a veto over changes that affect live network control. Transition plans must demonstrate that operability is maintained at every intermediate state.

Principle 3: Interoperability by design

• Statement: Systems and data stores must be designed to exchange information using open standards and documented interfaces. Proprietary lock-in is acceptable only where no open alternative exists and a formal exception is recorded.
• Rationale: London Grid's systems must exchange data with NESO, Ofgem reporting systems, and third-party developers. Proprietary interfaces create integration barriers that increase cost and reduce flexibility.
• Implications: New system procurements must include interoperability requirements in the specification. Where CIM or other industry standards exist, they are the default. Vendor proposals that rely on proprietary interfaces must justify the departure and identify the exit strategy.

Principle 4: One published truth per date

• Statement: Every published number must carry a state, date context, and authority trail. Where multiple channels publish the same figure, all must reference the single authoritative record for that date.
• Rationale: Inconsistent data publication erodes regulatory trust, creates confusion for planning decisions, and undermines public confidence in the distributor's evidence base. London Grid has experienced cases where different teams published conflicting figures for the same metric.
• Implications: Every data-publication channel must reference the single authoritative record. Derived or cached versions must be declared and carry refresh timestamps. A data steward must be named for each published dataset. Exception requests go through the Architecture Board with documented justification.

Principle 5: Cyber spans OT, IT, and telecoms

• Statement: Cyber resilience evidence and controls must cover the operational technology, information technology, and telecommunications estates as one integrated perimeter. Siloed security assessments that cover only one domain are not accepted as sufficient.
• Rationale: London Grid's OT security depends on the integrity of telecoms links between substations and control rooms, and on the IT systems that manage authentication and data storage. A security assessment that covers only enterprise IT misses the attack vectors that matter most.
• Implications: Security architecture views must show trust boundaries across all three estates. Penetration testing and resilience exercises must include OT and telecoms scenarios. The cyber team must review all architecture proposals that touch network control, monitoring, or communication systems.

Notice how each principle traces back to a real London pressure. Evidence before exposure responds to the regulatory trust problem. Safety and operability first responds to the network safety obligation. Interoperability by design responds to the multi-party data exchange requirement. One published truth per date responds to the data-consistency problem. Cyber spans OT, IT, and telecoms responds to the converged-estate security challenge.

A London principle pack should change data publication rules, exception handling, and review evidence. If a principle does not alter the release or design conversation, it is still unfinished.