Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 487 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Modaf'

Entries that have been tagged with 'Modaf'.-

Representing ‘The Needy’ in MODAF - The Needline

by Nic Plum on Tuesday 11 January, 2011 - 13:25 GMT

Posted in Architecture FrameworkMODAFStandards

Tags: 1.2.004configuration controlmodafneedlineoperational

MoD logo

I’m spending a lot of time playing ‘spot the difference’ to capture the changes in the Canadian DNDAF (at v1.7 from 1.6), MODAF (at 1.2.004 from 1.2.003) and NATO AF (at 3.1 from 3 - or at least will be when the documentation is properly accessible). This is harder than it needs be owing to the patchy nature in which changes are identified and recorded in the various architecture frameworks - or not. In this respect MODAF is definitely one of the better frameworks.

One of the significant changes with the release of the MODAF 1.2.004 (May 2010) is that all resources are now equal in that not only can interactions (Resource Interactions) be identified between them but can also be characterised and flows of information, energy, materiel and people captured. Prior to this MODAF could only characterise interactions for artefacts, systems but not for human resources. 1.2.004 also  adds the ability to show materiel, energy and people flows to various systems and operational views.

All of this is good and much needed for describing the real world. It does now highlight the Needline as a throwback to the earlier information-only days. In the solution-free operational views the node (the nearest we get to ‘thing’ or ‘stuff’ ) is connected to another node by a needline. In 1.2.004 it is defined as:

A relationship between Nodes representing a bundle of InformationExchanges.

i.e. a collection of information exchanges.

 

In the old days (MODAF 1.1 - May 2007) it was defined as:

 

A relationship specifying the need to exchange information between nodes…

 

which has a more explicit (=better) link to it being a line identifying a need and hence the name of the stereotype.

The current definition is a poor one since it defines Needline only in terms of the MODAF metamodel itself. Stereotypes are supposed to represent something in the real world and therefore the ones that can be selected by an architect should be defined in terms of the parts of the real world that they are supposed to represent. The new definition contains nothing in terms of representation or the real world equivalent. It’s almost as if the purpose or point of having it have been lost as there’s no sense of a Needline being used to represent a need for an exchange (of some type) any more - this has been thrown away.

It still doesn’t seem right to only being able to express a need for information. Why not a need for energy, people or materiel? It would make much more sense to unify any need under needline and define it as A relationship identifying the need to exchange energy, information, materiel or people. At least then it would be consistent with the rationalisation / equal treatment of resources (Resource Type). The resulting representation of exchanges is therefore inconsistent and it feels like the new exchange types have been tacked onto rather than incorporated within the metamodel.

Comments

Comment on this article

