Architecture Compliance

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

Introduction

Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of Architecture 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 Enterprise Architecture that illustrate how the Enterprise 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 Enterprise Architecture.

Apart from defining formal processes, the Architecture 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 Enterprise 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.

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

Project Impact Assessments ("Project Slices")

Introduction

A project slice is a project specific subset of the Enterprise Architecture. It is written in order to illustrate how the Enterprise 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(s) Mapping	Shows the Business 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.

Sources

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 E 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 Architecture 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.

Purpose

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

First and foremost, catch errors in the project 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 standards
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
Take advantage of advances in technology
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 function.
Architecture reviews can demonstrate rapid and positive support to the enterprise business community.
- 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.

While compliance to architecture is required for development and implementation, non-compliance also provides a mechanism for highlighting:

Areas to be addressed for realignment, but just as importantly
Areas for consideration for integration into the architectures as they are uncovered by the compliance processes.

The latter point identifies the ongoing change and adaptability of the architectures to requirements that may be driven by indiscipline, but also allows for changes to be registered by faster moving changes in the operational environment. Typically dispensations (see IT Governance) will be used to highlight these changes and set in motion a process for registering, monitoring and assessing the suitability of any changes required.

Timing

Timing of compliance activities should be considered with regard to the development of the architectures themselves.

Compliance reviews are held at appropriate project milestones or checkpoints in the project's life cycle. Specific checkpoints should be included as follows:

Development of the architecture itself (ADM compliance - see governance / architecture development)
Implementation of the architecture(s) (architecture compliance - see governance / architecture implementation)

Architecture project timings for assessments should include:

Project initiation
Initial design
Major design changes
Ad hoc

The Architecture Compliance Review is typically targeted for a point in time when business requirements and the enterprise 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:

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 responsibilities.

In all cases, the Architecture Compliance Review process needs the backing of senior management, and will typically be mandated as part of corporate Architecture 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

Overview

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.

Roles

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	Lead Architect	To ensure that the architecture is technically coherent and future proof.	An IT architecture specialist
5	Architect	One of the Lead 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

Steps

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 Lead 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.	Lead 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 Customer
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

Focus on:
- High risk areas
- Expected (and emergent) differentiators
For each question in the checklist, understand:
- The question itself
- The principle behind it
- What to look for in the responses
Ask subject experts for their views.
Fix the checklists questions for your use
Bear in mind the need for feedback to the architecture board

Guidelines for Conducting Architecture Compliance Reviews

Understand clearly the objectives of those soliciting the review; and stay on track and deliver what was asked for. For example, they typically want to know what is right or wrong with the system being architected; not what is right or wrong with the development methodology used, their own management structure, etc. It is easy to get off track and discuss subjects that are interesting and perhaps worthwhile, but not what was solicited. If you can shed light and insight on technical approaches, but the discussion is not necessary for the review, volunteer to provide it after the review.
If it becomes obvious during the discussion that there are other issues that need to be addressed, which are outside of the scope of the requested review, bring it up with the meeting chair afterwards. A plan for addressing the issues can then be developed in accordance with their degree of seriousness.
Stay “scientific”. Rather than “we like to see large databases hosted on ABC rather than XYZ”, say things like, “The downtime associated with XYZ database environments is much greater than on ABC database environments. Therefore we don’t recommend hosting type M and N systems in an XYZ environment."
Ask "open” questions, i.e. questions that do not presume a particular answer.
There are often “hidden agendas” or controversial issues among those soliciting a review, which you probably won’t know up front. A depersonalized approach to the discussions may help bridge the gaps of opinion rather than exacerbate them.
Treat those being interviewed with respect. They may not have built the system "the way it should be", but they probably did the best they could under the circumstances they were placed in.
Help the exercise become a learning experience for you and the presenters.
Reviews should include detailed assessment activities against the architectures and should ensure that the results are stored in the Enterprise Continuum.