Architecture Compliance

Introduction    Terminology    Project Impact Assessments   Architecture Compliance Reviews   Review Process      Review Checklists      Review Guidelines


Ensuring the compliance of individual projects with the Enterprise Technical Architecture is an essential aspect of IT Governance. To this end, the IT Governance function within an enterprise will normally define two complementary processes:

Apart from defining formal processes, the IT Governance function may also stipulate that the Architecture function should extend beyond the role of architecture definition and standards selection, and participate also in the technology selection process, and even in the commercial relationships involved in external service provision and product purchases. This may help minimise the opportunity for misinterpretation of the Technical Architecture, and maximize the value of centralized commercial negotiation.


Terminology - the Meaning of "Architecture Compliance"

A key relationship between the architecture and the implementation lies in the definitions of the terms "conformant", "compliant", etc. While terminology usage may differ between organizations, the concepts of levels of conformance illustrated in Figure 1 should prove useful in formulating an IT Compliance Strategy.

architecture conformance levels

Figure 1: Levels of Architecture Conformance


"In accordance with" in Figure 1 means:


Project Impact Assessments ("Project Slices")


A project slice is a project specific subset of the Technical Architecture. It is written in order to illustrate how the Technical Architecture impacts on the major projects within the organization.

The structure of the description for each project is:

Introduction Describes the project's business objectives, the applications being deployed, the major service qualities required for the project, and the assumptions and constraints.
Target Architecture Mapping Shows the Business Process Domain and Target architecture coverage of the Project, provides a System Schematic, breaks down the application into its Logical Partitioning and its Physical Topology and (if relevant) a provides a Product Table.
Project Development Process Overview Provides the project's Key Milestones, Release Schedule and a Roles, Responsibilities & Contacts Table.
Future Directions Briefly outlines known future directions for the project.
References Lists appropriate project documentation for further detail.


Much of this information will normally come from the projects themselves, and is not originated by the architect.

Project Impact Assessments will normally be developed as an output of Phase D of the ADM.

It is important to note that, besides the ADM, an organization will often have other relevant methodologies - in particular, for Project Management - that will have an input here.

There is also an important link to the IT governance strategy. Defining a Project Impact Assessment is only worthwhile if Project Managers take notice of the impact!


Architecture Compliance Reviews

An architecture compliance review is a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives. A formal process for such reviews normally forms the core of an enterprise architecture compliance strategy.


The goals of an architecture compliance review include some or all of the following:

Apart from the generic goals related to quality assurance outlined above, there are additional, more politically oriented, motivations for conducting architecture compliance reviews, which may be relevant in particular cases:


Compliance reviews are held at appropriate project milestones or checkpoints in the project's life cycle.

The Architecture Compliance Review is typically targeted for a point in time when business requirements and the enterprise IT architecture are reasonably firm, and the project architecture is taking shape, well before its completion.

The aim is to hold the review as soon as practical, at a stage when there is still time to correct any major errors or shortcomings, with the obvious proviso that there needs to have been some significant development of the project architecture in order for there to be something to review.

Inputs to the architecture compliance review may come from other parts of the standard project life-cycle, which may have an impact on timing.

Governance and Personnel Scenarios

In terms of the governance and conduct of the architecture compliance review, and the personnel involved, there are various possible scenarios:

In all cases, the Architecture Compliance Review process needs the backing of senior management, and will typically be mandated as part of corporate IT Governance policies. Normally, the enterprise CIO or enterprise Architecture Board will mandate architecture reviews for all major projects, with subsequent annual reviews.


Compliance Review Process


The Architecture Compliance Review process is illustrated in Figure 2.

architecture compliance review process

Figure 2: Architecture Review Process

The main roles and steps in the process are tabulated below.


No. Role Responsibilities Notes
1 Architecture Board To ensure that IT architectures are consistent and support overall business needs. Sponsor and monitor architecture activities.
2 Project Leader (or Project Board) Responsible for the whole project  
3 Architecture Review Co-ordinator To administer the whole architecture development and review process More likely to be business oriented than technology oriented
4 Chief Architect To ensure that the architecture is technically coherent and future proof. An IT architecture specialist
5 Architect One of the Chief Architect's technical assistants  
6 Customer To ensure that business requirements are clearly expressed and understood Manages that part of the organization that will depend on the success of the IT described in the architecture
7 Business Domain Expert To ensure that the processes to satisfy the business requirements are justified and understood Knows how the business domain operates; may also be the customer.
8 Project principals To ensure that the architects have a sufficiently detailed understanding of the customer department's processes. They can provide input to the Business Domain expert or to the architects Members of the Customer's organisation who have input to the business requirements that the architecture is to address


No Action Notes Who
1 Request architecture  review As mandated by IT Governance Policies and Procedures Anyone, whether IT or business oriented, with an interest in or responsibility for the business area affected
2 Identify responsible part of organization and relevant Project Principals   Architecture Review Co-ordinator
3 Identify Chief Architect and other Architects   Architecture Review  Co-ordinator
4 Determine scope of review Identify which other business units / departments are involved.

Understand where the system fits in the corporate architecture framework.

Architecture review Co-ordinator
5 Tailor checklists To address the business requirements. Chief Architect
6 Schedule Architecture Review meeting   Architecture Review Co-ordinator with collaboration of Chief Architect
7 Interview Project Principals To get background and technical information:
  • for internal project - in person
  • for COTS - in person or via RFP

Use checklists.

Chief Architect and/or Architect, Project Leader and Customers
8 Analyze completed checklists Review against corporate standards.

Identify and resolve issues.

Determine recommendations.

Chief Architect

9 Prepare architecture review report May involve supporting staff. Chief Architect
10 Present review findings To Customer

To Architecture Board

Chief Architect
11 Accept review and sign off   Architecture Board


12 Send Assessment Report / Summary to Architecture Review Co-ordinator   Chief Architect


Compliance Review Checklists

The following review checklists provide a wide range of typical questions that may be used in conducting Architecture Compliance Reviews, relating to various aspects of the architecture.  The organization of the questions includes the basic disciplines of system engineering, information management, security and systems management. The checklists are based on material provided by an Open Group member, and are specific to that organization. Other organizations could use the following checklists with other questions tailored to their own particular needs.

The checklists provided here contain too many questions for any single review: they are intended to be tailored selectively to the project concerned (see guidelines below). The checklists actually used will typically be developed / selected by subject matter experts. They are intended to be updated annually by interest groups in those areas.

Some of the checklists include a brief description of the architectural principle that provokes the question, and a brief description of what to look for in the answer. These extensions to the checklist are intended to allow the intelligent re-phrasing of the questions, and to give the user of the checklist a feel for why the question is being asked.

Occasionally the questions will be written, as in RFPs, or in working with a senior project architect. More typically they are expressed orally, as part of an interview or working session with the project.

The checklists provided here are designed for use in individual architecture projects, not for business domain architecture or for architecture across multiple projects. (Doing an architecture review for a larger sphere of activity, across multiple business processes and system projects, would involve a similar process, but the checklist categories and their contents would be different.)


Compliance Review Guidelines

Guidelines for Tailoring the Review Checklists

Guidelines for Conducting Architecture Compliance Reviews

Copyright The Open Group, 1999, 2001