RW - Navigation

RW - Recent

Last 10 entries [comments]:


Last 10 posts [threads/views]:


Last 10 pages updated:

There are 484 wiki pages in total.

RSS logoRSS Feed

The Residual World::Tag = 'View'

Entries that have been tagged with 'View'.-

Risk and Threats - The Common Ground Between Security and Safety?

by Nic Plum on Tuesday 10 April, 2012 - 21:25 GMT

Posted in Architecture FrameworkTRAK

Tags: def standefenceforumiso42010mil stdontologyrisksafetysecuritysolutionsourceforgestandardthreattrakviewviewpointvulnerability


This is something that has been bumbling around for some considerable time - safety and security. By that I whether there is something useful that an enterprise architecture view can be used for in the system safety and security disciplines.

On the face of it there is quite a bit of overlap. Both are ultimately concerned with risk inherent in a solution design which arises from threats (security) or hazards (safety). Both involve management with the aim to reduce the risk, threat or accident (safety) to an acceptable or tolerable target. I suspect also that security management also uses categories to classify acceptable severity or probability in much the same way that the various system safety management standards in defence do (MIL STD 882D, DEF STAN 00-56). Both also involve mitigation of risk by design - through structure, behaviour, or adherence to a normative process of some sort.

There are bound to be some differences, not the least of which is terminology. In the security area we seem to have constructs like:

  • Threat poses Risk
  • Threat exploits Vulnerability
  • design aka TRAK:Resource (System, Software, Organisation, Job or Role) exposed to Risk (and subsequently that Risk is mitigated by the (improved) Resource or Function (of that Resource)

In the safety area we seem to have constructs like:

  • Failure may present Hazard
  • Hazard can cause Accident
  • Accident poses Risk
  • Resource exhibits Failure

and attributes such as probability, impact, severity.

Anyway it seems sensible to open up the debate so I’ve posted some thoughts in the forums within the TRAK Viewpoints project site on Sourceforge. Something is definitely needed and my hunch is that there is so much overlap that it would be possible to create a Viewpoint that addresses the risk within a solution design. This may of course end up being two viewpoints depending on the concerns and therefore concepts (metamodel stereotypes) and relationships involved. What is needed is more debate and input from those involved with system safety and system security - hence the post. As ever with TRAK the objective is economy so that we have something that is just or barely adequate to describe the concerns and concepts involved and no more.



Comment on this article

Related Articles

    Sharing tags:


    External Links

    NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF?

    by Nic Plum on Friday 25 February, 2011 - 15:45 GMT

    Posted in Architecture FrameworkMODAFNAFStandards

    Tags: meaningmodafnafnatoviewviewpoint

    The NATO Architecture Framework (NAF) has been around for many years now. It has been on a convergence path with MODAF from version 3 (released in November 2007) and the latest version, 3.1 appears to be even more closely aligned with MODAF than ever. I say ‘appears’ since there is only 1 part - Chapter 5 - that has been released and the remainder is subject to an official delay.

    The documentation for NAF isn’t the best as it describes on Wikipedia with respect to version 3:

    The documentation of the NAF Rev 3 views (Chapter 4) does not always align well with the NAF Meta Model (Chapter 5). This is particularly the case with some of the examples, which are based on DoDAF version 1.0. Some NAF users find it useful to first of all refer the official MODAF Documentation - [1]. This is a useful strategy, as the MOD documentation can be somewhat easier to follow, and NAF and MODAF share a common meta-model.

    There is certainly a consistency problem. At version 3 the framework consists of 7 views each of which has a number of subviews. A NAF::View is a collection of NAF::Subviews that are related by the subject matter. This terminology actually came from DODAF 1.X.

    Chapter 7, Architecture Definitions, Terminology and Ontology, 7.2.1 defines NAF::View:

    A set of subviews grouped by purpose.

    clearly a collection of subviews, and defines NAF::Subview as

    A pattern from which to develop individual products by establishing the purposes and audience for a product and the techniques for its creation and analysis.

    Note: this is called Viewpoint in IEEE-1471-2000; perspective is often used in the same sense.

    Under 7.2.3 NAF Metamodel Terminology it then defines NAF::View as:

    A specification of a way to present an aspect of the architecture. Views are defined with one or more purposes in mind - e.g. showing the logical topology of the enterprise, describing a process model, defining a data model, etc

    MODAF 1.2.004 defines MODAF::View as:

    A specification of a way to present an aspect of the architecture. Views are defined with one or more purposes in mind - e.g. showing the logical topology of the enterprise, describing a process model, defining a data model, etc.

    It is clear that the NAF::View definition has therefore been taken directly from MODAF. Unfortunately in cut and pasting they didn’t remember that MODAF is organised using Viewpoints (collections of views) and Views unlike NAF. NAF is therefore inconsistent. It actually has 3 places where View is defined since it also appears in Chapter 5. This is another problem as it isn’t stated where the master source of truth is so that in the event of conflict the user knows which takes precedence. As a general principle consistency is not improved by having something defined in any more than one place.

    This was version 3 of NAF. Has version 3.1 improved matters? In a word, No. Looking at the only part of version 3.1 that is in public view, Chapter 5, the definition is still the same. On top of this in places the description under some of the subviews things like The NSOV-2 view defines…. What appears to be happening is that NAF is adopting the MODAF Viewpoint/View terminology instead of it’s own View/Subview terminology. Unfortunately it’s done this only partially - 3.1 doesn’t define either Subview or Viewpoint for the collection and still has subviews as headings (not views) so we have the strange situation where a view is both the collection and the individual specification. This doesn’t make for good or easy reading.

    One of the advantages of standardisation is that is provides a common language. ISO/IEC 42010:2007 defines a view:

    A representation of a whole system from the perspective of a related set of concerns.

    and viewpoint as:

    A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the tech- niques for its creation and analysis.

    so a NAF::Subview and MODAF::View is closest in spirit to the ISO 42010::Viewpoint (practice is different as neither framework specifies the view content - they are narratives - hence the response by the tool vendors in creating the UPDM to constrain what can appear in the products for tools). NAF uses ArchitecturalProduct to refer to the thing the architect produces in response to the NAF::Subview specification. This term doesn’t appear in the description of the views - another source of inconsistency as often different terminology is used or words are used in senses that aren’t in keeping with the definition of the terms in the metamodel. To be consistent there has only to be one definition and this has to be used wherever that term appears whether in user documentation or architecture description. How can you expect the user to be consistent if the specification isn’t. If you advocate the importance of consistent meaning (semantics) you have be consistent in the specification - none of the casual use that we all use in everyday conversation. You have to be pedantic.

    The NATO Architecture Framework therefore seems to be suffering in the transition to version 3.1 and also because of the similarity between it and MODAF where terms have previously been used in a different sense. Unlike at the start both MODAF and the NATO AF are now very similar. In fact they’re so similar that you have to ask whether it’s worth maintaining two distinct architecture frameworks that are separated only by a small technical gap? As the Wikipedia article suggests you can use the MODAF documentation to help produce NAF architecure descriptions (don’t blame me for the acronym!). The sovereignty gap might be wider but is it really worth the price? Particularly in these cash-strapped economic times it no longer seems to be efficient use of tax payer’s money to maintain the overhead of both - isn’t it about time they reconciled any differences and merged? This has to be a reasonable savings measure in either or both NATO’s and the MOD’s budget.



    Comment on this article

    Related Articles


      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.