Page 1 of 2 pages  1 2 > 

Keep Clear Separation Between the Concerns that Each Architecture View Addresses

ISO/IEC 42010 advocates or, more likely, is predicated on the assumption that an architecture description of a complex system needs many architecture views.

Since the initial publication of IEEE Std 1471, there has been wide acceptance for the use of multiple viewpoints to express architectures of systems, and for system concerns as a primary motivation for the content of architectural descriptions. This revision builds upon these core concepts, and captures additional consensus in the areas of architecture frameworks and architecture description languages.

Each view describes the real world architecture and addresses a different set or concerns or questions posed. The typical concerns each view addresses are defined within an architecture viewpoint which is a specification for each view type. Note that this use of ‘viewpoint’ is not that same as that used in MODAF and DODAF where viewpoint is a collection of architecture views, not a specification.

Pretty obviously these need to overlap so that the reader can move around the architecture description and also understand the context for any part. For example there’s no point in showing a function without showing the thing that performs the function and this in turn might realise or implement part of a concept. Overlapping views are therefore a good thing. This in turn requires overlap between the defining viewpoints (ISO terminology).

Whilst some overlap is always good, too much overlap in invariably bad. If there is too much overlap in the things that can be shown in different view types then it becomes difficult if not impossible for the reader to understand the purpose of each view type and differentiate between them. It also leads to inconsistency in the way that an architect approaches the task since if the same content can be shown on 2 view types one architect might choose one view type and another might choose the second. From the reader’s point this is confusing since there is no clear expectation in terms of finding particular objects and relationships. In essence it is a human factors problem since with too much overlap the affordance suffers as there is no longer a clear distinction between view type and the likely view content. From the point of ISO/IEC 42010 the risk is that there is no longer any clear distinction in terms of the concerns addressed by each view type.

This is best illustrated by practical example. The following is taken from MODAF 1.2.004 and looks at the MODAF::SV-1 Resource Interaction Specification View vs the MODAF::SV-2 set (SV-2a System Port Specification View, SV-2b System Port Connectivity Description View and SV-2c System Connectivity Clusters View).

The MODAF System Viewpoint states:

The primary purpose of an SV-1 is to show resource structure; i.e. to identify the primary sub- systems, posts and roles and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.

but goes on to add:

In its simplest form, an SV-1 can be used to depict systems and sub-systems, and identify the interfaces between them; however, this rarely adds more to that which can be shown in an SV-2, product.

and

If possible, an SV-1 will show resources and their interactions for the entire architecture on the same diagram

It’s immediately confusing since the stated intent is to show structure (despite the name of the view) but then adds interactions and itself identifies that there is hardly any difference between the SV-1 and SV-2 since both can legitimately be used to describe both structure and identify interfaces between the structural parts. In terms of the definition there is no distinction between the different concerns addressed and therefore you might choose the SV-1 to describe structure and interaction whilst I might choose the SV-2. [Note: The MODAF::SV-2 can only be used for System and Software not for Human Resource (Organisation, Job and Role) unlike the MODAF::SV-1]

At 1.2.004 there is even less differentiation since it now can be used not only to identify but to characterise interfaces:

If SV-1 is developed as a composite structure model (e.g. in SysML, UML), Resource Ports may be used to convey how interactions are dealt with internal to the resource when the resource has parts. Resource Ports may also specify the interfaces they require or provide.

(As an aside there are also inconsistencies between what appears in the textual description, the data objects and the fragment of simplified metamodel since the data objects section does not appear to list all the types of object that can appear on a SV-1.)

There is so much overlap between the MODAF:SV-1 and SV-2 that it is no longer clear what distinguishes the two (you can show structure and interactions on both) and therefore why you need both. Certainly the stated emphasis on structure isn’t reflected in the definition of the SV-1.

To be fair to MODAF this looks to be a problem inherited from DODAF:

Systems Viewpoint. SV-1: Systems Interface Description

A primary purpose of a SV-1 DoDAF-described Model is to show resource structure, i.e., identify the primary sub-systems, performer and activities (functions) and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability.

The NATO Architecture Framework, version 3.1 doesn’t state a structural intent quite as boldly although it does say for the NSV-1 System interface description:

In a sense NSV-1 and NSV-4 provide complementary representations (structure and function)

If structural were limited to composition and configuration relationships and exclude flows then the SV-1s would be structural. They don’t, however, and the fact that their name includes Interaction or Interface (not structure) suggests that the intended focus of each of these views are the flows. Very much a case of mixed messages which doesn’t help the architect.

This shows that it is vital to keep clear water between the focus and therefore the concerns addressed by each view type.

Comments

Comment on this article

Related Articles

{REL[6104][related1_blog]GpnAueGSREL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (30% )
• MODAF is Dead - Long Live ‘NAF’? (30% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (10% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (10% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )

External Links

• ISO/IEC FCD 42010 Systems and Software Engineering — Architecture Description - latest draft. 8th June 2010
• The MODAF System Viewpoint. 26th April 2010
• DODAF 2.02. SV-1:: Systems Interface Description
• ANNEX 1 TO AC/322(SC/1-WG/1)N(2009)0005-ADD2 NAF V3.1 CHAPTER 5 5.2.6.1 NSV-1 System interface description. 1st March 2010

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

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

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

Some 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.

Anyway, 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]GpnAueGSREL}

Sharing tags:

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

External Links

• NATO Architecture Framework home - external link
• NATO Architecture Framework Views (Capability View, Operational View, Programme View, System View, Service-Oriented View, Technical View, All View)
• NATO Architecture Framework Subviews
• MODAF Viewpoints
• MODAF Views
• TRAK Views

Page 1 of 2 pages  1 2 >