Nato Architecture Framework (NAF) - 3.1 - NATO All View

title

NAF - Part 3.1 - NATO All View

author

Bernard Szlachta (NobleProg Ltd)

NAV-1, Overview and Summary Information。

• provides executive-level summary information in a consistent form that allows quick reference and comparison between architectures
• NAV-1 includes assumptions, constraints, and limitations that may affect high-level decisions relating to the architecture.

Example

NAV-1, Overview and Summary Information。

Definition

The NAV-1 product is a summary of a given architecture effort, documenting the following:

• Architecture Project Identification
  • the architecture project name
  • the architects
  • the organisation developing the architecture
  • the assumptions and constraints
  • the approving authority and the completion date
  • the records the level of effort and costs (projected and actual) required to develop the architecture

• Scope
  • the views and subviews that have been developed
  • the temporal nature of the architecture
    • the time frame covered, whether by specific years or by designations such as current, target, transitional, and so forth
  • the organisation that fall within the scope of the architecture

NAV-1, Overview and Summary Information。

Definition

• Purpose and viewpoint
  • the need for the architecture
  • what it will demonstrate
  • the types of analyses (e.g., Activity-Based Costing) that will be applied to it
  • who is expected to perform the analyses
  • what decisions are expected to be made on the basis of an analysis
  • who is expected to make those decisions, and what actions are expected to result
  • The viewpoint from which the architecture is developed is identified (e.g., planner or decision maker).

• Context (the setting in which an architecture exists)
  • mission, doctrine, relevant goals and vision statements
  • authoritative sources for the rules, criteria, and conventions that were followed.
• Tools and File Formats Used
  • Findings (e.g. identification of shortfalls, recommended system implementations, and opportunities for technology insertion)
  • An initial version may focus the effort and document its scope, the organisation involved
  • Optionally costing information, such as integration costs, equipment costs and other costs

Iterative approach and retrospection。

• After an architecture has been used for its intended purpose, and the appropriate analysis has been completed, yet another version may be produced to summarize these findings for high level decision makers
• In the new version, the NAV-1 product and a corresponding graphic in the form of an NOV-1 product serve as an executive summary of the architecture

Nato Architecture Framework (NAF) - 4.2 - NATO Meta Model - NAV

NAV-2, Integrated Dictionary。

Example

NAV-2, Integrated Dictionary。

Purpose

• To clearly and unambiguously define the terms used to describe the architecture, and to, consequently:
  • provide consistency across subviews;
  • provide consistency across architectures;
  • facilitate architecture development, validation, maintenance, and reuse;
  • trace architecture data to authoritative data sources;

Definition

• The Integrated Dictionary contains definitions of terms used in architecture descriptions, where all definitions provide reference to the information sources.
• NAV-2 allows the set of architectural products to stand alone so that they can be read and understood uniformly
• NAV-2 is an accompanying reference to other products, and its value lies in unambiguous definitions
• The key to long-term interoperability can reside in the accuracy and clarity of these definitions

NAV-2, Integrated Dictionary。

Development Guidance

• The NAV-2 dictionary does not have to be literally a dictionary
• NAV-2 can be used to define terms using:
  • a simple glossary, defining terms in a descriptive way by use of natural language
  • a semantic network, defining terms by defining their (semantic) relations to other terms
  • a taxonomy, defining terms by defining their membership of (and closeness to) classes of terms within a hierarchy
  • an ontology, defining terms by defining the essential being of concepts that underlie the terms
  • or as a combination of the above
• It is much preferred to reference authoritative sources, rather than defining new terms in an architecture
• Many terms exist that transcend architecture projects and are unique to a domain
• These terms should be established outside any architecture effort and referenced as such
• The dictionary may distinguish different categories of terms
  • For example, the category of terms used in the operational domain that is the subject of the architecture effort, and the category of terms that represent the technical terms used to describe architectural elements, such as node, service and system.
• The latter category of terms is already defined in the NMM (refer to NAF-chapter 5)

