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]2FmC68GHREL}

Sharing tags:

• MODAF is Dead - Long Live ‘NAF’? (30% )
• Risk and Threats - The Common Ground Between Security and Safety? (30% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )
• 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% )

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

What is the Point of this Site?

Indeed, what is the point of this site? Why go to the trouble and suffer the frustrations in creating it? Why not simply “get a life”?

Background

It started with TRAK (very nearly a Hot Chocolate hit there!) - The Rail Architecture Framework - which I’ve been developing over the last year for London Underground Limited. This is based on the MODAF, the MoD Architecture Framework which is important to the rationale for the site. At the beginning it was thought that a framework would need to contain rail-specific constructs and views but in the end we realised that we’d created something that was domain or industry-free. It should have been obvious from a system-thinker’s perspective, but the journey to this point is just as important as the realisation.

Of course in developing and trying out the views, the UML profile and the plugin for Sparx Systems Enterprise Architect modelling tool similar questions arose. It was also valuable because it meant that the development was led by the pragmatic, down to earth needs and problems faced by architects delivering views and models to meet deadlines.

In reality the experience in TRAK is building upon the experience over many years first at the MoD at Abbey Wood and then at the Architectures Lab at Malvern. Most of the support and help was provided by the group itself. It had to be this way because we were modelling in the days before MODAF and discovering and making rules based on practical experience. Like most things in life you need to experience failings and problems to properly appreciate the wisdom of others!

Geneology

Since DODAF first appeared many other related enterprise architecture frameworks have appeared. They all continue to borrow ideas from each other as they evolve.

Many Enterprise Architecture Frameworks are Related to DODAF

The Perceived Need - Support

The sorts of areas where help, advice and support is needed for enterprise architecture include

• frameworks
• definition - what must appear
• advice - what should appear
• what a framework can represent, what it can’t represent
• when something else is best used to represent
• modelling style
• how to represent particular configurations, functionality
• modelling patterns or conventions often encountered
• types of model
• utility or usefulness
• best views for a purpose
• fitness for purpose
• when to use a model / when not to
• dealing with stakeholders
• applicability of views to common development scenarios / lifecycle e.g. design review points, activities
• collaboration
• preparing for sharing models
• working with remote colleagues
• keeping in sync - models & understanding & consistency
• dealing with privacy
• communication - the primary objective as we need to be able to communicate findings, analysis, implications (as interesting as it might be it’s not for our own benefit!)
• detail, scope - what to include / leave out
• adjusting for stakeholders - maintaining the model & avoiding the simple powerpoint/visio syndrome (“just a diagram”)
• organisation of views / model - navigability - “telling a story” / the user-interface of the model presented
• documenting the model, findings
• tools for modelling
• limitations
• features
• compatibiity/interoperability with other tools
• model / repository organisation
• model/repository consistency

Apart from the very obvious framework-specific part many of these areas overlap and face common problems. Solved once the solution ought to be able to help others even if the framework being used is different.

Then there’s the people side. Many of us who work with one framework have and will work with others so why create silos? As with the models produced it makes sense to try and reuse, adapt and extend wherever possible. The centre of gravity ought to reside with the users and user-generated content not with the standards themselves - it has to be of use and pragmatic.

It therefore seemed if a means of enabling support were provided, to recognise this overlap between all the DODAF-related frameworks.

The Purpose

In short

The purpose of the site is to provide a means for users and practioners of DODAF/MODAF-related architecture frameworks

• to get practical advice and help
• to give advice and help

to help create, share and build-upon (extend) existing architecture models.

The watchwords are - useful, practical, understandable

The Belief

It might be that everything is already covered - there’s enough “how to”, FAQ, examples, advice when faced with typical project situations. It might be that as a bunch we like best to keep quiet and keep it all to ourselves or that we believe that knowledge is power. I’d rather believe that we like helping others (and in doing so we often help ourselves).

If you’re in the latter category then please sign up and please contribute - whether comments on entries, discussions in forums, examples of architectural views or adding to the wiki. You never know when it might prove useful. It’s also self-help and therapeutic to share!

Comments

Comment on this article

Related Articles

{REL[129][related1_blog]2FmC68GHREL}

Sharing tags:

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

Forums

• See discussion thread in forums

External Links

• Wikipedia - Enterprise Architecture Framework
• The MOD Architecture Framework -  (GOV.UK site
• Wikipedia - DODAF
• DODAF - version 2.02
• NATO Architecture Framework (NAF)
• Department of National Defense/Canadian Forces Architecture Framework (DNDAF)