10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists

10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists

The TOGAF Standard describes an Architecture Compliance review as a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives. A formal review process normally forms the core of an enterprise's Architecture Compliance strategy. Phase G's step "Perform Enterprise Architecture Compliance reviews" applies it to each implementation project, and the resulting Compliance Assessments are a Phase G output held in the Governance Repository. A compliance strategy is one of three elements of an effective governance strategy, together with an Architecture Board and Architecture Principles.

---

Why Compliance Reviews Are Held

TOGAF lists the goals of a review. First and foremost is to catch errors in the project architecture early, reducing the cost and risk of change later and shortening the project. Other goals include:

• Ensure best practices are applied to architecture work.
• Give an overview of the architecture's compliance with mandated enterprise standards.
• Identify where the standards themselves may need modification.
• Identify services that are currently application-specific but might be provided as part of the enterprise infrastructure.
• Document strategies for collaboration, resource sharing, and synergies across architecture teams.
• Take advantage of advances in technology.
• Communicate the status of business and technical readiness to management.
• Identify key criteria for procurement, such as RFI and RFP content for COTS products.
• Identify and communicate significant architectural gaps to product and service providers.

TOGAF also notes more political benefits. A review can help decide between architectural alternatives, because business decision-makers in the review favor what is best for the business. It produces one of the few measurable deliverables for executives. It gives the architecture function a way to engage projects that might otherwise bypass it.

Non-compliance is not only a failure signal. It highlights areas to realign and areas to consider for integration into the architecture. Dispensations register such changes and start a process for assessing them.

---

The Six Levels of Architecture Conformance

TOGAF defines conformance by comparing the features in the architecture specification with the features in the implementation. Memorize the levels in these terms:

TOGAF explains that "in accordance with" means the implementation supports the stated strategy and future direction, adheres to the stated standards (including syntax and semantic rules), provides the stated functionality, and adheres to the stated principles, such as being open where appropriate and reusing building blocks.

Quick test: check whether anything specified was implemented wrongly (Non-conformant). Then check whether everything specified was implemented. Finally, check whether anything unspecified was added. A project that implements only part of the specification but adds nothing outside it is Compliant. A project that implements all of it but adds non-conforming extras is Conformant.

---

When to Review

TOGAF separates checkpoints for the development of the architecture itself (ADM compliance) from checkpoints for its implementation (architecture compliance). Project timings for assessments include:

• Project initiation
• Initial design
• Major design changes
• Ad hoc reviews

The review is typically targeted at a point when business requirements and the Enterprise Architecture are reasonably firm and the project architecture is taking shape, well before completion, while there is still time to correct major errors. Normally the CIO or Architecture Board mandates reviews for all major projects, with subsequent annual reviews.

Who Runs the Review

TOGAF describes three scenarios. A small project may review itself using the checklists. A project with no practicing architect may have the review led by the EA function, with business domain experts involved. Most commonly, in larger projects (the typical TOGAF scenario), the Lead Enterprise Architect coordinates the review with a team of business and technical domain experts, or a representative of the Architecture Board leads it.

---

Roles and the Twelve-Step Process

Roles: Architecture Board; Project Leader (or Project Board); Architecture Review Co-ordinator, who administers the process and is more likely business-oriented than technology-oriented; Lead Enterprise Architect; Architect; Customer; Business Domain Expert; and Project Principals.

Steps:

1. Request architecture review (anyone with an interest in the business area may request it, as mandated by governance policies)
2. Identify the responsible part of the organization and the relevant project principals (Review Co-ordinator)
3. Identify the Lead Enterprise Architect and other architects (Review Co-ordinator)
4. Determine the scope of the review (Review Co-ordinator)
5. Tailor the checklists to address the business requirements (Lead Enterprise Architect)
6. Schedule the Architecture Review Meeting (Review Co-ordinator with the Lead Enterprise Architect)
7. Interview project principals, using the checklists (Lead Enterprise Architect and/or Architect, Project Leader, and Customers)
8. Analyze completed checklists against corporate standards and determine recommendations (Lead Enterprise Architect)
9. Prepare the Architecture Compliance review report (Lead Enterprise Architect)
10. Present review findings to the Customer and the Architecture Board (Lead Enterprise Architect)
11. Accept the review and sign off (Architecture Board and Customer)
12. Send the assessment report or summary to the Review Co-ordinator (Lead Enterprise Architect)

TOGAF also mentions a model-based alternative. Solution architects trace their elements to the Enterprise Architecture model through "drill-down" diagrams, so tools can partly automate conformance checks.

---

The Compliance Review Checklists

TOGAF provides example checklists covering:

• Hardware and Operating System
• Software Services and Middleware
• Applications (infrastructure and business-specific)
• Information Management
• Security
• System Management
• System Engineering/Overall Architecture
• System Engineering/Methods and Tools

The checklists deliberately contain too many questions for any single review. They are meant to be tailored to the project, typically by subject matter experts, and updated annually by interest groups. They are designed for individual projects; a review across several processes or projects would use different categories.

---

After the Review

The Architecture Board and the customer accept and sign off the review. Where an implementation is not compliant, TOGAF's governance framework gives two routes: adjust or realign the design to meet the requirements, or request a dispensation. Dispensations are granted for a given time period with identified service and operational criteria that must be enforced while they last, and their time-bound nature makes them a trigger in the compliance cycle (Section 12.3). Compliance assessments are recorded in the Governance Repository.

---

Common Exam Traps

• Using informal "mandatory versus optional" definitions. TOGAF's levels compare specified features with implemented features. Decide on that basis.
• Reviewing only at go-live. TOGAF targets reviews well before completion, while errors can still be fixed.
• Using every checklist question. The checklists are meant to be tailored.
• Treating a dispensation as permanent. Dispensations are time-bound and trigger later compliance activity.