Page 1 of 2 pages  1 2 > 

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

Related Articles

{REL[6115][related1_blog]HXKRPlcHREL}

Sharing tags:

• Keep Clear Separation Between the Concerns that Each Architecture View Addresses (67% )
• Risk and Threats - The Common Ground Between Security and Safety? (33% )
• Representing ‘The Needy’ in MODAF - The Needline (17% )
• New Revision (“The ISO 42010 Mix”) of TRAK Released (17% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (17% )

External Links

• Wikipedia - NATO Architecture Framework
• AC/322-D(2007)0048. NATO Architecture Framework Version 3 - CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification.
• AC/322-D(2007)0048. NATO Architecture Framework Version 3 - CHAPTER 7 Architecture Definitions, Terminology and Ontology
• AC/322(SC/1-WG/1)N(2009)0005-ADD2. NATO Architecture Framework Version 3.1 - CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification.
• ISO/IEC 42010:2007 Systems and Software engineering - Recommended Practice for Architectural Description of Software-Intensive Systems

Keep Clear Separation Between the Concerns that Each Architecture View Addresses

ISO/IEC 42010 advocates or, more likely, is predicated on the assumption that an architecture description of a complex system needs many architecture views.

Since the initial publication of IEEE Std 1471, there has been wide acceptance for the use of multiple viewpoints to express architectures of systems, and for system concerns as a primary motivation for the content of architectural descriptions. This revision builds upon these core concepts, and captures additional consensus in the areas of architecture frameworks and architecture description languages.

Each view describes the real world architecture and addresses a different set or concerns or questions posed. The typical concerns each view addresses are defined within an architecture viewpoint which is a specification for each view type. Note that this use of ‘viewpoint’ is not that same as that used in MODAF and DODAF where viewpoint is a collection of architecture views, not a specification.

Pretty obviously these need to overlap so that the reader can move around the architecture description and also understand the context for any part. For example there’s no point in showing a function without showing the thing that performs the function and this in turn might realise or implement part of a concept. Overlapping views are therefore a good thing. This in turn requires overlap between the defining viewpoints (ISO terminology).

Whilst some overlap is always good, too much overlap in invariably bad. If there is too much overlap in the things that can be shown in different view types then it becomes difficult if not impossible for the reader to understand the purpose of each view type and differentiate between them. It also leads to inconsistency in the way that an architect approaches the task since if the same content can be shown on 2 view types one architect might choose one view type and another might choose the second. From the reader’s point this is confusing since there is no clear expectation in terms of finding particular objects and relationships. In essence it is a human factors problem since with too much overlap the affordance suffers as there is no longer a clear distinction between view type and the likely view content. From the point of ISO/IEC 42010 the risk is that there is no longer any clear distinction in terms of the concerns addressed by each view type.

This is best illustrated by practical example. The following is taken from MODAF 1.2.004 and looks at the MODAF::SV-1 Resource Interaction Specification View vs the MODAF::SV-2 set (SV-2a System Port Specification View, SV-2b System Port Connectivity Description View and SV-2c System Connectivity Clusters View).

The MODAF System Viewpoint states:

The primary purpose of an SV-1 is to show resource structure; i.e. to identify the primary sub- systems, posts and roles and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.

but goes on to add:

In its simplest form, an SV-1 can be used to depict systems and sub-systems, and identify the interfaces between them; however, this rarely adds more to that which can be shown in an SV-2, product.

and

If possible, an SV-1 will show resources and their interactions for the entire architecture on the same diagram

It’s immediately confusing since the stated intent is to show structure (despite the name of the view) but then adds interactions and itself identifies that there is hardly any difference between the SV-1 and SV-2 since both can legitimately be used to describe both structure and identify interfaces between the structural parts. In terms of the definition there is no distinction between the different concerns addressed and therefore you might choose the SV-1 to describe structure and interaction whilst I might choose the SV-2. [Note: The MODAF::SV-2 can only be used for System and Software not for Human Resource (Organisation, Job and Role) unlike the MODAF::SV-1]

At 1.2.004 there is even less differentiation since it now can be used not only to identify but to characterise interfaces:

If SV-1 is developed as a composite structure model (e.g. in SysML, UML), Resource Ports may be used to convey how interactions are dealt with internal to the resource when the resource has parts. Resource Ports may also specify the interfaces they require or provide.

(As an aside there are also inconsistencies between what appears in the textual description, the data objects and the fragment of simplified metamodel since the data objects section does not appear to list all the types of object that can appear on a SV-1.)

There is so much overlap between the MODAF:SV-1 and SV-2 that it is no longer clear what distinguishes the two (you can show structure and interactions on both) and therefore why you need both. Certainly the stated emphasis on structure isn’t reflected in the definition of the SV-1.

To be fair to MODAF this looks to be a problem inherited from DODAF:

Systems Viewpoint. SV-1: Systems Interface Description

A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems, performer and activities (functions) and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.

The NATO Architecture Framework, version 3.1 doesn’t state a structural intent quite as boldly although it does say for the NSV-1 System interface description:

In a sense NSV-1 and NSV-4 provide complementary representations (structure and function)

If structural were limited to composition and configuration relationships and exclude flows then the SV-1s would be structural. They don’t, however, and the fact that their name includes Interaction or Interface (not structure) suggests that the intended focus of each of these views are the flows. Very much a case of mixed messages which doesn’t help the architect.

This shows that it is vital to keep clear water between the focus and therefore the concerns addressed by each view type.

Comments

Comment on this article

Related Articles

{REL[6104][related1_blog]HXKRPlcHREL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (30% )
• Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views (10% )
• Conformance Assessment vs ISO/IEC 42010:2011 (10% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (10% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (10% )

External Links

• ISO/IEC FCD 42010 Systems and Software Engineering — Architecture Description - latest draft. 8th June 2010
• The MODAF System Viewpoint. 26th April 2010
• DODAF 2.02. SV-1:: Systems Interface Description
• ANNEX 1 TO AC/322(SC/1-WG/1)N(2009)0005-ADD2 NAF V3.1 CHAPTER 5 5.2.6.1 NSV-1 System interface description. 1st March 2010

NATO Architecture Framework Metamodel v3.1 Surfaces

A definition/description of the NATO Architecture Framework Metamodel version 3.1 is now publicly available (the definition of the framework had previously disappeared from public view).

Currently only the document that specifies the metamodel is available - this is one part of the overall definition of the NATO Architecture Framework. The documentation that specifies the architecture views for version 3.1 isn’t yet available. The document that is available is Chapter 5 - NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) .

Without a complete document set and without a change record yet it’s hard to make an assessment, but ...

• NAF 3.1 now seems to be much closer to the MODAF 1.2.003 metamodel (MODAF is now at 1.2.004)
• The number of subviews has increased in total from 47 at 3.0 to 49 at 3.1 - with notable changes in the NATO Service-Oriented Views (NSOVs) which now align with MODAF
• the usage context of Resources (Capability Configuration, Artefact, Role, Post, Organisation, Software) can now be specified - this is a way of allowing exchange of models which were previously unexchangeable owing to the choices allowed by the NAF metamodel in typing a real world thing e.g. system vs platform vs artefact with the result that different architects would choose different stereotypes. The conflict in choice is still present but the usage context allows the architect to say, for example, this Platform is being used as a System. This is identical to MODAF from 1.2.003.
• any Resource is allowed to have a function now (NAF previously divided Resources up into ‘functional’ and ‘non-functional’
• any Resource can now interact with another Resource

Some niggles still remain e.g. the ‘system’ stereotype is really not a first class player and cannot itself contribute to capability or have parts which are other resource-like things - so no complex system or including the man with the machine as part of the system. This looks as though it has to be achieved using a Capability Configuration as a system and ignoring the fact that the System stereotype cannot represent a system. The new definition of System in v 3.1 doesn’t help - ‘The usage of an artefact as a System in a CapabilityConfiguration’ - as it doesn’t actually define what a system is.

Still the increased flexibility wrt Resources is a significant step forwards in representing the real world.

Update 11th November 2010
The definition for the NATO architecture framework seems to have disappeared again.

Comments

Comment on this article

Related Articles

• Has the NATO Architecture Framework v3 Definition “Naffed-Off”?

Sharing tags:

• Has the NATO Architecture Framework v3 Definition “Naffed-Off”? (50% )
• Keep Clear Separation Between the Concerns that Each Architecture View Addresses (25% )
• NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF? (25% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (13% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (13% )

External Links

• Chapter 5 - NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES)
• Architecture Framework Comparison - wiki on trak-community.org
• NAF 3.1 - wiki on trak-community.org

Page 1 of 2 pages  1 2 >