48.2 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 48-1 should prove useful in formulating an IT compliance strategy.
Figure 48-1: Levels of Architecture Conformance
The phrase "In accordance with" in Figure 48-1 means:
- Supports the stated strategy and future directions
- Adheres to the stated standards (including syntax and semantic rules specified)
- Provides the stated functionality
- Adheres to the stated principles; for example:
- Open wherever possible and appropriate
- Re-use of component building blocks wherever possible and appropriate
48.3 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:
- First and foremost, catch errors in the project architecture early, and thereby reduce the cost and risk of changes required later in the lifecycle. 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 to management the status of technical readiness of the project.
- Identify key criteria for procurement activities (e.g. for inclusion in Commercial Off-The-Shelf (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
- Areas for consideration for integration into the architectures as they are uncovered by the compliance processes
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.
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 lifecycle. Specific checkpoints should be included as follows:
- Development of the architecture itself (ADM compliance)
- Implementation of the architecture(s) (architecture compliance)
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 lifecycle, which may have an impact on timing.
48.3.3 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 architects or project leaders pose to themselves, 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 practicing 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 enterprise 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 led 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 (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.
48.4 Architecture Compliance Review Process
The Architecture Compliance review process is illustrated in Figure 48-2 .