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.

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.

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.

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:

Table - Categories for assessing architectural maturity.

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

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.

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.