Page 1 of 2 pages  1 2 > 

Pulling the MODAF, DODAF, NAF et al Into a Common Frame of Reference

Some of the more observant amongst you might have noticed that we have a wiki that aims to cover multiple enterprise architecture frameworks (DODAF, MODAF, NATO Architecture Framework and TRAK as a minimum) as well as the use of such things in a typical systems engineering lifecycle.

This is a long slow process. The first to be covered was TRAK and now we’ve got decent coverage of the NATO Architecture Framework as well as a sprinkling of MODAF. To date there are the best part of 300 pages. There’s a lot still to do so if anyone would like to help then this would be gratefully received as it takes time to locate source material and extract the essence.

Why go to this trouble? For several reasons:

• To help. Some frameworks either don’t have much of a web presence or provide information in forms that isn’t the easiest to navigate through. MODAF has suffered in navigability as a result of being taken from the site maintained by Model Futures and squeezed into the ‘one size fits all’  corporate MoD structure. The NATO Architecture Framework and some others just offer a set of unlinked PDF documents without supporting web content. If we can extract the bare bones in terms of view definitions and link them to other views, the respective metamodel and other frameworks then this has to be better.
• To compare and contrast. All of these frameworks have a common origin, the DODAF, and have at times borrowed bits from each other so there is a lot of similarity. There are also some important differences reflecting their ages and their respective specification and user communities. It’s very difficult to see this when they are widely separated and presented in very different formats and language or terminology. If we can provide bridges between the frameworks and put the information in a similar way alongside each other then it’s much easier for the user or potential user of the frameworks. I have this belief that there will be a universal metamodel at some point. One of the reasons we separated the definition of the TRAK Viewpoints from the TRAK metamodel was to   allow for the possibility that we’d not got it right and to enable the metamodel to be re-used if needs be).
• To provide points of reference. As a lot of the frameworks are expressed in large documents it’s quite hard to make reference to a particular view or metamodel element. If each view, each term or each metamodel element is a separate wiki page it makes it much easier to make reference to - each element is addressable by a URL (which is where I’d really like the architecture models themselves to be at some point in the future) and within a namespace named after the framework (not all terms have the same meaning e.g. MODAF:View is a singular architecture view, NAF:View is a collection of subviews and TRAK:Architecture View although singular is a response to a view specification (TRAK:Viewpoint).

Being forced to read the documentation in some detail means that you do learn quite a lot. I’ve learnt that NAF:System cannot realise a capability and that NAF:Organisational Resource  (Organisation and Post = ‘Job’)  cannot have functions assigned directly only indirectly via NAF:Role.

I’d be interested if anyone has good pointers to AUSDAF documentation and very much so if any site member wanted to help to start fleshing out other frameworks.

Anyway, you can keep up to date with progress / changes on the wiki by subscribing to the RSS feed.

Comments

Comment on this article

Related Articles

{REL[122][related1_blog]QTuyqDNEREL}

Sharing tags:

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

External Links

• NATO Architecture Framework home - external link
• NATO Architecture Framework Views (Capability View, Operational View, Programme View, System View, Service-Oriented View, Technical View, All View)
• NATO Architecture Framework Subviews
• MODAF Viewpoints
• MODAF Views
• TRAK Views

Support for the ‘AFs - Wiki Now Live

Wiki- With Spaces for TRAK, MODAF, DODAF and Common Process/Problems

After a long time - some months - of effort the wiki has got to the point where it’s sensible to let it loose.

It has something over 550 pages (a devil to keep consistent) and there’s inevitably a lot of explanation to support the recent release of TRAK. It does have a comparison between TRAK and MODAF 1.2 and sections for MODAF, DODAF, NAF as well as for the modelling process.

Any site member can add content as with the rest of this site - if you don’t see the page you wanted help create it!

There’s lots still to do both in terms of content and adding functionality

• wiki page heading links
• linking the wiki to the discussion forums so that comments can be made on each page

Visit the wiki now!

Comments

Comment on this article

Related Articles

{REL[123][related1_blog]QTuyqDNEREL}

Sharing tags:

• MODAF is Dead - Long Live ‘NAF’? (33% )
• Definitions - What Exactly is a Risk? (17% )
• Just When You Thought It Was Safe - EntiTy Returns (17% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (17% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (17% )

Forums

• See discussion thread in forums

External Links

Putting the Architectural Modelling Community First - What You Can Expect to See

This current site is really only a interim site. What is intended is a site that properly supports the folks using TRAK or other MDAF-based architecture frameworks and one which represents the ethos behind it:-

• pragmatic - led by need and application - the human interface to the framework (usability, affordance etc.)
• open - decisions, rationale, explanation
• democratic - involve the community in the site content rather than broadcast top down what I/we think folks need. The centre of gravity ought to be with the users rather than the specifiers-of the framework
• fun - why not? Systems thinkers/engineers and architects are real, dare I say it ‘whole’ people and all sides need to be addressed
• dynamic - the content needs to be able to change and adapt to new circumstances, thinking or practice

What You Might Expect

The features that you should expect to see are:-

• each section of the site is a ‘blog’
  • articles can be discussed and commented on by site members
  • updates notified by RSS news feeds
• articles can be linked together, tagged, put into categories and dynamically sorted/displayed and searched for by users
• discussion forums
  • tool support
  • use of architecture frameworks
  • modelling / repository organisation - not governed by frameworks but important and common to all
• architects can submit examples of views to help others
• wiki to hold facts on architecture frameworks e.g. metamodel elements, use of UML tools, tips, plugins etc.
• single sign-on to comment, add a forum discussion or to add to the wiki
• everyone can see everything - nothing hidden
  • only site members can contribute or comment - contributors and commenters recognised and stand up to the mark!
• fun / anarchic humour
  • the lighter side
  • not taking life too seriously

Comments

Comment on this article

Related Articles

{REL[135][related1_blog]QTuyqDNEREL}

Sharing tags:

• This is But One Part of a Bigger “Whole” (29% )
• Standards - Site Appearance in Internet Explorer 8 vs Anything Else (14% )
• Keep Clear Separation Between the Concerns that Each Architecture View Addresses (14% )
• Risk and Threats - The Common Ground Between Security and Safety? (14% )
• Architecture Description Language (ADL) vs Architecture Framework (14% )

External Links

Page 1 of 2 pages  1 2 >