Togaf 9.2 Architecture Compliance Review

[Giorgina Makara]

Ensuringthe compliance of individual projects with the enterprise architecture is an essential aspect of architecture governance (see 50. Architecture Governance). To this end, the IT governance function within an enterprise will normally define two complementary processes:

Apart from defining formal processes, the architecture governance (see 50. 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 to minimize the opportunity for misinterpretation of the enterprise 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 48-1 should prove useful in formulating an IT compliance strategy.

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.

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

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.

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 (see 50. Architecture Governance). Normally, the enterprise CIO or enterprise Architecture Board (see 47. Architecture Board) will mandate architecture reviews for all major projects, with subsequent annual reviews.

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 a member of The Open Group, 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 contain too many questions for any single review: they are intended to be tailored selectively to the project concerned (see 48.6 Architecture Compliance Review Guidelines). 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.)

Ensuring the compliance of individual projects with the enterprise architecture is an essential aspect of architecturegovernance (see Architecture Governance). To this end, the IT governance function withinan enterprise will normally define two complementary processes:

Apart from defining formal processes, the architecture governance (see ArchitectureGovernance) function may also stipulate that the architecture function should extend beyond the role of architecturedefinition and standards selection, and participate also in the technology selection process, and even in the commercialrelationships involved in external service provision and product purchases. This may help to minimize the opportunity formisinterpretation of the enterprise 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 inLevels of Architecture Conformance should prove useful in formulating an IT compliance strategy.

A "project slice" is a project-specific subset of the enterprise architecture. It is written in order to illustrate how theenterprise architecture impacts on the major projects within the organization.

There is also an important link to the architecture governance strategy (see ArchitectureGovernance). 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 architecturalcriteria, spirit, and business objectives. A formal process for such reviews normally forms the core of an enterprise ArchitectureCompliance strategy.

Apart from the generic goals related to quality assurance outlined above, there are additional, more politically-orientedmotivations for conducting Architecture Compliance reviews, which may be relevant in particular cases:

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

The Architecture Compliance review is typically targeted for a point in time when business requirements and the enterprisearchitecture 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 orshortcomings, with the obvious proviso that there needs to have been some significant development of the project architecture inorder for there to be something to review.

In all cases, the Architecture Compliance review process needs the backing of senior management, and will typically be mandatedas part of corporate architecture governance policies (see Architecture Governance).Normally, the enterprise CIO or enterprise Architecture Board (see Architecture Board)will mandate architecture reviews for all major projects, with subsequent annual reviews.

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

The checklists provided contain too many questions for any single review: they are intended to be tailored selectively to theproject concerned (see Architecture Compliance Review Guidelines). The checklists actually used willtypically be developed/selected by subject matter experts. They are intended to be updated annually by interest groups in thoseareas.

Some of the checklists include a brief description of the architectural principle that provokes the question, and a briefdescription of what to look for in the answer. These extensions to the checklist are intended to allow the intelligent re-phrasingof 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 areexpressed 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 orfor architecture across multiple projects. (Doing an architecture review for a larger sphere of activity, across multiple businessprocesses and system projects, would involve a similar process, but the checklist categories and their contents would bedifferent.)

3a8082e126