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:

• NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF? (25% )
• MODAF is Dead - Long Live ‘NAF’? (25% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (13% )
• 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

TRAK is in the Wild - Now an Open Source Enterprise Architecture Framework

TRAK has been released, thanks to the foresight of London Underground Ltd., under an open source license.

Releasing TRAK under open source is important because

• it is a standard to facilitate the exchange of architecture models
• it recognises that there are many who could contribute expertise if allowed to do so - any with the need or energy/motivation can participate
• it provides a feasible maintenance and support system - one where TRAK has the wherewithall to heal itself
• it keeps the cost of using the standard to a minimum - since architecture is a form of communication we shouldn’t tax it!
• it represents pragmatism in terms of releasing early, not waiting for perfection and in collaborating for the common good

The UK Department for Transport are the sponsor of TRAK as part of a wider systems engineering initiative.

The release of TRAK has been split into 4 products.

The first 2 parts form the logical definition of TRAK.

• the TRAK metamodel. This specifies the allowable object types and relationships that can be used. In essence it provides the language that an architect can use through the set of nouns and verbs. It includes a simplified metamodel for easy reference. It also includes a detailed comparison against MODAF 1.2 in order to set an initial baseline. One of the reasons for release using the GNU Free Documentation License (GFDL) is that the History section is preserved together with attribution to those who help develop TRAK. The metamodel is at trakmetamodel.sourceforge.io
• the TRAK architecture viewpoint definitions. TRAK adopts ISO 42010 / IEEE 1471 practice by having a viewpoint for each architectural view that specifies the concerns addressed, the allowable objects (from the metamodel), the suggested presentation format and the consistency rules. It includes a comparison against MODAF 1.2 view set. It is released as open source under the GFDL at trakviewpoints.sourceforge.io

The second 2 parts are implementations against the logical definition.

• the MDG Technology for TRAK. This is a Sparx Systems Enterprise Architect (EA) file that contains the architectural model used to create both the MDG plugin that implements TRAK in Enterprise Architect and the UML profile for TRAK which is used by Enterprise Architect and any other UML modelling tool. It represents the implementation of both the TRAK metamodel and the TRAK viewpoint definition as far as is possible. It contains the EA plugin and the source EA project file. It is released under the GNU Public License version3 (GPL v3) at mdgfortrak.sourceforge.io
• the UML profile for TRAK. This provides the set of objects and relationships defined within the TRAK Metamodel in a way that any decent UML modelling tool can use. It is released under the GPL v3 at trakumlprofile.sourceforge.io

Not saying it’s perfect - we know it isn’t. It’s good enough for practical purposes and we have a list of things that need looking at. What I hope is, being open source, that anyone needing to apply it in a particular situation and finding it lacking can then get involved to solve the problem. Application and usability are all important - more so than any theoretical underpinning. The framework is not a system - this only arises when you add tools, people, organisations and therefore you always have to address visibility, navigation, affordance etc - in short the user interface for the whole thing. We hope in this way that TRAK will be user-centric and problem-led rather than specification-centric.

If you do want to get involved there are forums set up at the TRAK Viewpoints and TRAK Metamodel sites.

Comments

Comment on this article

Related Articles

Sharing tags:

• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (25% )
• Just When You Thought It Was Safe - EntiTy Returns (13% )
• Definitions - What Exactly is a Risk? (13% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (6% )
• Definitions - What Exactly is a Risk Part 2? (6% )

External Links