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

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

Sharing tags:

• NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF? (10% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (10% )
• Risk and Threats - The Common Ground Between Security and Safety? (10% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )
• Definitions - What Exactly is a Risk? (10% )

External Links

• DODAF 2 website - DODAF Viewpoints and Models
• DODAF 2 website - Systems Viewpoint

Tom Graves / Tetradian Commentary on TRAK

At the risk of descending into the BBC’s habit of trailing their own programmes ...

Thanks to a post from Rich Hilliard on the TRAK group on LinkedIn I came across Tom’s article on his blog about TRAK, posted on Saturday titled ‘How to get enterprise-architecture on TRAK’:

At last – at last – there’s now a ‘framework for enterprise-architecture’ that’s actually worthy of that title. ...

Although in a few places this does show its physical-engineering heritage, in effect this is a generic high-level metamodel suitable for use in enterprise-architectures for any type of organisation. (This is a very important contrast to the metamodels in TOGAF or even in Archimate [Business, Application and Technology layers], which at present are effectively usable only for IT-centric architectures in information-oriented enterprises such as banks, finance, insurance and the like.) ...

and it finishes

Anyway, definitely worth a detailed look. Even from a fairly cursory review to date, my own strong opinion is that for TOGAF-type architecture-developments that could touch any space beyond IT, we should all standardise on something like this as a base-metamodel, rather than the as-yet unusably-incomplete one provided in the TOGAF 9 specification.

Recommended – very recommended.
...

Not all bad then!

Comments

Comment on this article

Related Articles

{REL[5979][related1_blog]TIVL1r28REL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (33% )
• Definitions - What Exactly is a Risk? (33% )
• Just When You Thought It Was Safe - EntiTy Returns (33% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (33% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (33% )

External Links

• Tom Graves/Tetradian Blog

TRAK LinkedIn Group Created

It’s been a busy week. Yesterday saw the first meeting of the TRAK Steering Group in London chaired by the Department for Transport. No doubt more on that in another post.

Partly because everyone seems to do it and because it makes sense group has been created on LinkedIn (https://www.linkedin.com/groups?mostPopular=&gid=3256940) where topics concerning TRAK can be aired.

This in no way replaces any of the TRAK discussion forums on Sourceforge (https://sourceforge.net/apps/phpbb/trakviewpoints/ and https://sourceforge.net/apps/phpbb/trakmetamodel/) since LinkedIn is a closed community - you can’t see it in a search engine and you ahve to be a member - and TRAK is very much about keeping people informed and involved and the placed to get involved in shaping TRAK is very definitely on Sourceforge, not LinkedIn.

It just seemed sensible to provide another means for folks to chat and also to discover TRAK that perhaps don’t use Sourceforge - it takes all sorts to make the world tick!

Comments

Comment on this article

Related Articles

{REL[164][related1_blog]TIVL1r28REL}

Sharing tags:

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

Forums

• See discussion thread in forums

External Links

• trakviewpoints project discussion forums on Sourceforge
• trakmetamodel project discussion forums on Sourceforge