Related Articles

    {REL[6112][related1_blog]qVNmk4XPREL}

    Sharing tags:

    External Links

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

    by Nic Plum on Monday 05 April, 2010 - 10:52 GMT

    Posted in Architecture FrameworkMODAFNAFSite

    Tags: comparecontrastdodafmodafnafsitetrakwiki

    c300 pages on the wikiSome 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.

    Keep up to date with the wiki by subscribing to the RSS feedAnyway, 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]qVNmk4XPREL}

      Sharing tags:

      External Links

      A System is a System, Right? Not if You’re Head-Modelling

      by Nic Plum on Saturday 27 February, 2010 - 16:24 GMT

      Posted in Architecture FrameworkMODAFTRAK

      Tags: artefactcapability configurationdefinitionhandbookhead-modelincosemeaningmodafontologyplatformstereotypesystemsystem of systemstrak

      Introduction

      Choosing stereotypes for an enterprise architecture framework isn’t easy. In defining something you embed the prevailing view at the time the framework was created. This may later haunt you. With every extra stereotype you add choice and then when you add the poor old architect or modeller into the mix you increase the possibility of inconsistency - the very thing the metamodel is designed to constrain and eliminate. This is illustrated very nicely in trying to place ’System’ at the centre of TRAK.

      Since we started with MODAF 1.2 this is where the story begins.

      MODAF 1.2

      In the MODAF System is defined as

      The usage of an artefact as a System in a Capability Configuration

      and part of the physical architecture.

      In MODAF a System is man-made and physical - no parts

      MODAF::System - A Physical Artefact

      Technically it is defined as an Artefact alongside Platform. This arose because when the MODAF was originally launched the consensus on what a system is wasn’t the currently accepted one with emergence et al and the MODAF quite reasonably took the then accepted view - hence it is a purely man-made thing. No notion of complexity whatsoever.

      From the The MODAF System Viewpoint(SV) (17th February 2009):
      ‘Artefacts - Physical objects made for a purpose (e.g. system, sub-system, platform, component or any physical item that occupies space and has attributes)’

      ‘Physical Architectures - Configurations of resources for a purpose (e.g. capability configurations)’

      ‘The physical resources contributing to a capability must either be an organisational resource or a physical asset. That is, a system cannot contribute alone; it must be hosted on a physical asset used by an organisational resource of both. Organisational aspects (e.g. who uses a system) can now be shown on SV-1.’

      In short as it is defined in MODAF 1.2:

      • system is something physical
      • it is man-made
      • it can’t contain anything else like Organisation, Post or Role, or Software
      • it is not the same thing as a Capability Configuration
      • systems cannot provide capability

      TRAK

      When creating TRAK we found we couldn’t use MODAF::System as it didn’t fit with either the London Underground view of a system or the INCOSE or ISO ones.

      The current INCOSE Systems Engineering Handbook defines a system as:
      ‘an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.’

      It was therefore impossible to use MODAF::System to represent what is currently accepted to be a system. So what could we use? As a system is a mixture of hard and soft resources it made sense to position at the centre of TRAK:

      In TRAK System is central to the metamodel

      TRAK::System - Central to the Metamodel

      Immediately therefore this allows us to describe systems

      • composed of a mixture of equipment, software and people - not just physical
      • composed of just software or of just human stuff - soft systems

      and we don’t need ‘Sub-system’ either or ’System of Systems’ since the terms just reflect a point of view in the hierarchy of systems and we already have the construct ‘System is configured with System’ to allow us to represent systems at any level. In fact if we introduced sub-system we would be forcing architects to make a choice and with choice comes difference of opinion and the potential for inconsistency - my Sub-system might be your System and so on.

      Now Add People

      The choice of metamodel elements is important, particularly when you add people (users of the metamodel) into the mix.

      Some of you will be looking at the TRAK metamodel fragment above and thinking ... Capability Configuration. Indeed in MODAF this is where Capability Configuration sits. So is Capability Configuration correct? As defined it cannot be - Capability Configuration is still part of the Physical Architecture.

      The bigger problem, however, is that you end up using one element but with the meaning of another. It’s easy to see how this might arise - being not allowed to add parts to MODAF::System the architect takes the stereotype that does allow him or her to add the stereotypes that they want - the Capability Configuration. It is possible that they don’t even see the problem in doing so. The trouble is that they describe something as a system but use Capability Configuration. Their ‘head-model’ doesn’t fit the meaning of the model elements used.

      It is actually worse because in providing MODAF::Platform and MODAF::System there is a choice to be made - when is something a platform and when is it a system? You can almost guarantee that different choices will be made and therefore it makes it more likely that architecture descriptions (models) can’t be ported between organisations. In fact the poor modeller has 3 stereotypes that can be used to mean ’system’ (in their head) - the MODAF::Capability Configuration, MODAF::System and MODAF::Platform. On the receiving end you can’t predict which will have been used.

      This is why in TRAK there is only 1 TRAK::System. It’s flexible, can be used for hard or soft systems and, importantly, ‘there shall only be one’ - no sub, super or whatever-system.

      You describe the context simply by the system boundary and hierarchy. Easy.

      After all a system is a system.

      Acknowledgements

      The MODAF is Crown Copyright/MOD
      The TRAK Metamodel is released under the GNU Free Documentation License.

      Comments

      Comment on this article

      Related Articles

          Sharing tags:

          External Links

          1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
           

          All articles/posts © of the respective authors

          Site design and architecture © 2010 - 2019 Eclectica Systems Ltd.