Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Operational'

Entries that have been tagged with 'Operational'.-

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]nYTq5cZ1REL}

    Sharing tags:

    External Links

    DODAF 2 - Now That Systems Views Deprecated, What Happens?

    by Nic Plum on Friday 19 November, 2010 - 18:47 GMT

    Posted in Architecture FrameworkDODAFStandards

    Tags: advicecapabilitydoddodaflinkedinoperationalprojectservicesystemviewpoint

    DODAF logo
    In releasing DODAF 2 significant changes were made from DODAF 1.5 not the least of which are the changes to the definition and use of ‘System’ which can now perform functions, be made from materiel and personnel rather than just computer hardware - all good and very necessary when representing a real system. The trouble is that there are then some very odd statements and advice made with respect to describing systems.

    From DODAF Viewpoints and Models:

    The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.

    and from the Systems Viewpoint

    The Systems DoDAF-described Models are available for support of legacy systems. As architectures are updated, they should transition from Systems to Services and utilize the models within the Services Viewpoint.

    So it seems that Systems Views are being withdrawn and the official advice is to transition from Systems Views to Services views. This is worrying for a number of reasons:

    • you cannot equate a System with a Service. A System is a thing characterised by emergent behaviour. A Service is usually an abstract activity-like thing with no notion of technology or implementation. A System is very definitely part of the implementation. If they are considered to be the same why have both sets of views?
    • if the Systems Views disappear you cannot then describe any implementation using DODAF. It is surely very important to be able to describe the things we see in the real world. So what happens to the companies that design and develop these systems if they no longer have any means to describe the architecture of the things they develop and deliver? Enterprise architecture should bring different communities together for the common good not cut them out.
    • if Systems Views disappear the means to gather the data relating to systems for the underlying DODAF Data Model disappears. This is owned by the DoD so they alone probably feel the effects of this.
    • the linkage to the Operational, Project, Services and Capability Viewpoints disappears. Without the Systems Views and systems you lose the ability to describe how systems realise capabilities or the operational needs. Equally without Systems you can’t describe when these are delivered or removed from service and therefore the effects on capability. How can you then implement a service?

    All in all this is pretty serious. I therefore posted a question on the DODAF Group on LinkedIn asking what people were planning to do as a result of the advice to migrate the Systems Views to the Service Views. I only got one responder, but a valuable one in Charles Thornburgh. He correctly pointed out that it wasn’t mandatory. It is still, however, official DoD advice. He also pointed out that a lot of the best brains were engaged in looking at this including DoDAF Meta-model Working Group to determine if there is a difference in modeling Services vs. Systems. I pointed out that I’d thought that this would have been done before advising users.

    It could be quite a while before the analysis and impact assessment is complete. The easiest action would be to remove the official advice from the DODAF 2 website until such time that the way forwards has been agreed. Maintaining the advice knowing that there are significant problems doesn’t seem like a sensible idea - what happens if the advice is acted on? There will be some very unhappy bunnies in industry if the advice is withdrawn much later.

    Has anyone actually followed this advice? What did you do / how did you approach this? Any helpful suggestions for the rest of us?

    Comments

    Comment on this article

    Related Articles

      {REL[6049][related1_blog]nYTq5cZ1REL}

      Sharing tags:

      External Links

      ‘Logical’, ‘Abstract’ or ‘Concept’ Instead of ‘Operational’?

      by Nic Plum on Monday 19 April, 2010 - 15:46 GMT

      Posted in Architecture FrameworkMODAFTRAK

      Tags: conceptdefinitionlanguageontologyoperationalperspectivetrak

      Abstract - from the New Oxford American DictionaryThe language used in a framework definition is important to its “user interface”. Get it wrong and you build in problems for the long term. It is, however, difficult to get the ‘right’ name - one that is readily understood and where everyone has the same understanding.

      In TRAK we have an ‘Operational Perspective’ - that provides the elements and viewpoints with which to describe the problem in terms of need, exchanges and behaviour in a way which is free from implementation or any particular solution or technology. The trouble is that the word ‘operational’ is all too readily associated with the day to day running or operation of the system. This has caused confusion in the rail domain. Of course any confusion can lead to the use of the wrong architectural views or for an unnecessary restriction in scope - all of which can lead to inconsistency and which make it harder to exchange or collaborate on architecture models.

      Back to the problem in hand. If we don’t use ‘Operational’ what could we use instead? ‘Logical’ is a possibility. It is used in other frameworks, such as Zachman, where it is a perspective that represents the logical information systems model which is free from the technology (another perspective). It looks as though MODAF would like to use ‘logical’ since the pre-amble to the MoD’s ‘The MODAF Operational (OV) Viewpoint’ states ‘the OV Views illustrate the Logical Architecture of the enterprise; ie whilst they show what is required to conduct an (operational or business) activity, they do not consider how a solution may manifest itself when implemented.’  The trouble is, would the average user equate ‘logical’ with implementation-free or would they associate mathematics, rules or some alternative “Spockian” image with the term?

      ‘Abstract’ is another candidate. Looking in the New Oxford American Dictionary, produced by the Oxford University Press (OUP),  that comes with the Apple Dictionary application we have:

      ab•stract
      adjective |ˈabstrakt|existing in thought or as an idea but not having a physical or concrete existence : abstract concepts such as love or beauty.

      • dealing with ideas rather than events : the novel was too abstract and esoteric to sustain much attention.
      • not based on a particular instance; theoretical : we have been discussing the problem in a very abstract manner.
      • (of a word, esp. a noun) denoting an idea, quality, or state rather than a concrete object : abstract words like truth or equality.
      • of or relating to abstract art : abstract pictures that look like commercial color charts.


      This looks to be promising. It is quite clearly nothing to do with a particular solution or realisation. Is ‘Abstract Perspective’ only a term that an air-head would use? It certainly seems to be better than keeping the current ‘operational’.

      Or would it be better just to use ‘Concept’....?

      Not easy. The request to change the name has been made on SourceForge and it will be interesting to see what comments or reaction develops.

      Whatever the outcome there will have to be some changes on the site wiki…. :-(

       

      Comments

      Comment on this article

      Related Articles

        {REL[139][related1_blog]nYTq5cZ1REL}

        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 - 2011 Eclectica Systems Ltd.