Listing all articles in The Residual World under the category 'Standards' :

What Would a TRAK View Look Like in a Graph Database? Part 1

by Nic Plum on Monday 31 August, 2015 - 15:38 GMT

Posted in Architecture FrameworkTRAKStandardsTools

Tags: complianceconformancegraphiso42010standardtraktripletuple

The trouble with using a lot of the enterprise architecture tools is that they were originally developed for software development. This means that they tend to focus on / provide functionality for the expression of objects rather than relationships and they typically use software notation to describe the relations, for example the UML. If you are primarily interested in relationships it is then quite hard to exploit and query the relationships. There is also the inevitable problem with the readability of the result particularly for the non-technical and non-software audience who haven’t grown up with, say, UML Class diagrams.

TRAK is defined in a solution-agnostic way and specifies that all the relationships must be 1) visible; 2) labelled so that the assertions / tuples can be read as simple sentences e.g.

  • System. A is configured with B. Software, or
  • Argument. D supports Claim. Y

This means that it is easer to read. It is still up to the implementer and the notation (an Architecture Description Language in ISO/IEC/IEEE 42010 terminology) how this appears when visualised. You might, for example, get the following. A UML Representation of a TRAK Tuple

This isn’t too bad to read thanks to the TRAK requirements to make everything explicit but if you want to follow relationships and display the results you typically have to dive under the hood create a query that has multiple table joins. Even then the result is a table which isn’t the best way of presenting a structure. If you wanted to recurse down a structure to display something and its parts you might not be able to do this without knowing how many levels you needed to traverse to retrieve the results.

It soon gets all too difficult which is a shame because having created the relationships the real power over a ‘flat’ diagram is the ability to query them to answer questions.

Is there another way? In a nutshell, yes. A TRAK view is defined as a set of assertions / tuples / triples. In mathematical terms these are ‘graphs’ and now you can get graph databases that store graphs rather than tables. It’s therefore a straightforward exercise to create a TRAK view in a graph database using the governing TRAK viewpoint (which constrains what tuples can be shown) and the TRAK metamodel as the ‘domain model’ for reference.

I’m in the process of evaluating the free community edition of the Neo4J graph database. The plan is to create a complete architecture description within Neo4J to show how it might look as a set of graphs. Neo4J is pretty straightforwards and the reference manual, online training and free e-books are valuable. I wanted to produce the equivalent of a TRAK architecture description that is already online so I’m porting the one that was used to support the formal conformance assessment of TRAK against ISO/IEC/IEEE 42010:2011.  This particular TRAK architecture description makes a lot of use of the MVp-04 Assurance Viewpoint since it describes a structured set of claims (of compliance), arguments and evidence.

This has been achieved using the CSV import capability of Neo4J to import the elements and their properties. For example the import of the TRAK requirement elements was achieved using:

LOAD CSV WITH HEADERS FROM “file:///requirements.csv” AS row
CREATE (n:Requirement)
SET n = row,
n.`object ID` = toInt(row.`object ID`),
  n.`AD exchange element owning ID` = row.`AD exchange element owning ID`,
  n.`AD exchange element owning organisation`=row.`AD exchange element owning organisation`,
  n.`reference URL` = row.`reference URL`,
  n.`sequence ID`=toInt(row.`sequence ID`),
  n.`requirement ID`=row.`requirement ID`,
  n.`compliance level` = row.`compliance level`,
  n.`requirement paragraph` = row.`requirement paragraph`,
  n.`requirement scope` = row.`requirement scope`,
  n.`requirement type` = row.`requirement type`,
  n.`requirement priority` = row.`requirement priority`, =,
  n.description = row.description,
  n.`requirement owning org` = row.`requirement owning org`,
  n.`element author`= row.`element author`,
  n.`created date` = row.`created date`,
  n.`modified date` = row.`modified date`
SET n :Requirement:`Architecture Description Element`

CREATE CONSTRAINT ON (reqt:Requirement) ASSERT reqt.`object ID` IS UNIQUE

All the different TRAK metamodel elements have been imported similarly and connected together, e.g.

LOAD CSV WITH HEADERS FROM “file:///claim_about_requirement.csv” AS row
MATCH (claim1:Claim {`object ID`: toInt(row.Start_Object_ID)})
MATCH (reqt1:Requirement {`object ID`: toInt(row.End_Object_ID)})
MERGE (claim1)-[r:`about`]->(reqt1)
ON CREATE SET r.`connector ID` = toInt(row.`connector ID`);

