Page 1 of 4 pages  1 2 3 >  Last ›

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.

Comments

Comment on this article

MODAF is Dead - Long Live ‘NAF’?

Integrated EA presents an interesting and useful opportunity to learn, listen and talk about enterprise architecture, mostly but not always from a defence and aerospace application and not just from the UK but other parts of Europe and the world that have experience in the application of MODAF, DODAF, NAF and similar architecture frameworks. The event was created by Ian Bailey of Model Futures who was one of the ‘elves’ behind the creation of MODAF and who has maintained parts of the documentation and the MODAF metamodel (M3) since. This year’s Integrated takes place this week on 3/4th March 2015 at One Great George Street, London.

Ian has posted on the Integrated EA blog about the imminent demise of MODAF as a distinct architecture framework since it is about to join forces with the Nato Architecture Framework (NAF). Ignoring the name, NAF hasn’t had a good record over the years in terms of its documentation and because the metamodels for NAF and MODAF were significantly the same it was often the case that architects would use MODAF documents to produce NAF views (or ‘models’ as NAF calls them - the terminology differs between frameworks and the ISO/IEC/IEEE 42010 standard).

The post makes for interesting reading. In his post Ian mentions TRAK:-

MODAF spawned TRAK, which was free of the legacy user base MODAF had, and so was able to do a lot of things we’d been trying to do in MODAF for a long time

I’m still jealous of the freedom Nic had when he developed TRAK, and I still like the idea of an open-source framework.

.

so we must clearly be doing something right which is nice to know as Ian knows his stuff! Presumably this must also apply to NAF - unless they’ve ditched their roots or elected not to make some aspects backwards-compatible.

On this very site in 2011 I suggested that it would be a good idea to merge MODAF and NAF since they were converging, it didn’t seem sensible to have two similar but different sets of documentation etc. and the overhead in terms of maintenance and development cost must be significant. In the interim period we’ve had the economic downturn / crash and the financial imperative for efficiency / cost saving must be even greater. What never occurred to me was that MODAF would disappear or be absorbed into NAF. It therefore seems very unfair that the reward for MODAF being more consistent, having better documentation and being ahead is to lose its own identity. I suppose there is still much collaborative effort but all of the user-facing terminology seems to be very much that of NAF.

A quick look at the new set of NAF::’Models’ ( aka MODAF::’Viewpoints’) shows that there has been some attempt to simplify the naming of the models/viewpoints (something TRAK has had from its inception). It’s also nice to see some principle of organisation for the models/viewpoints in the grid view. This is very reminiscent of Zachman. They have also attempted some rationalisation to improve consistency. What seems to have disappeared is the MODAF Acquisition Viewpoint and it looks as though the MODAF AcV-2 Programme Timelines View is now part of the NAF:Logical Specifications. [ How any high level architecture description can be considered to be a ‘specification’ is beyond me since it doesn’t support the basic ideas behind attributes of requirements let alone completeness of specification. This seems to be the Holy Grail of folks with a software background but inconsistent with readability / understandability / basic user interface principles e.g. if it’s complete enough as a coded specification it’s also likely to be highly technical, use formal notation that is capable of supporting machine-validation and completeness-checking and increasingly impenetrable to the user. This also ignores the “..ilities” and non-functional aspects of a specification because most notations seem to be designed to describe structure, messaging or behaviour.] The MODAF AcV-1 which described the structure of projects seems to have disappeared. It ought to fit under the NAF Structural heading but this is occupied by the NAF Logical Scenario which is an entirely different view so there are clearly going to be some significant problems to overcome in eliminating MODAF viewpoints and merging MODAF views with the NAF cousins.

If only the new NAF would take on board some reasonable amount of compliance with the international standard in terms of terminology we’d start to see some real progress based on standardisation. There are encouraging signs that someone behind NAF is taking some notice of the standard e.g. ‘A3 Architecture Correspondence. ISO 42010’ which I assume has something to do with correspondence rules but without any detail it’s impossible to see whether this complies. “It’s progress Jim, ..”.

MODAF might be nearly dead but it’s very hard to shout “long live NAF” - yes, Ian, something must really be done with that acronym otherwise we’ll have have “NAF models ..”, “NAF specifications” … and you can only have so much NAF-ness! 

Comments

Comment on this article

NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF?

The NATO Architecture Framework (NAF) has been around for many years now. It has been on a convergence path with MODAF from version 3 (released in November 2007) and the latest version, 3.1 appears to be even more closely aligned with MODAF than ever. I say ‘appears’ since there is only 1 part - Chapter 5 - that has been released and the remainder is subject to an official delay.

