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:
- The Architecture function will be required to prepare a series of Project Impact Assessments - project-specific views of the
Technical Architecture that illustrate how the Technical Architecture impacts on the major
projects within the organization. (These are sometimes referred to as project slices
through the architecture.)
- The IT Governance function will define a formal Architecture
Compliance Review process, for reviewing the compliance of projects to the Technical
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.
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.
Figure 1: Levels of Architecture Conformance
"In accordance with" in Figure 1 means:
- supports the stated strategy and futures directions
- adheres to the stated standards (including syntax and semantic rules specified)
- provides the stated functionality
- adheres to the stated principles, e.g.
- open wherever possible and appropriate
- re-use of components / building blocks wherever possible and appropriate
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:
||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
||Provides the project's Key Milestones, Release
Schedule and a Roles, Responsibilities & Contacts Table.
||Briefly outlines known future directions for the
||Lists appropriate project documentation for further
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
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
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!
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
The goals of an architecture compliance review include some or all of the following:
- First and foremost, catch errors in the porject architecture early, and thereby reduce
the cost and risk of changes required later in the life-cycle. This in turn means that the
overall project time is shortened, and that the business gets the bottom-line benefit of
the architecture development faster.
- Ensure the application of best practices to architecture work
- Provide an overview of the compliance of an architecture to mandated enterprise
- 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 synergies across
multiple architecture teams
- Communicate the status of technical readiness of the project to management
- Identify key criteria for procurement activities (e.g., for inclusion in COTS product
RFI / RFP documents)
- Identify and communicate significant architectural gaps to product and service providers
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:
- The architecture compliance review can be a good way of deciding between architectural
alternatives, since the business decision-makers typically involved in the review can
guide decisions in terms of what is best for the business, as opposed to what is
technically more pleasing or elegant.
- The output of the architecture compliance review is one of the few measurable
deliverables to the CIO to assist in decision-making.
- Architecture reviews can serve as a way for the Architecture organization to engage with
development projects that might otherwise proceed without involvement of the Architecture
- Architecture reviews can demonstrate rapid and positive support to the enterprise
- The enterprise architecture and architecture compliance helps ensure the alignment of IT
projects with business objectives.
- Architects can sometimes be regarded as being deep into technical infrastructure and far
removed from the core business.
- Since an architecture compliance review tends to look primarily at the critical risk
areas of a system, it often highlights the main risks for system owners.
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.
In terms of the governance and conduct of the architecture compliance review, and the
personnel involved, there are various possible scenarios:
- For smaller scale projects, the review process could simply take the form of a series of
questions that the project architect or project leader poses to him or herself, using the
checklists provided below, perhaps
collating the answers into some form of project report to management. The need to conduct
such a process is normally included in overall enterprise-wide IT governance policies.
- Where the project under review has not involved a practising or full-time architect to
date (for example, in an application level project), the purpose of the review is
typically to bring to bear the architectural expertise of an enterprise architecture
function. In such a case the enterprise architecture function would be organizing, leading
and conducting the review, with the involvement of business domain experts. In such a
scenario, the review is not a substitute for the involvement of architects in a project,
but it can be a supplement or a guide to their involvement. It is probable that a database
will be necessary to manage the volume of data that would be produced in the analysis of a
large system or set of systems.
- In most cases, particularly in larger scale projects, the Architecture function will
have been deeply involved in, and perhaps leading, the development project under review.
(This is the typical TOGAF scenario.) In such cases, the review will be co-ordinated by
the lead architect, who will assemble a team of business and technical domain experts for
the review, and compile the answers to the questions posed during the review into some
form of report. The questions will typically be posed during the review by the business
and technical domain experts. Alternatively the review might be lead by a representative
of an "Architecture Board" or some similar body with enterprise-wide
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.
The Architecture Compliance Review process is illustrated in Figure 2.
Figure 2: Architecture Review Process
The main roles and steps in the process are tabulated below.
||To ensure that IT architectures are consistent and support overall
||Sponsor and monitor architecture activities.
||Project Leader (or Project Board)
||Responsible for the whole project
||Architecture Review Co-ordinator
||To administer the whole architecture development and review process
||More likely to be business oriented than technology oriented
||To ensure that the architecture is technically coherent and future proof.
||An IT architecture specialist
||One of the Chief Architect's technical assistants
||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
||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.
||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
||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
||Identify responsible part of organization and relevant Project Principals
||Architecture Review Co-ordinator
||Identify Chief Architect and other Architects
||Architecture Review Co-ordinator
||Determine scope of review
||Identify which other business units / departments are involved.
Understand where the system fits in the corporate architecture
|Architecture review Co-ordinator
||To address the business requirements.
||Schedule Architecture Review meeting
||Architecture Review Co-ordinator with collaboration of Chief Architect
||Interview Project Principals
||To get background and technical information:
- for internal project - in person
- for COTS - in person or via RFP
|Chief Architect and/or Architect, Project Leader and Customers
||Analyze completed checklists
||Review against corporate standards.
Identify and resolve issues.
||Prepare architecture review report
||May involve supporting staff.
||Present review findings
To Architecture Board
||Accept review and sign off
||Send Assessment Report / Summary to Architecture Review Co-ordinator
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