This is also available as a downloadable report on ResearchGate: http://dx.doi.org/10.13140/RG.2.2.15015.15521

Summary

In moving from NATO Architecture Framework (NAF) v3 to v4 the metamodel (NMM) has been dropped. There's only a design implementation of it left in the UAF and no longer any input requirements to implement. This isn't how engineering design and traceability should work.

History / Background

The NATO Architecture Framework (NAF) provides a set of architecture views that the system architect can use to describe the architecture of a military system. Like the US DoD Architecture Framework (DODAF) and the UK MOD Architecture Framework (MODAF) NAF has its roots in the US C4ISR Architecture Framework [1, 2]. The current version (4) was first issued in 2018 and updated in 2020.

Figure 1 - NATO Architecture Framework (NAF) Versions

NAF Version 3

Like most architecture frameworks, NAF version 3 [3] is defined by NATO using a documentation set [Figure 2].

Figure 2 - NATO Architecture Framework Version 3 Document Structure (Partial)

The NAF document set at version 3 has five parts but the relevant parts are Chapter 5, which defines the NATO architecture framework metamodel (NMM) and Chapter 4 which defines NAF architecture views and sub-views. The NMM provides the architecture description elements that may appear in the NAF architecture views.

At NAF version 3 this terminology is non-standard and doesn't match ISO/IEC/IEEE 42010 Systems and Software:

Architecture Description. A NAF::Architecture View collects together a set of NAF Sub Views, each of which is supposed to define the content of an individual 42010Architecture View.

As 'sub..' anything denotes a position in a hierarchy, not a type, we have in NAF v3, a view meaning a collection (42010::Architecture Perspective), a specification of an architecture view (42010::Architecture Viewpoint). In NAF v3, like MODAF, there is no term that refers to the product created against the NAF::subview (42010::Architecture Viewpoint).

The version 3 terminology isn't consistent:

