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 = 'Capability'

Entries that have been tagged with 'Capability'.-

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]95q7XkSMREL}

    Sharing tags:

    External Links

    Perspectives - Structure / Grouping of TRAK Viewpoints

    by Nic Plum on Sunday 06 December, 2009 - 09:52 GMT

    Posted in Architecture FrameworkTRAKStandards

    Tags: capabilityconceptieee1471iso42010managementoperationalperspectiveprocurementsolutiontrak

    —Edited to reflect changes in names of TRAK Enterprise and Concept Perspectives—

    Architectural frameworks normally provide ways of grouping views that have a common aspect and these collections are known as perspectives.

    TRAK provides the following perspectives:-

    They provide a way of simplifying and organising the architectural description.

    TRAK defines a set of architectural viewpoints and view contents. Elements shown on a view have to be part of the underlying metamodel and can only be connected using the allowed relationships. TRAK specifies what can be shown and how it is presented and organised. This is shown in the context of IEEE 1471 in Figure 4?1. It is the ‘architecture element conforms to metamodel’ relationship outside the IEEE 1471 space and the ‘framework defines architecture viewpoint’ and ‘framework defines perspective’ that provide conformity and consistency.

    IEEE 1471 Model - with links to TRAK Metamodel

    IEEE1471 Conceptual Model with TRAK Metamodel Elements Added

    Each TRAK viewpoint (and therefore view) is designed to address specific concerns or questions.

    Enterprise Perspective

    This perspective covers the enduring capabilities that are needed as part of the bigger enterprise. These are high level needs that everything else contributes to and form part of the long term strategic objectives that need to be managed. It provides a mechanism to link into the higher level goals such as ‘Keep London moving’.

    Concept Perspective

    The concept perspective covers the logical view of what is needed. It covers the logical connection of concept nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It provides a means of stating the operational exchange needs and information required.

    Procurement Perspective

    The procurement perspective provides a top level view of the solution to the problem outlined in the capability perspective and developed in the operational perspective in that it provides a way of showing how projects deliver solutions to provide capability. It provides a way of showing time dependency between projects and is an essential prerequisite for investigating capability gaps in the capability perspective. It also provides a mechanism for showing how organisations and projects relate to the systems being delivered.

    Solution Perspective

    The solution perspective provides views of the solution or potential solution, recognising that there may be many potential solutions which might meet the logical needs expressed in the operational perspective. Functional views provide a means of describing the behaviour in terms of functions, activity, sequence, state and interactions. Physical views describe how the system is organised, how information is routed and where parts are or must be.

    Management Perspective

    The management perspective covers views that are concerned with the management and production of the architecture products. It enables the scope of any architecture task to be defined and the provides ways of recording what was done and capturing the intended understanding so that the architecture can be provided to others or re-used.

    Comments

    Comment on this article

    Related Articles

      {REL[126][related1_blog]95q7XkSMREL}

      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.