6.4 Architecture Contracts, Dispensations & Compliance Reviews
Key Takeaways
- Architecture Contracts formalize governance relationships between architecture bodies, business sponsors, and solution implementers.
- Dispensations provide a formal, time-bound mechanism to temporarily permit non-compliant solutions under strict risk controls.
- Architecture Compliance Reviews utilize systematic audit checklists across business, data, application, technology, and security domains.
- The Architecture Board evaluates dispensation requests, assessing business urgency, technical impact, risk mitigation, and expiration timelines.
- Formal compliance reviews prevent architectural debt, ensure accountability, and maintain alignment with baseline standards.
6.4 Architecture Contracts, Dispensations & Compliance Reviews
Effective enterprise architecture governance requires formal administrative mechanisms to enforce compliance, manage variations, and maintain architectural integrity during solution delivery. While architecture models and blueprints define what should be built, Architecture Contracts, Dispensations, and Architecture Compliance Reviews provide the governance frameworks that ensure implementation teams actually deliver solutions in accordance with those blueprints.
Without formal contracts and review mechanisms, enterprise architecture becomes advisory rather than mandatory. Conversely, without a structured dispensation process, architecture governance becomes an inflexible bottleneck that impedes business agility. TOGAF provides a balanced, pragmatic governance model that enforces compliance while offering formal escalation and exemption paths when legitimate business constraints arise.
Architecture Contracts: Binding Governance Agreements
An Architecture Contract is a joint agreement that formalizes the commitments, responsibilities, and governance boundaries between the enterprise architecture organization, business sponsors, and implementation project teams. It transforms abstract architectural principles into contractual requirements.
Primary Categories of Architecture Contracts in TOGAF
TOGAF defines three distinct operational categories of Architecture Contracts:
- Architecture Board & Business User Contract: Establishes agreement between executive business sponsors and the Architecture Board regarding strategic goals, architectural vision, funding, and expected business capability outcomes.
- Architecture Board & Architecture/Development Team Contract: Binds internal engineering teams, solution architects, and project managers to deliver solutions adhering to specified Target Architectures, standards, and non-functional requirements.
- Enterprise Architecture & Supplier/Partner Contract: Formulates legally binding requirements with external system integrators, software vendors, and cloud service providers, specifying architecture standards compliance, SLA guarantees, and audit rights.
+-------------------------------------------------------------------------+
| TYPES OF ARCHITECTURE CONTRACTS |
+------------------------------------+------------------------------------+
| BUSINESS USER CONTRACT | DEVELOPMENT TEAM CONTRACT |
| - Strategy & Capability Scope | - Technical Standards Baseline |
| - Funding & Business Objectives | - Non-Functional Requirements |
+------------------------------------+------------------------------------+
|
v
+-------------------------------------------------------------------------+
| SUPPLIER / VENDOR CONTRACT |
| - External Vendor Compliance - SLA Guarantees & Audit Rights |
+-------------------------------------------------------------------------+
The Formal Dispensation Process
A Dispensation is a formal, time-bound authorization granted by the Architecture Board that permits an implementation project to temporarily or permanently deviate from specified enterprise architecture standards, principles, or target blueprints.
When is a Dispensation Warranted?
Dispensations are not intended to excuse poor planning or unauthorized shortcuts. Legitimate scenarios requiring a formal dispensation include:
- Critical Business Urgency: Unforeseen market opportunities or emergency regulatory deadlines that require deploying an interim solution before target infrastructure is fully available.
- Legacy Integration Barriers: Technical incompatibilities in legacy systems where full compliance is technically impossible without an unbudgeted multi-million-dollar modernization.
- Vendor Capability Gaps: Third-party commercial off-the-shelf (COTS) software that satisfies 95% of business needs but lacks native compliance with a specific security or protocol standard.
- Prohibitive Cost-Benefit Ratio: Situations where achieving 100% compliance incurs disproportionate expenditure relative to business value generated.
The Step-by-Step Dispensation Workflow
1. Submission ---> 2. Risk Assessment ---> 3. Board Review ---> 4. Conditional Approval ---> 5. Tracking
- Request Submission: The Project Lead or Solution Architect submits a formal Dispensation Request detailing the non-compliant component, technical rationale, and business justification.
- Impact & Risk Assessment: The EA team evaluates the security, operational, and architectural risks associated with granting the exemption.
- Architecture Board Review: The Architecture Board convenes to evaluate the request, impact analysis, and proposed risk mitigations.
- Conditional Decision: The Board approves or denies the dispensation. Approved dispensations are time-bound (e.g., valid for 12 months) and carry explicit conditions, such as mandatory risk controls or a commitment to remediate upon contract expiration.
- Tracking & Register Maintenance: The dispensation is cataloged in the Enterprise Architecture Repository's Governance Log for continuous tracking and expiration monitoring.
Conducting Architecture Compliance Reviews
An Architecture Compliance Review is a structured audit conducted at defined project milestones (e.g., Architecture Gate, Detailed Design Gate, Pre-Production Gate) to verify that solution delivery aligns with enterprise standards and the Architecture Contract.
Goals of a Compliance Review
- Identify architectural errors, security risks, and technical debt early in the project lifecycle.
- Ensure solution building blocks (SBBs) conform to reusable enterprise architecture building blocks (ABBs).
- Verify adherence to non-functional requirements (scalability, availability, security, performance).
- Provide feedback to update baseline architecture standards based on real-world delivery insights.
Architecture Compliance Review Checklists
Compliance reviews utilize domain-tailored checklists to systematically audit project deliverables:
| Domain Checklist | Key Audit Items & Verification Criteria |
|---|---|
| Business Architecture | Capability mapping, process alignment, organizational roles, business continuity considerations. |
| Data Architecture | Master Data Management (MDM) adherence, data dictionary mapping, data protection, privacy (PII) controls. |
| Application Architecture | API design standards, microservice boundaries, containerization compliance, integration patterns. |
| Technology Architecture | Infrastructure standards, cloud service selection, network topology, backup/DR configuration. |
| Security & Governance | Identity and Access Management (IAM), encryption baselines, vulnerability scanning, audit logging. |
Managing Non-Compliance & Escalation Paths
When a Compliance Review uncovers Non-conformant elements, the review team documents the findings and presents them to the project team and Architecture Board. The governance escalation workflow proceeds as follows:
+-------------------------------------------------------------------------+
| COMPLIANCE AUDIT FINDINGS |
+-------------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------------+
| NON-COMPLIANCE CLASSIFICATION |
+------------------------------------+------------------------------------+
| MINOR NON-COMPLIANCE | MAJOR NON-COMPLIANCE |
| - Non-critical guideline drift | - Security vulnerability |
| - Documentation omission | - Architecture contract breach |
+------------------------------------+------------------------------------+
|
v
+-------------------------------------------------------------------------+
| ESCALATION & DECISION GATE |
| OPTION A: Mandatory Remediation Plan |
| OPTION B: Submit Formal Dispensation Request to Architecture Board |
| OPTION C: Amend Target Architecture Baseline |
+-------------------------------------------------------------------------+
By combining binding Contracts, disciplined Compliance Reviews, and formal Dispensations, TOGAF delivers a comprehensive governance environment that balances rigor with operational adaptability.
Which of the following best defines a 'Dispensation' in TOGAF architecture governance?
What happens when an approved Dispensation reaches its specified expiration date?
Which type of Architecture Contract governs the relationship between enterprise architects and external third-party system integrators or software vendors?