CREATE CONSTRAINT ON (conn:`about`) ASSERT conn.`connector ID` IS UNIQUE

TRAK also has elements to represent Architecture View so its easy to relate the elements and the connectors to the view(s) that show them.

In Neo4J queries match patterns (think of these as paths through the underlying architecture description - the sets of tuples). Suppose for example I want to show the structure of the standard itself. Off the top of my head I don’t know how deep the structure is but this doesn’t matter since the Cypher query language allow me to recurse to the bottom.

The query to show the requirement structure is simply:

MATCH (a:Standard {name:'ISO/IEC/IEEE42010:2011 Systems and Software Engineering - Architecture Description'})
MATCH (a) -[r:`has part`*1..]->(b)
RETURN a,b, r

which simply tells Neo4J to start with the topmost node - a TRAK ‘Standard’ and then look for all the outgoing ‘has part’ relationships for as many levels as needed and then return the nodes and relationships. The result of this is shown below.

Equivalent TRAK MV-03 - Structure of ISO/IEC/IEEE 42010:2011 (Partial)

Display full size image.

Finding orphan nodes with no relationships is as simple as:

MATCH (node)
WHERE NOT ((node)—())
RETURN node;

It’s not yet TRAK-compliant. I’ve still got to figure out how to get the cascading style sheet to display the TRAK metamodel element type (‘label’ in Neo4J) but it’s already a very useful tool to exploit the relationships made. This is with Neo4J out of the box as a bare database i.e. with no application built on top of it. It ought to be relatively straightforwards for a software engineer to extend this to implement the TRAK viewpoint definitions and visually query the database. Or I should add that it is if you’ve got a simple and explicit metamodel because it’s easy to square this with the graphs produced. If all you’ve got is a more indirect and complicated one enforced via a UML profile it’s a much harder task and you can’t then easily verify the result against the original views in the modelling tool.


Comment on this article

MODAF is Dead - Long Live ‘NAF’?

by Nic Plum on Monday 02 March, 2015 - 23:00 GMT

Posted in Architecture FrameworkMODAFNAFStandards

Tags: architecture frameworkmodafnafnato

Integrated EA presents an interesting and useful opportunity to learn, listen and talk about enterprise architecture, mostly but not always from a defence and aerospace application and not just from the UK but other parts of Europe and the world that have experience in the application of MODAF, DODAF, NAF and similar architecture frameworks. The event was created by Ian Bailey of Model Futures who was one of the ‘elves’ behind the creation of MODAF and who has maintained parts of the documentation and the MODAF metamodel (M3) since. This year’s Integrated takes place this week on 3/4th March 2015 at One Great George Street, London.

Ian has posted on the Integrated EA blog about the imminent demise of MODAF as a distinct architecture framework since it is about to join forces with the Nato Architecture Framework (NAF). Ignoring the name, NAF hasn’t had a good record over the years in terms of its documentation and because the metamodels for NAF and MODAF were significantly the same it was often the case that architects would use MODAF documents to produce NAF views (or ‘models’ as NAF calls them - the terminology differs between frameworks and the ISO/IEC/IEEE 42010 standard).

The post makes for interesting reading. In his post Ian mentions TRAK:-

MODAF spawned TRAK, which was free of the legacy user base MODAF had, and so was able to do a lot of things we’d been trying to do in MODAF for a long time

I’m still jealous of the freedom Nic had when he developed TRAK, and I still like the idea of an open-source framework.


so we must clearly be doing something right which is nice to know as Ian knows his stuff! Presumably this must also apply to NAF - unless they’ve ditched their roots or elected not to make some aspects backwards-compatible.

On this very site in 2011 I suggested that it would be a good idea to merge MODAF and NAF since they were converging, it didn’t seem sensible to have two similar but different sets of documentation etc. and the overhead in terms of maintenance and development cost must be significant. In the interim period we’ve had the economic downturn / crash and the financial imperative for efficiency / cost saving must be even greater. What never occurred to me was that MODAF would disappear or be absorbed into NAF. It therefore seems very unfair that the reward for MODAF being more consistent, having better documentation and being ahead is to lose its own identity. I suppose there is still much collaborative effort but all of the user-facing terminology seems to be very much that of NAF.

