Nato AF (NAF) Version 4 - A Look at the Definition of View Content

This is a first of what will be many dives into the definition of the NAF v4 looking this time at the definition of view content - a prerequisite for achieving consistency in the exchange / interoperability of architecture descriptions.

This is a first take looking at the definition of view content - a prerequisite for achieving consistency in the exchange / interoperability of architecture descriptions.

Architecture frameworks represent a form of standardisation. They seek to ensure consistency and increase the exchangeability / interoperability of architecture descriptions through:-

• defining a restricted and controlled “grammar” or vocabulary for describing or making statements about the system of interest and its place with respect to the Residual World. This is usually achieved by defining a metamodel that provided the nodes and connectors to produce the views. Defined properly the metamodel provides a set of statements or assertions (‘tuples’) that can be used, for example: ‘System is configured with Software’ , ‘Contract applies Standard’ or ‘Evidence proves Claim’.
• defining consistent view content by defining what architecture description elements (really tuples) must and may appear in each view. This is important not only in terms of ergonomics (visibility and affordance) so that the reader knows where to find or what to expect in each view in terms of subject matter but also when either exchanging or working collaboratively with other offices or organisations - typical MBSE practice when producing an integrated model of the system of interest.
• defining consistency rules that apply across the collection of views forming the architecture description e.g. if ‘System A is configured with ‘Software B’ in one view and ‘System C is configured with Role D’ then if Software B exchanges information with Role D in another view it must also be true that System A has an interface with System C.

Anyway the first part of this examination looks at how well NAF v 4 can achieve consistency of view content.

The NATO Architecture Framework (NAF) version 4 is now with us and is a substantial change to the previous version 3. As we’ve highlighted there were problems in the closeness of NAF vs MODAF which led to the demise of MODAF. MODAF does, however, still live on in the work that seems to be happening to the NAF metamodel termed MODEM. Bizarrely though the NAF version 4 does not make reference to this as the metamodel preferring to make some woolly references to the ability to use ArchiMate or the UAF as the metamodel. This will be the subject of another post but it’s impossible to ensure consistency if you don’t mandate / control the set of bits from which the architecture description is formed.

The defining baseline for NAF v 4 is the document - NATO Architecture Framework. Version 4. Architecture Capability Team. Consultation, Command and Control Board. January 2018

Background

The NATO Architecture Framework version 4 (January 2018)  definition identifies reasons for change:

1.5 Reason for Change

1.5.1 NAF version 3 (NAFv3) was issued in 2007 to support alliance interoperability through the coherent use of architectures, and provide for the re-use of architecture artefacts and products to facilitate the description of systems and applications. However, NAFv3:

• was not consistently applied by projects,
• did not provide a common architecture approach,
• became challenging to maintain due to limited technical resources, and
• did not align with major terms and concepts in the following international standards:
• ISO/IEC/IEEE 42010 Systems and Software Engineering – Architecture Description,

....

1.5.2 NAFv4 addresses the above limitations and is a step towards a single Architecture Framework across NATO and Nations.

and its purpose is:

1.1.4 The NATO Architecture Framework (NAF) provides a standardized way to develop architecture artefacts, by defining:

• Methodology – how to develop architectures and run an architecture project (Chapter 2),
 
• Viewpoints – conventions for the construction, interpretation and use of architecture views for communicating the enterprise architecture to different stakeholders (Chapter 3)

Not Yet Consistent with ISO/IEC/IEEE 42010

There were problems in the use of terminology not the least was that MODAF and NAF used different terms to refer to views and view definitions and neither aligned with the international standard for architecture description, ISO/IEC/IEEE 42010. In highlighting the previous lack of conformance with ISO/IEC/IEEE 42010 version 4 should now presumably conform. It does repeat some of the definitions but unfortunately a lot of the old misuse still persists and there is at least one misunderstanding:

‘1 Introduction

1.1 Architecture Descriptions

1. A Viewpoint is where you are looking from.’

No. A ‘ISO42010::Viewpoint’ is a specification for a view. ISO/IEC/IEEE 42010 is quite clear on this:

