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

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

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

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.

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:

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:

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

External Links

• MODAF Metamodel 1.2.004
• The MODAF System Viewpoint(SV) 17th February 2009.
• INCOSE‐TP‐2003‐002‐03.2. INCOSE Systems Engineering Handbook v. 3.2. January 2010
• TRAK Metamodel. 26th February 2010.