In the Framework, there are seven major perspectives (i.e., views ...

A view is defined as a set of subviews grouped by purpose ....

This definition of the term 'subview' is similar to the term 'viewpoint' as defined in the IEEE 1471-2000 standard'

The consistency and other problems are described by Ian Bailey [4].

Most of the issues uncovered in this study are around Chapter 4 of NAF – the chapter that documents the views. This chapter has had multiple editors and was not entirely developed with Chapter 5 (the NAF Meta-Model) in mind. Furthermore, Chapter 5 has been revised since Chapter 4 was released, but there have been no corresponding updates to Chapter 4. As a result, it has a number of issues...

Classic Engineering Lifecycle - Input Requirements vs Design Implementation

NAF v 3 is defined by NATO. It is, or should be, independent of any particular notation modelling language or tool used to produce architecture views for architecture descriptions. Independence isusually also ensured because the specifying organisation (NATO) is separate from any implementing organisation. This is classic engineering practice where the agnostic requirements - "the what" represented by the NAF v3 document set - is separate from the particular implementation of the NAF v3 - "the how" - the design (of how to implement the NAF v3.

For example, if the Unified Modelling Language (UML)[5] is to be used a UML profile is created which implements the NMM elements using UML metamodel elements so that when loaded into a UML modelling tool there is a set of UML elements that can be used to create the various NAF 42010::Architecture Views in a UML modelling tool [Figure 3].

Figure 3 - Implementation of the NAF as a UML Profile for a UML Modelling Tool

The UML is specified by the Object Management Group (OMG) and any organisation can define a UML profile implementing the NAF architecture description elements. Usually the modelling tool vendor spends the effort to define the UML profile implementation for their modelling tool. There are several organisations involved - NATO who define the "master source" requirements, the OMG who define the UML and the UML modelling tool vendors who interpret the NAF requirements to produce a tailored UML profile for each too. As with any design if the input requirements (NAF documentation set) changes, the UML specification changes or their tool capabilities change the UML profile for NAF would likely change.

All of this is invisible to the system architect - they simply start the tool and are able to select a 42010::architecture view as a UML diagram and they are presented with a toolbox palette with the right node and connector elements (from the tool vendor's UML profile that interprets the NAF). The user has no choice but to trust that each part of the chain is valid and has been implemented correctly.

Improving UML Implementation Consistency

The problem was, however, that the evolution of the defence architecture frameworks meant that the UML tool vendors were constantly struggling to implement similar but different metamodels, similar but different architecture view content, with each changing at different points in time. Even metamodel elements with the same name weren't necessarily the same type of thing and could be defined very differently. It also hasn't helped that the defence architecture frameworks weren't good at defining allowed architecture view content which therefore required interpretation and clarification that then wasn't used to update the master source AF-defining documents to avoid the same need for interpretation in the future.

On its own this failure to correct increases the technical debt as the hard won in-house expertise and knowledge in interpreting these documents remains implicit and increases the fragility of the AF implementation and AF definition. Each UML tool vendor could therefore interpret the requirements differently or implement them differently (as there are many possible 'designs' or ways in which a set of agnostic requirements could be met).

As a conseqience there was a need to improve the consistency of implementation in the UML modelling tools. This is where the Universal Profile for DODAF and MODAF (UPDM) arose as a means to improve the consistency of implementation - a common UML profile for implementing DODAF and MODAF [6].

The UPDM is a UML implementation. As with any implementation the UPDM is not the DODAF and the UPDM is not the MODAF either as indicated in the UPDM 2.1 specification:

While conformance with UPDM 2.1 Core and DoDAF-specifics should greatly facilitate conformance with DoDAF 2.02, each tool vendor is still responsible for the tool's ultimate conformance with the documented architecture framework [6]

The UPDM simply aids the architect in producing DODAF-compliant and MODAF-compliant architecture views. The UPDM isn't an architecture framework. It implements metamodel elements but it doesn't define the architecture views and it doesn't implement rules in the individual architecture frameworks.

The UPDM also partly covered the NAF NMM as NAF version 3 included and extended the MODAF metamodel (M3):

NAF and MODAF have shared a common meta-model for some time. The NAF Meta-Model (NMM – Chapter 5 of the NAF Specification) is the same as v1.2 of the MODAF Meta-Model (known as M3).[4]

The NAF views are different and there is still local tool vendor adaptation required by tool vendors to implement the metamodel triples(^1), formed from the metamodel node and connector elements, that may appear in each of the architecture views as the UPDM describes views but doesn't specify what may or may not appear in each:

UPDM is not a new Architectural Framework. Instead, UPDM provides a consistent, standardized means to describe DoDAF, MODAF andNAF architectures in UML-based tools [1]

Having a common UML implementation didn't, however, solve the problems with the NAF v3 document set. As the UPDM was the result of a joint effort by the OMG it helped reduce inconsistency in UML modelling tools but it then meant that the 'design' implementation of NAF (and other AFs) was essentially accelerating away from and leading things because the various master source AF documents weren't being updated i.e. the input requirements were no longer driving things as all of the effort and interpretation was centred on the UPDM (the downstream responding design).

The UPDM 2.1 [6] makes reference to the lack of updates of the master definitions of the architecture frameworks:

the documentation set has not been changed from DoDAF Version 2.0 and is no longer definitive for without the changes. It can be downloaded from the DoDAF Archives ...

...

The DoDAF Meta Model (DM2) has changed from DoDAF Version 2.0. It can be derived as a sequential update from DoDAF MetaModel (DM2) Version 2.00 to 2.01, and 2.02. There were 94 changes in the DoDAF MetaModel (DM2) from DoDAF 2.0 (68 in Version 2.01 and (26 in Version 2.02).

At this point we have an inconsistent master NAF v3 document set which cannot be used by system architects (users) to define what should or should be in any particular NAF architecture view - the users have to rely on the design interpretation of the M3 (NMM) by the OMG and the tool vendors being a correct one. NAF still has a metamodel and there is an implementation of it within the UPDM. There is a means in the common UML profile of the UPDM to improve the consistency of implementation of the NAF. The UPDM also avoids the need for multiple UML profiles so it is simpler for the UML tool vendors to adapt and potentially for users to work with.

Improving the NAF Master Documentation... NAF Version 4 ...

Hause et al[1] identify the cost of maintaining separate defence architecture frameworks:

Creating and maintaining the mapping between the different frameworks takes a considerable amount of time, effort and money on the part of the nations, the tool vendors, and industry.

In these days of limited budgets, austerity measures and “Doing more without more”, this may be a luxury that the nations can no longer afford

At NAF version 4[7] the master documentation is significantly different. Effort has been made to use ISO/IEC/IEEE 42010 terminology - although it still suffers from using 'architecture' where it means 'architecture description':

An architecture may be used to provide a complete expression of any part of the system in an enterprise context.

It also addresses some of the inconsistency by eliminating the old conceptual model in chapter 3. NAF version 4 also introduces a Zachman-like grid to organise and classify the various architecture views based on suggestion from Ian Bailey[8].

But what about the metamodel (NMM) that forms the heart of the NAF?

NAF v4 states

The meta-model defines the essential modelling elements that can be used to describe the system in an enterprise context and its environment

so looking for the 'the metamodel' which used to be the NMM we find:

As part of the development of NAFv4 it was agreed that it should make use of commercial architecture meta-models to enable architecting across military and non-military domains. These are described in Chapter 4.

and then in Chapter 4 - Meta-Model

Chapter 4 of the NATO Architecture Framework identifies the meta-models to be used for creating NAFv4 compliant architectures.

NAFv4 compliant architectures can be creating using the following meta-models; The Open Group®’s ArchiMate® and the Object Management Group®’s Unified Architect Framework (UAF) ® Domain Meta-model (DMM)®

Figure 4 - NATO Architecture Framework Version 4 - Metamodel Removed and Structural Changes

so in NAF v 4 we have the curious situation where NAF no longer has a metamodel [Figure 4]. The NMM is dead. NAF doesn't define a metamodel. We have an architecture framework without its own metamodel.

The reference to ArchiMate is odd. ArchiMate is agnostic of the NAF so it is equally valid to list any 'vanilla' architecture description language (ADL) including the UML, BPMN etc. The problem in doing so is that it is far from clear that any vanilla ADL has all of the types and will permit them to be joined together to represent all of the NAF types and NAF architecture description triples needed to produce all the NAF architecture views. The statement represents a leap of faith with no substantiation.

NAF v4 does, however, have a set of very vague architecture viewpoint descriptions in Chapter 3 - none of which define the acceptable architecture view content. It's impossible to use the NAF v4 master documents to verify an architecture view against. It therefore looks as though the NAF itself no longer cares about view content. This is a significant change to the NATO-controlled master definition of the NAF.

Figure 5 - Implementation of the NAF v4 Now Relies Upon the Unified Architecture Framework (UAF)

'The metamodel' referred to now only exists in the implementation of the NAF or design side ("the how"). We have an implementation but the NMM being implemented no longer exists so in effect the design response is now completely cut adrift from the master source. One of these implementations, the Unified Architecture Framework (UAF) Domain Metamodel[9] is controlled by the OMG and provides a UML implementation. The concrete UAF profile (UAFP)[10](^1) provides an implementation of an abstract metamodel itself also described using the UML [Figure 5].

Of course even the abstract UML metamodel in the UAF contains an implementation of the NMM - or at least it did when the NMM existed. If the NMM has disappeared then there is no version 4 metamodel to implement - the only published but superseded one is the faulty version 3 metamodel. We then have the situation where there is only an implementation of what used to be the NMM within the design side (OMG), not within the master NAF documentation (NATO) [Figure 6].

Figure 6 - NAF v 4 UML Implementation Traceability - No Master Metamodel Definition

Of course even the abstract UML metamodel in the UAF contains an implementation of the NMM - or at least it did when the NMM existed. If the NMM has disappeared then there is no version 4 metamodel to implement - the only published but superseded one is the faulty version 3 metamodel. We then have the situation where there is only an implementation of what used to be the NMM within the design side (OMG), not within the master NAF documentation (NATO).

The UAF even refers to the NAF as a normative source even though it no longer has a metamodel at version 4 so both sides refer to each other. And what is 'normative guidance'?

The NAF itself has no definition of the AD elements and triples to be used for its own architecture views, no content or consistency rules and no mechanism to specify these.

It appears that all of the resources, energy and motivation are in the design implementation of the NAF in the UAF rather than on the root definition of the NAF. The problem then is that corrections, fixes and improvments aren’t being made in the right place – the root definition.

It's all very messy and not how the typical engineering design and development programme is supposed to work. It is difficult to imagine these changes and structure passing a formal System Requirement Review (SRR), Preliminary Design Review (PDR) and Critical Design Review (CDR) [11].

Concluding Remarks

There is no longer a NAF metamodel that acts as an implementation-free set of requirements for any implementation of it. We have a design implementation of it as a record within the UAF. There isn't any master source specification of NAF view content - we have to rely on the interpretation and agreement of tool vendors to establish what is and what isn't permitted as there is no source specification to refer to.

Although maintaining an architecture framework is costly removing most of the core definition of it and leaving its definition and expression to designers downstream is never a good idea.

Trying to solve problems with a design by deleting the input requirements doesn't work.

There are questions that arise from this:-

• What is it that the UAF implements? It isn't NAF v3 and at NAF v4 there is no metamodel. Clearly the OMG in referencing the NAF v 4 metamodel in the UAF traceability were working against a NAF metamodel that wasn’t NAF v3 and was never released as part of NAF v4. Why were the OMG working against something unreleased with no formal baseline?

• If an architecture framework no longer has a specified metamodel then is it reasonable to refer to it in the same way i.e. if it was NAF::NSOV-4' then shouldn't it now be 'UAF::NSOV-4' since the NAF without the NMM is no longer the NAF?

• If an architecture framework has no metamodel; no specification of architecture view content and no consistency rules is it an architecture framework? What is the minimum set of parts required for an architecture framework?

• What NAF master source specification does the user of NAF check their architecture view content against? Why isn't there a simple and user-understandable metamodel so that the user can check what the allowed architecture description triples (node-connector-node) are? A simple agnostic metamodel would also be easy to validate architecture and verify any implementation against.

A common UML implementation isn’t a substitute for good defining source documentation,

The next article will look at how the content of architecture views is specified, the mechanics used and their capabilities to specify vs the commonly held beliefs.

Footnotes

^1. A triple (node - relationship - node) is the smallest unit of architecture description: a node on its own cannot describe architecture i.e. 'Software' isn't architecture description but 'Software satisfies Standard' is.

^2. What was known as the Unified Architecture Framework Profile (UAFP) at UAF version 1.1 - a UML profile - is now named the Unified Architecture Framework Modelling Language (UAFML) at UAF version 1.2 even though it is still a UML profile that implements the UAF and there's only a single individual i.e. unlike any other modelling language it cannot be used for anything else and there will only ever be the single example of it.

References

1. M. Hause, G. Bleakley, and A. Morkevicius, ‘Technology Update on the Unified Architecture Framework (UAF)’, INCOSE International Symposium, vol. 26, no. 1, pp. 1145–1160, 2016, doi: DOI: 10.1002/j.2334-5837.2016.00217.x.
2. ‘C4ISR Architecture Framework. Version 1.0’, C4ISR ITF. Integrated Architectures Panel, CISA-0000-104-96, Jun. 1996. https://irp.fas.org/doddir/dod/c4isr/index.html.
3. ‘NATO Architecture Framework. Version 3.’ Architecture Capability Team, Nov-2007.
4. I. Bailey, ‘SSAC Task 83. NATO Architecture Framework - MODEM. Review’. 16-Aug-2013. https://nafdocs.github.io/assets/20130816_MODEM_to_NAF_Review_V1_1-U.pdf
5. ‘OMG Unified Modeling Language (OMG UML©). Version 2.5.1’, The Object Management Group, formal/2017-12-05, Dec. 2017. https://www.omg.org/spec/UML/2.5.1/PDF.
6. ‘Unified Profile for DoDAF and MODAF (UPDM). Version 2.1 (Normative Document)’, The Object Management Group, formal/13-08-04, Aug. 2013. http://www.omg.org/spec/UPDM/2.1
7. ‘NATO Architecture Framework. Version 4 (2020.09)’. Architecture Capability Team, Sep-2020. https://www.nato.int/cps/en/natohq/topics_157575.htm
8. I. Bailey, ‘Reorganising MODAF and NAF’. 07-Nov-2013. http://nafdocs.org/wp-content/uploads/2013/07/Reorganising-MODAF-and-NAF.pdf
9. ‘United Architecture Framework (UAF) Domain Metamodel. Version 1.1’, Object Management Group (OMG), dtc/19-11-05, Apr. 2020. https://www.omg.org/spec/UAF/1.1.
10. ‘Unified Architecture Framework Profile (UAFP). Version 1.1’, The Object Management Group, dtc/19-06-15, Jun. 2019. https://www.omg.org/spec/UAF/1.1/Beta1/UAFP/PDF.
11. ‘NAVAIR Systems Engineering Technical Review Process Handbook’, NAVAIR, NAVAIRINST 4355.19E, Feb. 2015.