A view is governed by its viewpoint: the viewpoint establishes the conventions for constructing, interpreting and analyzing the view to address concerns framed by that viewpoint. Viewpoint conventions can include languages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and other operations on views.

The ‘NAF4::Viewpoint’ harks back to the use of ‘viewpoint’ in MODAF which meant something quite different.

Chapter 2 - Methodology

1.1 The NATO Architecture Framework version 4 (NAFv4) is a standard for developing architectures.

No - it is a standard for developing architecture descriptions - the architectures are the real world things that care not about viewpoints or metamodels and can’t be stored on hard drives. Their descriptions can, however. This is a constant and historical misuse or failure to understand the difference between ‘architecture’ and its description in the version 3 and now version 4 documentation. The ISO/IEC/IEEE 42010 Conceptual model is quite clear about the distinction between System, Architecture and Architecture Description.

There is a fundamental problem if alignment is sought with TOGAF because TOGAF does not recognise that there are these 3 independent concepts - it only supports 2 - it doesn’t recognise the difference between architecture and its description. NAF has made a problem for itself in that it is impossible to comply with both ISO/IEC/IEEE 42010 and TOGAF since their conceptual models are different and the terms mean different things. NAF needs to pick a consistent set of standards to adhere to if it wants to assure consistency of output of architecture descriptions.

This gets confusing where architecture description and architecture views are used to highlight issues with the real world architecture. The ‘architecture’ term is consistently misused in the names of NAF views e.g. A7 - Architecture Meta-Data (‘concerned with the meta-data for the architecture and its Views’ - should be architecture description).

5.14 Architecture Framework

Architecture Framework TOGAF v9.1, page 45]: “is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

NAF v4 claims to conform to ISO/IEC/IEEE 42010:2011. The standard defines architecture framework as:-

architecture framework

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

It says nothing about tools or target state.

Conforming to a standard means that you use terms in the sense that the standard defines - it doesn’t mean pick and choose from any other source at will.

Chapter 5 - The Structure of the NATO Architecture Framework

1.5.1 The NAF is designed to ensure that architectures developed adhering to it can be understood, compared3, justified and related across many organizations, including NATO and other National Defence initiatives.

Ignoring the incorrect use of ‘architecture’ (NAF are repeat offenders in misuse of ISO/IEC/IEEE 42010 terminology) it is clear that the intent is that there is a a set of requirements for architecture descriptions conforming to the NAF. The assumption has to be that it is this document that forms the specification for NAF Views since there is no other document containing User Requirements (to put it in military terms).

So where exactly are the requirements against which users can produce NAF views?

NAF 4 Requirements for View Content

NAF 4 uses the correct term, viewpoint, as a specification for a view content. Previously in NAF 3 a view was a collection term and a subview referred to a particular definition.

Consistency requires an unambiguous set of requirements defining the content of each view (otherwise different architectures will produce wildly different content).

A typical example of the specification of a view against which a “NAF-compliant” architecture description must conform is the C1 - Capability Taxonomy (Chapter 3 Concept Viewpoints, page 74):

Looking at this in terms of the specification of view content:-

Definition of NAF v4 - C1 Capability Taxonomy View

• what are the architecture description elements (nodes, connectors forming tuples) that are required? Note that specifying nodes alone is not sufficient to unambiguously specify content - this is one of the reasons why a tuple should be the smallest unit of architecture description
• what is the minimum acceptable content?
• what is the allowed content - usually for extra context?
• what are the properties of the elements needed to address the concerns?
• what are the allowed overlaps with other views?
• where are the consistency requirements defining how this impacts the collection of views in the architecture description?

In terms of addressing the original need to improving consistency this does nothing.

At least in the old NCV-2 definition it stated that you required Operational Objective and Capability elements which although not sufficient or complete was a lot better than the current view definition.

If consistency is really the aim NAF ought to spend less effort on presentation and organising via the new (Zachman-esque) matrix and focus on the content as a specification. If there is no specification of view content then consistency will never be achieved.

External Links

• NATO Architecture Framework. Version4. - home page
• NATO Architecture Framework Version 4 (January 2018)