Architecture guidelines and techniques

NAR, in accordance with TOGAF, distinguishes between Guidlines and Techniques. While Guidelines serve as a guide for adapting an architectural framework to the conditions and needs of a particular agency, Techniques are guides and tools for the sub-processes of architecture creation and maintenance.

Guidelines for Adapting NAR to the Local Authority Framework

The content of the NAR is applicable to all obligated entities, see above, in its entirety as is, except for provisions that are demonstrably irrelevant to a particular OVS.

The basic guidelines for adapting the NAR to the office include those already mentioned above:

Establish and manage responsibilities for the creation and maintenance of architectures - Meta-architecture, architecture of architectures, see Modeling Offices and their Architectures.

Implement mandatory architectural engagements and add custom types, see Process of creating architectures.

Select an adequate subset of metamodel objects between minimum and maximum, see Architectures content and output framework

Select the adequate types of deliverable outputs and their architectural artifacts according to the necessary considerations, see Content and Output Architectures Framework

Regularly assess the architectural capabilities of the Authority, determine their required level and implement measures to achieve it, see Process of architecture creation.

Beyond the NAR, the OVS may add additional rules, metamodel objects, their attributes, diagram types, deliverables, roles and responsibilities, and so on in its local Authority Architecture Creation, Maintenance and Use Methodology.

Recommendations for Architecture Technicians

Here, practice-tested techniques that support the creation, management and use of office architectures, described in a practical and instructive way, will gradually appear in the office architecture management methodology.

Such techniques may include:

Business scenarios

Gap analysis of existing and target architectures

Risk analysis and management

Change readiness assessment

Architecture practice maturity assessment, etc.

Currently, no techniques already verified by the pilot projects are documented and thus only the original descriptions of the techniques in the original TOGAF documentation are available to authority architects.

Many of the NAR techniques are also general ICT management techniques that NAR (as well as TOGAF) preferably adopts, and therefore will be presented primarily in the document ICT Management Methods of the Czech Republic.

Architectural Practice Maturity Assessment

When first building or improving an authority's architectural capability, it is advisable to use the technique of Architecture Maturity Assessment( )).

This technique uses questions in a questionnaire, typically structured into 8-10 categories, to determine how good an authority is or would like to be in each aspect of architectural capability. The current NAR tool, based on the TOGAF, offers three questions in each of the following areas:

Process of creating and maintaining architecture	Dissemination and communication of architecture
Architecture Development	Architecture & IT Governance
The relationship between strategy and IT	Architects - People
The Management Connection	Influence and Implications of Architecture

Table - Categories for assessing architectural maturity.

An example of a practical application of architectural maturity assessment.

A description of the practical approach and the accelerator (table with questionnaire and chart) is part of the NA VS Knowledge Base.

Architectural Principles

The NAR specifies the necessary scope and format for describing architectural principles in the structure:

Identifier

Name

Statement (content)

Rationale

Implications

Exceptions

Binding principles

Control questions

Control data: Obligation, Revision condition, Revision date

Quality of architectural principles

A good set of principles expresses the true shared beliefs and values of a company. The principles are expressed in clear and usable language. Principles should be few in number, should be forward-looking, and should be supported and enforced by real leaders.

Here is a set of five criteria to help identify a good set of principles:

Understandable - easy for anyone to grasp and understand. There is no question about their importance * Robust - they allow good and easy decision making in matters of architecture, even in potentially controversial situations. * Complete - cover all situations that may arise. * Consistent - the interpretation of one principle cannot contradict others. Must be balanced. * Stable** - principles should be permanent but be able to accommodate change. There must be an amendment process for additions, changes or replacements to the principles once adopted.

Detailed descriptions of the architectural principles P1 - P17, as formulated and approved in the ICCR, will be published in the NA VS Knowledge Base, supplemented by control questions and further interpretations and explanations.

At the same time, a sample form for the description of the actual architectural principle of the OVS and a template for the deliverable Catalogue of Principles will be available here. If a separate Catalogue of Principles is not created, the OVS principles are formulated, approved and published through the OVS Information Concept.

Architectural Patterns

According to NAR, an architectural pattern is a building block of architecture that is a successful solution to a specific need. A guide and accelerator for working in and with architectural patterns is part of the NAR NAR Knowledge Base.

There, too, specific architectural patterns for practical use in OVS architectures will be added incrementally by OHA.