11.4 Architecture Compliance
Key Takeaways
- TOGAF's six levels of architecture conformance are Irrelevant, Consistent, Compliant, Conformant, Fully Conformant, and Non-conformant.
- A Compliant implementation implements some specified features, and all features it implements are covered by and in accordance with the specification.
- A Conformant implementation implements all specified features in accordance with the specification but also has extra features not in accordance with it.
- Any implementation in which some specified features are implemented not in accordance with the specification is Non-conformant.
- The first purpose of an Architecture Compliance review is to catch errors in the project architecture early, reducing the cost and risk of later changes.
11.4 Architecture Compliance
The Foundation syllabus asks you to briefly explain the need for Architecture Compliance. Compliance is how an organization checks that projects actually implement the Enterprise Architecture — and it is one of the most precisely worded areas of TOGAF, especially the six levels of conformance.
The Need for Architecture Compliance
Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of architecture governance. TOGAF describes two complementary processes:
- The architecture function prepares project architectures — project-specific views of the Enterprise Architecture that illustrate how it affects each major project.
- The IT governance function defines a formal Architecture Compliance review process for reviewing the compliance of projects with the Enterprise Architecture.
The Six Levels of Conformance
TOGAF defines conformance by comparing the features in the architecture specification with the features in the implementation:
| Level | Definition |
|---|---|
| Irrelevant | The implementation has no features in common with the architecture specification, so the question of conformance does not arise |
| Consistent | The implementation has some features in common with the specification, and those common features are implemented in accordance with it. However, some specified features are not implemented, and the implementation has other features not covered by the specification |
| Compliant | Some features in the specification are not implemented, but all features implemented are covered by the specification, and in accordance with it |
| Conformant | All the features in the specification are implemented in accordance with it, but some more features are implemented that are not in accordance with it |
| Fully Conformant | There is full correspondence between specification and implementation: all specified features are implemented in accordance with the specification, and there are no features implemented that are not covered by it |
| Non-conformant | Any of the above in which some features in the specification are implemented not in accordance with the specification |
How to Tell Them Apart
| Question | Irrelevant | Consistent | Compliant | Conformant | Fully Conformant |
|---|---|---|---|---|---|
| Are all specified features implemented? | No common features | No | No | Yes | Yes |
| Are all implemented features covered by the specification? | — | No | Yes | No | Yes |
If any specified feature is implemented incorrectly, the result is Non-conformant, whatever else is true.
Purpose of Architecture Compliance Reviews
A compliance review is a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives. TOGAF lists purposes such as:
- First and foremost, catch errors in the project architecture early, reducing the cost and risk of changes later in the lifecycle
- Ensure the application of best practices to architecture work
- Identify where the standards themselves may require 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 other synergy across teams
- Take advantage of advances in technology
- Communicate the status of technical readiness of a project to management
- Identify key criteria for procurement activities
- Identify and communicate significant architectural gaps to product and service providers
The Compliance Review Process
Typical steps include:
- Request an architecture review
- Identify the responsible part of the organization and relevant project principals
- Identify the lead enterprise architect and other architects
- Determine the scope of the review
- Tailor checklists
- Schedule the architecture review meeting
- Interview project principals
- Analyze completed checklists
- Prepare the Architecture Compliance review report
- Present the review findings
- Accept the review and sign off
- Send the assessment report or summary to the architecture review coordinator
Roles typically include the Architecture Board, the project leader (or project board), the customer, the lead enterprise architect, other architects, and the project principals. Checklists usually cover areas such as hardware and operating systems, software services and middleware, applications, information management, security, system management, system engineering, and methods and tools.
The output recorded in the ADM is a Compliance Assessment (Phase G).
Dispensations
When a compliance assessment is rejected because a subject area is not compliant, the subject area can either be adjusted or realigned to meet the compliance requirements or request a dispensation. Dispensations provide an alternate route to interim conformance: they are granted for a given time period and set of identified services and operational parameters that must be enforced. When the dispensation expires, the subject area must go through the compliance assessment process again.
Scenario: Classifying a Review Result
An architecture specification for a customer portal defines five features: single sign-on, the standard API gateway, encrypted data at rest, audit logging, and accessibility compliance. The delivered portal implements all five correctly and adds an unapproved chat widget that sends data to an external service outside the specification. Because every specified feature is implemented in accordance with the specification but an extra feature is not in accordance, the result is Conformant, not Fully Conformant. If the audit logging had been implemented incorrectly, the result would be Non-conformant.
Common Exam Pitfalls
- Assuming "Compliant" is better than "Conformant." Compliant means only some specified features are implemented (all implemented ones covered); Conformant means all specified features are implemented, plus some extra.
- Defining Consistent as "similar in spirit." Consistent has a precise meaning: some common features implemented correctly, some specified features missing, and some features not covered.
- Forgetting Non-conformant overrides. Any incorrectly implemented specified feature makes the result Non-conformant.
- Treating dispensations as permanent. They are granted for a given period and parameters, then re-assessed.
An implementation delivers all features in the architecture specification in accordance with it, and nothing beyond the specification. Which conformance level applies?
Which statement defines the Compliant level of architecture conformance?
According to TOGAF, what is first and foremost the purpose of an Architecture Compliance review?
What happens when a dispensation granted after a rejected compliance assessment expires?