RW - Navigation

RW - Recent

Last 10 entries [comments]:


Last 10 posts [threads/views]:


Last 10 pages updated:

There are 487 wiki pages in total.

RSS logoRSS Feed

The Residual World::Tag = 'Solution'

Entries that have been tagged with 'Solution'.-

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

    Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views

    by Nic Plum on Friday 16 September, 2011 - 11:19 GMT

    Posted in Architecture FrameworkTRAKStandards

    Tags: adlarchitecture description languagearchitecture frameworkimplementationsolutionspreadsheettemplatetrakuml

    ADLs and Architecture Frameworks

    Any architecture description language, e.g. UML, BPMN, ArchiMate potentially can be used to represent the views in any architecture framework. Whether they can or not depends on whether they have the necessary concepts/entities to suit those in the architecture framework and architecture viewpoint that governs the view content. The reality is however that as ADLs have been developed for different and often more generic purposes they all have limitations when used for an architecture framework. They may, for example, lack concepts that are needed or they might have rules which mean that relationships that are needed cannot be established. In the terminology of ISO/IEC 42010 their concerns might not align with the concerns addressed by the architecture framework and one or more architecture viewpoints within that framework.

    Of course such a central assessment not only applies to UML but for any other language used to represent TRAK architecture viewpoints. After all this is architecture description and this is what it’s all about, surely - identifying the relationships and communicating them? Trouble is I can’t see anyone else doing it (or if they are they keep it out of the public gaze). For the life of me I can’t understand why you wouldn’t want the users to to use a tool or use a particular ADL without knowing the implications and limitations of this implementation. It’s inevitable that there are trade-offs because the ADL wasn’t designed for the specific purpose.Even if a view cannot be represented there is usually a workaround. Even if there aren’t workarounds it will only matter if the concerns of the task sponsor require the viewpoint that cannot be implemented. Knowing what you can and can’t do with a tool and with an ADL in that tool and therefore the suitability of both for the task(s) is important. How many architecture frameworks do you know that make this information publicly available?

    The assessment of UML suitability to represent TRAK architecture viewpoints is part of the implementation of TRAK i.e. solution

    The Assessment of UML Suitability to Represent TRAK Architecture Viewpoints is Part of the Implementation of TRAK i.e. Solution


    This mapping between ADL and architecture framework and therefore the suitability of the ADL for use seems to be something that is traditionally a dark secret.  In the interests of keeping everything in the open so that the user can make an informed decision I’ve mapped UML (as implemented in the UML profile for TRAK project on Sourceforge) against TRAK. Specifically I’ve identified the mandatory and optional tuples for each TRAK Viewpoint and compared them against the combinations of UML stereotype that would be needed and identified whether UML allows these combinations and can therefore be used to represent each TRAK tuple.

    Although the TRAK metamodel is tiny by comparison with others (only types of architecture description element can appear in TRAK architecture views) there are a lot of relationships between them and therefore a lot of tuples that provide the many paths or routes through the TRAK metamodel and therefore richness of description available to the user. I think I’m right in saying that a metamodel is really a directed graph (so don’t get misled by the relative prominence of the big block things - they’re not the most important parts).

    What falls out of this is a list of:

    • TRAK Viewpoints (and therefore views) that UML can fully realise - 19 or the 22 TRAK viewpoints
    • TRAK Viewpoints (and therefore views) that UML can partially realise - 2 viewpoints: CVp-03 Concept Item Exchange and SVp-02 Solution Resource Interaction
    • TRAK Viewpoints (and therefore views) that UML cannot realise at all. There is only 1 viewpoint - the SVp-03 Solution Resource Interaction to Function Mapping Viewpoint because UML doesn’t permit a UML::Activity to be connected to a UML::InformationFlow and therefore this either has to be done manually or using a SQL query if the AD is stored in a database.

    Importantly I’ve tried to identify why UML can only realise some viewpoints partially or not at all and the consequences of this with any workarounds.   This sort of situation exists in other frameworks. The difference here is that I felt it made sense not only to be open but to do this once in a central location rather than everyone do it in their own space time and time again.

    Of course it depends on whether the UML profile is sensible (it may not be) and whether my assessment is correct (I’m no UML expert). The spreadsheet on which it is based has been circultaing around theTRAK SG members for some months including Simon Perry from Atego (who understands a lot more about UML than I do).

    It is distinctly possible that there are errors or it can be improved. There is a tracker on the Sourceforge trak project for all of the documents that implement TRAK where you can submit comments or errors spotted. The assessment itself is in the/Suitability of Architecture Description Languages/UML/ directory within the trak project.

    It is part of a big exercise to make things clear and place in full public (i.e. for users as well as tool implementers) so that we have clear mappings between:

    1. TRAK and ISO/IEC 42010
    3. each individual ADL and TRAK

    so that where there are limitations or trade-offs you can see where these occur i.e. they might be in the international standard, in TRAK, an ADL or the implementation of an ADL in a tool.

    Implementing TRAK in Another ADL?

    As part of this exercise I’ve created an Open Office spreadsheet template which can be used to support the assessment of the suitability of that ADL for representing TRAK architecture viewpoints and therefore views. It is the basis of my assessment of the UML profile for TRAK.

    You should use this template so that there is consistency in the approach taken. It is updated in line with the TRAK Viewpoints and TRAK Metamodel definitions.Please consider making the assessment available centrally so that others can find it and so that they don’t have to repeat the exercise. We have the space on the trak project to host these. If anyone has an alternate UML profile of TRAK I’d be interested to see the differences in implementation and this again would need to be assessed. Obviously we really only want representation or mapping for any one particular ADL.


    Comment on this article

    Related Articles


      Sharing tags:

      External Links

      Improving Consistency for Tools - ‘TRAK. Implementation. Architecture Description Elements’ Document

      by Nic Plum on Monday 05 September, 2011 - 15:03 GMT

      Posted in Architecture FrameworkTRAKTools

      Tags: architecture descriptionconsistencydocumentexchangeimplementsolutionstandardtool

      There is a constant need to reduce the scope for inconsistency in any architecture description. TRAK is no different. TRAK has been defined in a way that is free of implementation and using natural language wherever possible. One of the pitfalls of this is the possibility that names will be implemented inconsistently in tools. For example, the attribute ‘start date’ might be called ‘start date’, ‘start_date’, ‘startDate’, ‘Start Date’ and so on. The danger in this is that upon exchange the receiving tool might not recognise this if it is using, say, ‘startDate’.

      I’ve therefore created a document titled ‘TRAK. Implementation. Architecture Description Elements’. To put it into context a couple of diagrams (produced using the OmniGraffle stencil for TRAK):

      Context - the TRAK. Implementation. Architecture Description Elements documents is part of the set of documents that improves consistency of exchange of an AD

      The TRAK. Implementation. Architecture Description Elements Document is Part of the set of Documents that Improves Consistency of Exchange of an Architecture Description

      The TRAK. Implementation. Architecture Description Elements document responds to the logical TRAK Metamodel definition.

      The TRAK. Implementation. Architecture Description Elements Document Responds to the Logical Definition of the TRAK Metamodel

      The document is at

      The purpose of this document is therefore to standardise the naming of the architecture description elements used in any implementation of TRAK, whether graphical or text-based.

      In addition to naming this document also specifies the formats used for attributes such as text, language labels, geographic location and uniform resource identifier. It also identifies the allowed values where an enumerated list specified for an attribute.

      None of this guarantees successful exchange - in a UML modelling tool there will be an extra wrapping applied through XMI which might be at a different version in the sending and receiving tool and in addition even if an element has the same name it might mean something completely different in each. This document is therefore one part of a set of normative measures needed to maximise the chances of successful interoperability between a pair of tools.

      There are a couple of things still left to do, not the least of which is figure out how to specify privacy marking / security descriptor schemes. If anyone knows of any good standards-like sources for these please let me know.

      Any constructive comments via the Sourceforge Tracker set up for implementation of TRAK at


      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 - 2019 Eclectica Systems Ltd.