A quick look at the new set of NAF::’Models’ ( aka MODAF::’Viewpoints’) shows that there has been some attempt to simplify the naming of the models/viewpoints (something TRAK has had from its inception). It’s also nice to see some principle of organisation for the models/viewpoints in the grid view. This is very reminiscent of Zachman. They have also attempted some rationalisation to improve consistency. What seems to have disappeared is the MODAF Acquisition Viewpoint and it looks as though the MODAF AcV-2 Programme Timelines View is now part of the NAF:Logical Specifications. [ How any high level architecture description can be considered to be a ‘specification’ is beyond me since it doesn’t support the basic ideas behind attributes of requirements let alone completeness of specification. This seems to be the Holy Grail of folks with a software background but inconsistent with readability / understandability / basic user interface principles e.g. if it’s complete enough as a coded specification it’s also likely to be highly technical, use formal notation that is capable of supporting machine-validation and completeness-checking and increasingly impenetrable to the user. This also ignores the “..ilities” and non-functional aspects of a specification because most notations seem to be designed to describe structure, messaging or behaviour.] The MODAF AcV-1 which described the structure of projects seems to have disappeared. It ought to fit under the NAF Structural heading but this is occupied by the NAF Logical Scenario which is an entirely different view so there are clearly going to be some significant problems to overcome in eliminating MODAF viewpoints and merging MODAF views with the NAF cousins.

If only the new NAF would take on board some reasonable amount of compliance with the international standard in terms of terminology we’d start to see some real progress based on standardisation. There are encouraging signs that someone behind NAF is taking some notice of the standard e.g. ‘A3 Architecture Correspondence. ISO 42010’ which I assume has something to do with correspondence rules but without any detail it’s impossible to see whether this complies. “It’s progress Jim, ..”.

MODAF might be nearly dead but it’s very hard to shout “long live NAF” - yes, Ian, something must really be done with that acronym otherwise we’ll have have “NAF models ..”, “NAF specifications” … and you can only have so much NAF-ness!  wink


Comment on this article

Definitions - What Exactly is a Risk?

by Nic Plum on Tuesday 12 March, 2013 - 22:30 GMT

Posted in Architecture FrameworkTRAKStandards

Tags: defencedefinitiondodiecnistsafetysecuritystandardtrakusa

NIST logoIEC logoUS DoD logo

Creating a definition sounds as thought it ought to be easy. It isn’t for many reasons - some of these are not so much technical as the process by which consensus is reached and the need to get consensus. For example the need to get consensus might mean that at times a weaker definition escapes because it was too difficult to get consensus with a tighter one.

Why do we care? Well there is a particular and a more general reason. The more general one is that the graphic blocks we use to represent the real world things have definitions and therefore the architect is supposed to select the most appropriate block to represent the real world thing based on the description. We can’t just choose anything otherwise we end up “head-modelling” where the verbal description we provide is not supported by the semantics of the model we’ve created (the model in our head is not the one on paper). If the description is wrong it might not be the right block to use (you wouldn’t represent ‘tank’ with a ‘tree’).

The particular reason is that we’ve a working group in TRAK looking to see if and how it is possible to extend TRAK to enable it to be used to address typical safety-related and security-related concerns. One of the starting points is therefore a review of general literature and particularly standards to identify the potential concepts or entities likely to be needed. In doing so we’ve found some potential problems with definitions.

A candidate entity is risk. What is a risk?

IEC 61508:2010

combination of the probability of occurrence of harm and the severity of that harm


Mishap Risk. An expression of the impact and possibility of a mishap in terms of potential mishap severity and probability of occurrence.


The net mission/business impact considering (1) the likelihood that a particular threat source will exploit, or trigger, a particular information system vulnerability and (2) the resulting impact if this should occur.

There is a common thread. Many other standards also have very similar forms of definition. None of these, however, defines what a risk actually is The analogy is defining force as the product of mass and acceleration - it tells us nothing of what force is. None of the above are therefore definitions of risk they just indicate how we might derive a metric for it. One of the principles in defining something has to be that the definition is independent of other variables or an implementation. In the above if risk didn’t involve probability of occurrence it would mean that the concept of risk itself had changed which isn’t true.

My dictionary provides:

a possibility of harm or damage

IEC 61508:2010 defines a Hazard:

potential source of harm [Guide 51 ISO/IEC:1990]..

’ which is fine but then in the note that follows it states ‘….for example, release of a toxic substance…’ which looks to be a hazardous event not a hazard.

All of this means that it is harder and takes longer than it should do to analyse and form a view of a pragmatic compromise because you have to examine every word and be selective in what you choose to accept and what you choose to reject. You cannot blindly assume that any standard is correct since it is as much the product of gaining consensus as it is the technical content. You have to be a skeptical enquirer and constantly challenge. Too often folks put such committees on pedestals and don’t stop and think.


Comment on this article

All articles/posts © of the respective authors

Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.