NAV-2, Integrated Dictionary。

Supporting NNEC Architecture Elements

For the development of this subview the modelling of the following NNEC architecture elements are essential:

• Operational object
• Information object
• Information product

Exercise。

Define term Aeroplane using

1. a simple glossary (Who? What? When? Where? Why?)
2. a semantic network
3. a taxonomy
4. an ontology (extra exercise, as ontologies hasn't been defined so far in NMM)

http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html

Nato_Architecture_Framework_(NAF)_-_4.2_-_NATO_Meta_Model_-_NAV#NAV-2_Integrated_dictionary

NAV-3 Metadata

NAV-3a, Architecture Compliance Statement (Metadata)。

Purpose

• To certify (officially state) that an architecture satisfies all applicable (externally) imposed criteria to a required degree
• The criteria in question are documented in the NAF
• The objective is also to communicate to the stakeholders of the architecture effort, and to other architects, that an architecture meets the requirements of the NAF.

NAV-3a, Architecture Compliance Statement (Metadata)。

Definition

• The NAF is a guidance document.
• It does not direct which subviews are mandatory for which types of NATO architectures.
• The NAF is also flexible in that it allows user defined subviews and deviation from existing subviews, if so required to achieve the objectives of the architecture effort.
• Consequently, an architecture compliance statement only makes a statement on:
  • whether an architecture‘s subviews deviate from the subview descriptions in chapter 4 (and to what degree)
  • whether an architecture‘s subviews deviate from the NMM (and to what degree)
  • whether an architecture‘s subviews use terminology that is inconsistent with the definitions of terms described in NAF chapter 7.
• By implication, this means that a fully NAF-compliant architecture must also be fully NMM-compliant.
• Deviations from the NMM must be described in detail in NAV-3b Metadata Extensions.
• If deviations exist, and if these deviations are described correctly, and in detail, in NAV-3b, then the architecture is NAF-compliant to a degree, with the exceptions made in NAV-3b.

NAV-3a, Architecture Compliance Statement (Metadata)。

Definition

• Although the NAF allows for deviation from this chapter‘s guidelines on subviews, it is strongly recommended not to deviate from the subview guidelines, and especially not to deviate from the NMM
• If no deviations are made, the resulting architecture is much more likely to reap the full benefits of the NAF
• I.e. the resulting architecture is:
  • more easily communicated to stakeholders
  • more easily understood by other architects
  • more easily incorporated in or merged with other architectures
  • more easily compared to other architectures
  • more easily interchanged with other architecture tools that support the NMM
  • more easily integrated into other architecture core data repositories that conform to the NMM
• The compliance statement itself can be a simple document, stating that the architecture meets the requirements of the NAF and the NMM.
• The statement should explain to what degree compliance has been met, as it is allowed to deviate from the standard subview templates of the NAF
• Alternatively, the compliance statement can be the set of comments to each or any of the elements of the core architecture data repository that stores the architecture

NAV-3a, Architecture Compliance Statement (Metadata)。

Development Guidance

• To verify whether an architecture‘s subview deviates from the NAF subview guidelines, the following checks must be made (this is not an exhaustive list):
  • Is the subview used inline with its purpose?
  • Is the subview delivered using the suggested products (i.e. diagrams, matrices, lists, specifications, or textual descriptions)
  • Does the subview contain the correct architecture elements?
  • Does the subview use the correct architecture element relationships?
  • Does the subview use the correct architecture element attributes?
  • Are names unique where uniqueness is required?
  • Are elements used consistently when they appear in multiple subviews, or in more detailed versions of the same subview?

NAV-3a, Architecture Compliance Statement (Metadata)。

Development Guidance

• It must be noted, that NAV-3a does not validate the soundness of the design itself.
• Validation of the design is the responsibility of the quality management authority.
• It is quite possible that an architecture is NAF-compliant, but still contains design flaws.
• However, an architecture should not be put through a compliance certification procedure before it has passed (final) quality control successfully
• The compliance certification procedure should be carried out under supervision of a nominated official, e.g. the Chief Architect
• The compliance statement should then be issued by the same official (see chapter 6)

Supporting NNEC Architecture Elements

The development of this subview can be done without modelling specific NNEC architecture elements.

NAV-3b, Metadata Extensions。

Purpose

To document any deviations of the architecture‘s subviews from the standard subview guidelines of the NAF, in terms of deviations from the NMM, which underpins all standard subviews of the NAF.

Definition

• NAF allows user defined subviews and deviation from existing subviews, if so required to achieve the objectives of the architecture effort
• NAV-3a (compliance statement) will state this deviation, but it is the purpose of NAV-3b to document the details of this deviation
• The allowance of metamodel extensions is especially intended to serve the needs of the Nations
• With National extensions in place, the NMM serves as a core metamodel common to all Nations, but with specific enhancements that serve a Nation‘s specific requirements for architectural design
• However, to optimize the architecture data exchange capability between the Nations and between NATO and the Nations, the National extensions should be ideally non-existent, or at least kept to a minimum

In general,everything in a subview must be reflected in the metamodel

NAV-3b, Metadata Extensions。

Definition

• If the metamodel does not provide for customized elements in a subview, then the NMM can be extended to provide for such a customization
• If such a metamodel extension is not provided, then those parts of a subview that are not reflected in the metamodel, can also not be stored in the repository or exchanged with other modelling tools
• However, even when an extension is documented well, the architecture data that uses this extension will not be exchanged with another party if either there is no exchange specification defined (i.e. an XMI-specification, refer to NAF-chapter 5), or the recipient‘s metamodel does not have that same extension in place (e.g. the recipient only has the core NMM).
• It is strongly recommended not to extend the NMM, for the reasons stated earlier in NAV-3a
• Generally, extensions to the metamodel impede exchangeability and understandability of NAF-based architectures
• For the same reasons, an extension is to be taken literally as something that is added
• The NMM itself must not be changed under any circumstances, since this model is intended as a NATO standard for architectures
• A stable and controlled NMM is paramount to guarantee the interoperability between the NATO Nations with regard to the exchange of NATO architecture models and data
• The product of the NAV-3b subview is a metamodel diagram with detailed specifications of each metamodel element, relationship and attribute included in the diagram.
• The product may also include the XMI-specification that enables the exchange of architecture data that uses the extended part of the NMM

NAV-3b, Metadata Extensions。

Development Guidance

• A NAV-3b product is a metamodel diagram
• The diagram should be developed using the same technique and format as used in the presentation of the NMM diagram itself
• The extended metamodel must clearly indicate at which point in the NMM an extension is made, and which NMM metamodel elements are affected by the extension
• Consequently, the NAV-3b metamodel extension diagram must reuse parts of the NMM diagram
• As an extension of the NMM also has an impact on the NMM exchange specification, this specification must be adapted as well
• The adaptation must fully reflect the extensions made to the NMM
• If this is omitted, the resulting architecture cannot fully be exchanged with other tools through XMI-technology
• In such a case, the exchanged architecture model will be incomplete, with only those model elements received that are based on the core NMM, and with those model element missing that are based on any extension of the core NMM
• In such a case, to ensure that recipients of an architecture are well informed when they receive an incomplete architecture, the architecture model elements that have a direct relationship with any missing architecture model elements, should be annotated to indicate that an extension exists at that specific place in the model

Supporting NNEC Architecture Elements

The development of this subview can be done without modelling specific NNEC architecture elements.

Exercises。

Exercise 2 - extending metamodel (only advanced users)

1. In EA architect, create a new extension for NAV-1 Architectural Product, the <<Painting>> Architectural Product
2. Generate XMI for this element
3. View the XMI
4. Start a new project
5. Import the the profile

Nato_Architecture_Framework_(NAF)_-_4.2_-_NATO_Meta_Model_-_NAV#NAV-3_Metadata