Compliance, waivers, and architecture contracts

G21H (Architecture Compliance) is the TOGAF Series Guide that defines how compliance reviews should work. The guide provides a structured process for determining whether an implementation conforms to the architecture. Understanding G21H is essential because ad hoc compliance checking produces exactly the false confidence described in the opening story.

The five conformance categories

G21H defines five conformance categories, each representing a different relationship between the implementation and the target architecture. These categories prevent compliance from collapsing into a binary yes/no assessment.

1. Irrelevant. The architecture has no coverage of the implementation area. No conformance assessment applies. This category is important because it prevents the governance process from claiming jurisdiction over areas the architecture has not addressed.
2. Consistent. The implementation appears aligned with the architecture but has not been explicitly verified against every requirement. This is the most common initial state: the implementation looks right but formal testing has not been completed.
3. Compliant. The implementation fully satisfies all architecture requirements that apply. Every applicable requirement has been checked and the implementation meets the standard.
4. Conformant. The implementation is fully compliant and has also been verified through formal review. This is the strongest category: not only does the implementation satisfy the requirements, but a structured review has confirmed that satisfaction.
5. Non-conformant. The implementation does not satisfy one or more architecture requirements. This category triggers the exception and waiver process. Non-conformance is not automatically a governance failure. It becomes a governance failure only when it is invisible or unmanaged.

The governance response should be different for each category. An implementation that is consistent but not yet formally verified needs a scheduled review. An implementation found non-conformant needs either correction, rejection, or a governed waiver. Treating all categories the same defeats the purpose of the graduated model.

The structured review steps

G21H describes a structured compliance review process with the following steps.

1. Identify the scope of the review. Determine which architecture requirements apply to the implementation being reviewed. Not every requirement applies to every project. The scope determination prevents the review from becoming an open-ended audit.
2. Gather evidence. Collect the implementation evidence needed to assess conformance. This includes design documents, test results, configuration records, and any deviation documentation.
3. Assess conformance. Compare the implementation evidence against the applicable requirements and assign a conformance category for each requirement area.
4. Record findings. Document the conformance assessment, including the category assigned, the evidence examined, and any conditions or follow-on actions required.
5. Report to the Architecture Board. Present the findings to the governance forum with recommendations for action. The board decides whether to accept, require correction, or grant a waiver.

The distinction between rule compliance and intent compliance is not explicit in TOGAF but emerges from practical governance experience and from the G21H emphasis on conformance rather than mere documentation completeness. Understanding both layers is essential because the opening story shows what happens when an enterprise checks only one.

Rule compliance

Rule compliance asks: has the design met the formal standards, controls, and obligations that apply at this stage? This includes technical standards (approved integration patterns, data formats, security controls), regulatory requirements (Ofgem data publication standards, NCSC cyber controls), and architecture principles (published and ratified by the Architecture Board). Rule compliance is necessary but not sufficient. An implementation that ticks every formal box can still undermine the architecture's purpose.

Intent compliance

Intent compliance asks: does the design still preserve the architecture's deeper purpose even after local compromises? Intent compliance checks whether the implementation preserves customer clarity, evidence quality, interoperability, resilience, and future coherence. The bank in the opening story passed rule compliance (every checklist completed) but failed intent compliance (fourteen projects had undermined the architecture's purpose by creating non-standard patterns, bypassing authentication, and duplicating master data).

Intent compliance is harder to assess than rule compliance because it requires judgement rather than checklist verification. The reviewer must understand what the architecture was trying to achieve, not just what it formally specified, and then assess whether the implementation preserves that achievement.

Conditional alignment

Conditional alignment asks: can the change move forward temporarily because compensating controls, follow-on work, and review conditions are explicit and bounded? This is the governed middle ground between full compliance and rejection. It is where waivers live. Conditional alignment is a mature governance response that acknowledges reality while preserving visibility and control.

The three-layer model (rule, intent, conditional) gives the governance process the vocabulary to handle real-world situations. Pure binary compliance (pass or fail) forces the enterprise into either pretending everything is fine or rejecting everything that deviates. The three-layer model allows honest assessment with proportionate response.

When a compliance review identifies non-conformance, the enterprise has three options: fix the deviation, reject the implementation, or grant a waiver. Waivers are not a sign of governance failure. They are a sign that the enterprise is mature enough to acknowledge reality while preserving visibility and control. However, an unhealthy waiver is worse than no waiver because it creates the illusion of governance while accumulating unmanaged architecture debt.

A healthy waiver contains six elements. The absence of any element weakens the waiver's governance value.

1. Deviation description. A clear, specific statement of what the implementation does differently from the target architecture and why. Vague descriptions like "minor deviation from standard" are not acceptable because they prevent future reviewers from understanding the actual deviation.
2. Enterprise consequence. An honest assessment of the impact the deviation creates for the wider enterprise. This includes technical debt, future integration cost, resilience impact, and regulatory risk. The consequence assessment should be specific enough that the Architecture Board can weigh the trade-off rationally.
3. Business justification. A clear explanation of why the deviation is the right trade-off given current constraints. The justification must be specific enough that a future reviewer can understand the reasoning. "We ran out of time" is an explanation; it is not a justification unless it also explains why the timeline constraint outweighed the architecture consequence.
4. Compensating controls. Any measures put in place to reduce the impact of the deviation while it persists. For example, additional monitoring, manual reconciliation, restricted access, or enhanced audit logging. Compensating controls acknowledge that the deviation creates risk and describe how that risk is managed.
5. Expiry condition. A date or trigger by which the deviation must be resolved, reviewed, or formally extended. This is the element most commonly missing from waivers. Open-ended waivers accumulate into unmanaged architecture debt because nobody is accountable for resolving them. The expiry condition should be realistic but non-negotiable: the waiver expires, and if the deviation has not been resolved, it must be re-submitted for fresh approval.
6. Governance approval. Formal approval from the appropriate governance forum. Material deviations should be approved by the Architecture Board. Bounded deviations within a single domain may be approved by the domain architect with notification to the board. The approval should be recorded in the exception register with a reference to the board meeting or delegated authority that granted it.