The documentation for NAF isn’t the best as it describes on Wikipedia with respect to version 3:

The documentation of the NAF Rev 3 views (Chapter 4) does not always align well with the NAF Meta Model (Chapter 5). This is particularly the case with some of the examples, which are based on DoDAF version 1.0. Some NAF users find it useful to first of all refer the official MODAF Documentation - [1]. This is a useful strategy, as the MOD documentation can be somewhat easier to follow, and NAF and MODAF share a common meta-model.

There is certainly a consistency problem. At version 3 the framework consists of 7 views each of which has a number of subviews. A NAF::View is a collection of NAF::Subviews that are related by the subject matter. This terminology actually came from DODAF 1.X.

Chapter 7, Architecture Definitions, Terminology and Ontology, 7.2.1 defines NAF::View:

A set of subviews grouped by purpose.

clearly a collection of subviews, and defines NAF::Subview as

A pattern from which to develop individual products by establishing the purposes and audience for a product and the techniques for its creation and analysis.

Note: this is called Viewpoint in IEEE-1471-2000; perspective is often used in the same sense.

Under 7.2.3 NAF Metamodel Terminology it then defines NAF::View as:

A specification of a way to present an aspect of the architecture. Views are defined with one or more purposes in mind - e.g. showing the logical topology of the enterprise, describing a process model, defining a data model, etc

MODAF 1.2.004 defines MODAF::View as:

A specification of a way to present an aspect of the architecture. Views are defined with one or more purposes in mind - e.g. showing the logical topology of the enterprise, describing a process model, defining a data model, etc.

It is clear that the NAF::View definition has therefore been taken directly from MODAF. Unfortunately in cut and pasting they didn’t remember that MODAF is organised using Viewpoints (collections of views) and Views unlike NAF. NAF is therefore inconsistent. It actually has 3 places where View is defined since it also appears in Chapter 5. This is another problem as it isn’t stated where the master source of truth is so that in the event of conflict the user knows which takes precedence. As a general principle consistency is not improved by having something defined in any more than one place.

This was version 3 of NAF. Has version 3.1 improved matters? In a word, No. Looking at the only part of version 3.1 that is in public view, Chapter 5, the definition is still the same. On top of this in places the description under some of the subviews things like The NSOV-2 view defines…. What appears to be happening is that NAF is adopting the MODAF Viewpoint/View terminology instead of it’s own View/Subview terminology. Unfortunately it’s done this only partially - 3.1 doesn’t define either Subview or Viewpoint for the collection and still has subviews as headings (not views) so we have the strange situation where a view is both the collection and the individual specification. This doesn’t make for good or easy reading.

One of the advantages of standardisation is that is provides a common language. ISO/IEC 42010:2007 defines a view:

A representation of a whole system from the perspective of a related set of concerns.

and viewpoint as:

A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the tech- niques for its creation and analysis.

so a NAF::Subview and MODAF::View is closest in spirit to the ISO 42010::Viewpoint (practice is different as neither framework specifies the view content - they are narratives - hence the response by the tool vendors in creating the UPDM to constrain what can appear in the products for tools). NAF uses ArchitecturalProduct to refer to the thing the architect produces in response to the NAF::Subview specification. This term doesn’t appear in the description of the views - another source of inconsistency as often different terminology is used or words are used in senses that aren’t in keeping with the definition of the terms in the metamodel. To be consistent there has only to be one definition and this has to be used wherever that term appears whether in user documentation or architecture description. How can you expect the user to be consistent if the specification isn’t. If you advocate the importance of consistent meaning (semantics) you have be consistent in the specification - none of the casual use that we all use in everyday conversation. You have to be pedantic.

The NATO Architecture Framework therefore seems to be suffering in the transition to version 3.1 and also because of the similarity between it and MODAF where terms have previously been used in a different sense. Unlike at the start both MODAF and the NATO AF are now very similar. In fact they’re so similar that you have to ask whether it’s worth maintaining two distinct architecture frameworks that are separated only by a small technical gap? As the Wikipedia article suggests you can use the MODAF documentation to help produce NAF architecure descriptions (don’t blame me for the acronym!). The sovereignty gap might be wider but is it really worth the price? Particularly in these cash-strapped economic times it no longer seems to be efficient use of tax payer’s money to maintain the overhead of both - isn’t it about time they reconciled any differences and merged? This has to be a reasonable savings measure in either or both NATO’s and the MOD’s budget.

Comments

Comment on this article

Page 1 of 4 pages  1 2 3 >  Last ›