Login  ·  Register

TRAK Community  ::  Wiki  ::  NAF:NAF 3.1
Search Wiki  
  

Enterprise Architecture

Navigation - General

Keep Up to Date

Active Members:

Search:

 

Create or Find Page:

 

View NAF:NAF 3.1

NATO_logo.gif

Version 3.1

From Notice AC/322(SC/1-WG/1)N(2009)0005-ADD2:

1. At Ref (a) the C3 PWG agreed NAF RFCP CH 5/0001/2009 on the understanding that the comments from Germany would be incorporated. Following NAF Management Syndicate work by Sweden, enclosed at Annex 1 is a final version of NAF Chapter 5 v 3.1 and at Annex 2 the completed responses to the comments from Germany.

2. At its 9th meeting the C3 PWG agreed Ref (b) to defer the associated revisions of NAF v3 chapters 3, 4 and 7.

Covered by NATO release conditions.

Significant Changes

Note: This is based on a full -text comparison as the full NAF 3.1 documentation set with a baseline isn’t yet available.

Views & Subviews

In terms of the subview set this increases from a total of 47 at NAF 3.0 to 49 in NAF 3.1.

The comparison in size between the NAF Views at NAF 3.1 (NAF 3.0) is:NATO Capability View (NCV)

  • 6* (7) subviews

  • NATO Operational View (NOV)

    • 9 (9) subviews

  • NATO Service-Oriented View (NSOV)

    • 8* (5) subviews

  • NATO Systems View (NSV)

    • 18 (18) subviews

  • NATO Technical View (NTV)

    • 3 (3) subviews

  • NATO Programme View (NPV)

    • 2 (2) subviews

    • See how this compares with other frameworks.

    Subview Changes

    Metamodel

    Update to metamodel brings the NMM in line with the MODAF metamodel (M3) v 1.2.003.

    • NAF::Information Exchange - new definition - no longer a specification of the information exchanged but a collection of Information Items
    • NAF::Needline - new definition - no longer represents a need but a collection of Information Exchanges
    • NAF::Software  - new


    From para 5.2.6.1, Chapter 5:

    Resources
    The way resources are modelled has changed in NAF version 3.1. The changes appear subtle, but are significant in terms of enabling re-use of architectural data. The main change is the introduction of a strong distinction between what a resource is, and how it is used in a particular architecture. In terms of the intrinsic type of resource, the following are possible:

    • Organisational Resources – types of roles, types of organisations, types of post
    • Artefacts – physical objects made for a purpose
    • Software – executable code
    • Physical Architectures – configurations of resources for a purpose – e.g. Capability Configurations

    Once defined, the intrinsic resource types can be re-used from architecture to architecture – it is expected that the most commonly re-used elements would be Physical Architectures and Capability Configurations. The following are the ways in which the resource types can be used:

    • Physical Asset – an artefact may be used as a platform or a system
    • Human Resource – usage of an organisational resource in a physical architecture or capability configuration
    • Part – an artefact that is a component of another artefact
    • Hosted Software – software implemented on a system (artefact)
    • Software Component – software code which is part of a larger executable (enables re-use of class libraries, sub-routines, etc.)
    • Used Configuration – a physical architecture or capability configuration being used in another physical architecture or capability configuration
    • Post – usage of a post type in an organisation
    • Role – usage of a role type in a post
    • Sub-Organisation – usage of an organisation type in another organisation type

    These different ways to employ the same type of resource allow greater re-use. For example, a type of warship doesn’t need to be defined twice, once as a platform and once as a system. It is specified once as an artefact and then can be used with the appropriate context in multiple architectures.

    Covered by NATO release conditions

    The problem being addressed is an inability to share models because in one model an element might be ‘platform’, in another the same real-world thing might be represented as ‘system’ or simply an ‘artefact’ or indeed a ‘capability configuration’. The root cause of the problem is a semantic one as the concepts of platform, system etc overlap and aren’t exclusive. The architect/modeller has to choose a single stereotype and therefore this choice results in diversity/inconsistency. The addition of usage context further complicates the framework and makes it harder to use/understand - particularly when presented to non-architects. It would have been better to address the root cause of the problem and reduce the choices / rationalise the metamodel structure. See https://trak-community.org/index.php/residualWorld/a_system_is_a_system_right_not_if_youre_head_modelling

    This is one of the areas where TRAK deviates from MODAF/NAF.

    Capability Configuration

    From para 5.2.6.1, Chapter 5:

    A Capability Configuration is a combination of organisational resources (with their competencies) and equipment that combine to provide a capability. A Capability Configuration is a combination of Artifacts (be they termed Systems or Platforms) or Organisational Resource configured with other Resources (System, Roles, other Capability Configurations, Software) to provide a capability. A physical resource contributing to a capability must either be an organisational resource or a physical asset, i.e. a system cannot contribute alone (it must be hosted on a physical asset or used by
    an organisational resource or both).

    Covered by NATO release conditions

    A system cannot contribute alone -  doesn’t accord with current definitions of what a system is and you can’t add Human Resource to a System (so people can’t be part of a system). The definition in NAF 3.1. has changed to The usage of an artefact as a System in a CapabilityConfiguration. - doesn’t actually define what a system is. In 3.0 it was A coherent combination of physical artefacts, energy and information, assembled for a purpose.

    Functions
    NAF version 3 made a distinction between resources that could carry out functions (as defined in NSV-4) and those that could not. A simplified model has been adopted in NAF version 3.1, where any resource is allowed to have functions.
    ...

    Interactions
    In NAF version 3, interactions were only possible between Functional Resources (Systems, Roles & Capability Configurations). NAF v3.1 states that any resource becomes functional if there is a function associated with it. Therefore any Resource can interact.

    Covered by NATO release conditions

    This makes NAF much more useful.

    Comment

    Chapter 5 of the NATO Architecture Framework deals with the NATO Architecture Framework Metamodel (NMM). For each of the NAF Subviews it presents the appropriate part of the metamodel together with simplified metamodel fragments and definitions of the metamodel stereotypes.

    Chapters 3, 4 and 7 cover:

    • CHAPTER 3 - NNEC Architecture Concepts and Elements
    • CHAPTER 4 - Architecture Views and Subviews
    • CHAPTER 7 - Architecture Definitions, Terminology and Ontology

    and clearly need to be consistent with the NAF 3.1 metamodel.

    There is no change record in this document which makes assessing change difficult. It is believed that one of the motivations is to bring the NMM in line with MODAF 1.2.003. There may be other changes.

    Previous Versions

    See NAF 3.0 and the full NAF Release History.

    References

    • Notice. AC/322(SC/1-WG/1)N(2009)0005-ADD2. 1st March 2010.
    • NATO Architecture Framework Version 3. NATO Architecture Framework Metamodel (ADES) CHAPTER 5 (NMM) and Architecture Data Exchange Specification. ANNEX 1 TO AC/322(SC/1-WG/1)N(2009)0005-ADD2. https://www.nhqc3s.nato.int/Browser.asp?Target=_docs/NAF_v3_1
     

    © 2010 Eclectica Systems Ltd.