C220 Part 5 defines an architecture contract as a joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. The contract makes the agreement between architecture and delivery explicit rather than assumed.

What an architecture contract contains

In practical terms, an architecture contract defines what the delivery team has agreed to build, what conformance criteria will be used to verify the result, what happens if the implementation deviates from the agreed architecture, and what review points exist during delivery. It is not a legal document. It is a governance instrument that prevents the common situation where architecture produces a target and delivery builds something different without anyone formally acknowledging the gap.

The contract typically includes the following elements:

• Scope and boundary. What the delivery team is building and what falls outside the contract. This prevents scope creep in both directions.
• Conformance criteria. The specific architecture requirements that the implementation must satisfy, drawn from the Architecture Definition Document and the architecture principles.
• Review points. When and how conformance will be assessed during delivery. Typically aligned with project stage gates or sprint boundaries.
• Exception escalation. What happens when the delivery team discovers it cannot conform. The contract should define the escalation path (waiver request to the Architecture Board) rather than leaving teams to improvise.
• Signatories. The named individuals who commit to the contract on behalf of architecture and delivery. The mutuality is important: an architecture contract is not imposed by the architecture team on delivery. It is a mutual commitment.

When architecture contracts add most value

Architecture contracts are most valuable in three situations:

• Cross-team handoffs. When architecture work is handed to a delivery team that did not participate in the architecture design, the contract ensures the delivery team understands and accepts the conformance expectations before work begins.
• External delivery partners. When third parties or outsourced teams are responsible for implementation, the contract provides a formal conformance benchmark that survives personnel changes and vendor transitions.
• Regulated milestones. When a transition step has regulatory consequence, the contract ensures that architecture conformance criteria are agreed before delivery begins rather than improvised during assurance review.

Compliance is not a single event. It is a cycle that connects delivery behaviour to governance decisions through a chain of evidence. Understanding the full flow prevents the enterprise from treating compliance as a one-off checklist.

1. Architecture contract agreed. The delivery team and the architecture function agree the conformance criteria before delivery begins.
2. Delivery produces evidence. During delivery, the team produces design documents, test results, configuration records, and deviation documentation. This evidence accumulates as the artefacts that the compliance review will examine.
3. Compliance review at milestone. At each agreed review point, a G21H compliance review assesses the evidence against the conformance criteria and assigns a conformance category.
4. Findings reported to board. The compliance findings are presented to the Architecture Board with recommendations. Non-conformances are accompanied by waiver requests or correction plans.
5. Board decides. The board reviews the findings and decides: accept, require correction, or grant a waiver with the six required elements.
6. Repository updated. The compliance record, decision log, and exception register are updated within 24 hours. The compliance evidence is now part of the governance memory.
7. Waiver expiry tracked. Active waivers are monitored against their expiry conditions. Before expiry, the waiver is either resolved (deviation fixed), extended (with fresh approval), or escalated (if neither resolution nor extension is possible).

This cycle ensures that compliance evidence flows continuously from delivery through to governance, and that governance decisions flow back to delivery as accepted constraints, waiver conditions, or correction requirements.

London operates under Ofgem regulation with specific obligations around data publication, cyber resilience, customer service standards, and network reliability. That regulatory context makes compliance particularly important because architecture deviations can create regulatory risk, not just technical debt.

Rule compliance in London

• Data publication components must conform to the approved information authority model and the LTDS (Long Term Development Statement) requirements.
• Cyber-relevant components must meet the baseline controls defined in alignment with the NCSC Cyber Assessment Framework.
• Customer-facing systems must meet the connection offer timescale standards required by Ofgem.
• Network operational technology must conform to the approved OT/IT boundary architecture.

Intent compliance in London

• Does the data publication pipeline preserve the information authority rules that prevent conflicting sources of truth?
• Does the cyber architecture maintain the separation and monitoring principles that protect operational resilience?
• Does the customer connections process preserve the end-to-end visibility that prevents customers from falling into process gaps?
• Does the network technology architecture maintain the interoperability that future regional energy planning will require?

Example London waiver

A delivery team implementing a new connection-offer calculation engine discovers that the approved integration pattern cannot meet the required response time under peak load. They request a waiver to use a direct database query instead of the approved API gateway for a six-month period.

• Deviation: Direct database access bypassing the API gateway for the connection-offer calculation under peak load.
• Enterprise consequence: Reduced auditability and monitoring for connection-offer calculations during peak periods. The API gateway provides audit logging and rate limiting that the direct query bypasses.
• Justification: The connection offer timescale standard required by Ofgem cannot be met under peak load using the current API gateway configuration. The response-time requirement outweighs the audit gap for a bounded period.
• Compensating controls: Additional database logging and a manual reconciliation process for connection offers calculated during peak periods.
• Expiry: Six months from approval date, conditional on the API gateway performance issue being resolved within the waiver period.
• Governance approval: Architecture Board, with a condition that the API gateway team reports progress at each monthly board meeting.