Search      Advanced Search

Page 1 of 16 pages  1 2 3 >  Last ›

Nato AF (NAF) Version 4 - A Look at the Definition of View Content

This is a first of what will be many dives into the definition of the NAF v4 looking this time at the definition of view content - a prerequisite for achieving consistency in the exchange / interoperability of architecture descriptions.

This is a first take looking at the definition of view content - a prerequisite for achieving consistency in the exchange / interoperability of architecture descriptions.

Architecture frameworks represent a form of standardisation. They seek to ensure consistency and increase the exchangeability / interoperability of architecture descriptions through:-

• defining a restricted and controlled “grammar” or vocabulary for describing or making statements about the system of interest and its place with respect to the Residual World. This is usually achieved by defining a metamodel that provided the nodes and connectors to produce the views. Defined properly the metamodel provides a set of statements or assertions (‘tuples’) that can be used, for example: ‘System is configured with Software’ , ‘Contract applies Standard’ or ‘Evidence proves Claim’.
• defining consistent view content by defining what architecture description elements (really tuples) must and may appear in each view. This is important not only in terms of ergonomics (visibility and affordance) so that the reader knows where to find or what to expect in each view in terms of subject matter but also when either exchanging or working collaboratively with other offices or organisations - typical MBSE practice when producing an integrated model of the system of interest.
• defining consistency rules that apply across the collection of views forming the architecture description e.g. if ‘System A is configured with ‘Software B’ in one view and ‘System C is configured with Role D’ then if Software B exchanges information with Role D in another view it must also be true that System A has an interface with System C.

Anyway the first part of this examination looks at how well NAF v 4 can achieve consistency of view content.

The NATO Architecture Framework (NAF) version 4 is now with us and is a substantial change to the previous version 3. As we’ve highlighted there were problems in the closeness of NAF vs MODAF which led to the demise of MODAF. MODAF does, however, still live on in the work that seems to be happening to the NAF metamodel termed MODEM. Bizarrely though the NAF version 4 does not make reference to this as the metamodel preferring to make some woolly references to the ability to use ArchiMate or the UAF as the metamodel. This will be the subject of another post but it’s impossible to ensure consistency if you don’t mandate / control the set of bits from which the architecture description is formed.

The defining baseline for NAF v 4 is the document - NATO Architecture Framework. Version 4. Architecture Capability Team. Consultation, Command and Control Board. January 2018

Background

The NATO Architecture Framework version 4 (January 2018)  definition identifies reasons for change:

1.5 Reason for Change

1.5.1 NAF version 3 (NAFv3) was issued in 2007 to support alliance interoperability through the coherent use of architectures, and provide for the re-use of architecture artefacts and products to facilitate the description of systems and applications. However, NAFv3:

• was not consistently applied by projects,
• did not provide a common architecture approach,
• became challenging to maintain due to limited technical resources, and
• did not align with major terms and concepts in the following international standards:
• ISO/IEC/IEEE 42010 Systems and Software Engineering – Architecture Description,

....

1.5.2 NAFv4 addresses the above limitations and is a step towards a single Architecture Framework across NATO and Nations.

and its purpose is:

1.1.4 The NATO Architecture Framework (NAF) provides a standardized way to develop architecture artefacts, by defining:

• Methodology – how to develop architectures and run an architecture project (Chapter 2),
 
• Viewpoints – conventions for the construction, interpretation and use of architecture views for communicating the enterprise architecture to different stakeholders (Chapter 3)

Not Yet Consistent with ISO/IEC/IEEE 42010

There were problems in the use of terminology not the least was that MODAF and NAF used different terms to refer to views and view definitions and neither aligned with the international standard for architecture description, ISO/IEC/IEEE 42010. In highlighting the previous lack of conformance with ISO/IEC/IEEE 42010 version 4 should now presumably conform. It does repeat some of the definitions but unfortunately a lot of the old misuse still persists and there is at least one misunderstanding:

‘1 Introduction

1.1 Architecture Descriptions

1. A Viewpoint is where you are looking from.’

No. A ‘ISO42010::Viewpoint’ is a specification for a view. ISO/IEC/IEEE 42010 is quite clear on this:

A view is governed by its viewpoint: the viewpoint establishes the conventions for constructing, interpreting and analyzing the view to address concerns framed by that viewpoint. Viewpoint conventions can include languages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and other operations on views.

The ‘NAF4::Viewpoint’ harks back to the use of ‘viewpoint’ in MODAF which meant something quite different.

Chapter 2 - Methodology

1.1 The NATO Architecture Framework version 4 (NAFv4) is a standard for developing architectures.

No - it is a standard for developing architecture descriptions - the architectures are the real world things that care not about viewpoints or metamodels and can’t be stored on hard drives. Their descriptions can, however. This is a constant and historical misuse or failure to understand the difference between ‘architecture’ and its description in the version 3 and now version 4 documentation. The ISO/IEC/IEEE 42010 Conceptual model is quite clear about the distinction between System, Architecture and Architecture Description.

There is a fundamental problem if alignment is sought with TOGAF because TOGAF does not recognise that there are these 3 independent concepts - it only supports 2 - it doesn’t recognise the difference between architecture and its description. NAF has made a problem for itself in that it is impossible to comply with both ISO/IEC/IEEE 42010 and TOGAF since their conceptual models are different and the terms mean different things. NAF needs to pick a consistent set of standards to adhere to if it wants to assure consistency of output of architecture descriptions.

This gets confusing where architecture description and architecture views are used to highlight issues with the real world architecture. The ‘architecture’ term is consistently misused in the names of NAF views e.g. A7 - Architecture Meta-Data (‘concerned with the meta-data for the architecture and its Views’ - should be architecture description).

5.14 Architecture Framework

Architecture Framework TOGAF v9.1, page 45]: “is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

NAF v4 claims to conform to ISO/IEC/IEEE 42010:2011. The standard defines architecture framework as:-

architecture framework

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders

It says nothing about tools or target state.

Conforming to a standard means that you use terms in the sense that the standard defines - it doesn’t mean pick and choose from any other source at will.

Chapter 5 - The Structure of the NATO Architecture Framework

1.5.1 The NAF is designed to ensure that architectures developed adhering to it can be understood, compared3, justified and related across many organizations, including NATO and other National Defence initiatives.

Ignoring the incorrect use of ‘architecture’ (NAF are repeat offenders in misuse of ISO/IEC/IEEE 42010 terminology) it is clear that the intent is that there is a a set of requirements for architecture descriptions conforming to the NAF. The assumption has to be that it is this document that forms the specification for NAF Views since there is no other document containing User Requirements (to put it in military terms).

So where exactly are the requirements against which users can produce NAF views?

NAF 4 Requirements for View Content

NAF 4 uses the correct term, viewpoint, as a specification for a view content. Previously in NAF 3 a view was a collection term and a subview referred to a particular definition.

Consistency requires an unambiguous set of requirements defining the content of each view (otherwise different architectures will produce wildly different content).

A typical example of the specification of a view against which a “NAF-compliant” architecture description must conform is the C1 - Capability Taxonomy (Chapter 3 Concept Viewpoints, page 74):

Looking at this in terms of the specification of view content:-

Definition of NAF v4 - C1 Capability Taxonomy View

• what are the architecture description elements (nodes, connectors forming tuples) that are required? Note that specifying nodes alone is not sufficient to unambiguously specify content - this is one of the reasons why a tuple should be the smallest unit of architecture description
• what is the minimum acceptable content?
• what is the allowed content - usually for extra context?
• what are the properties of the elements needed to address the concerns?
• what are the allowed overlaps with other views?
• where are the consistency requirements defining how this impacts the collection of views in the architecture description?

In terms of addressing the original need to improving consistency this does nothing.

At least in the old NCV-2 definition it stated that you required Operational Objective and Capability elements which although not sufficient or complete was a lot better than the current view definition.

If consistency is really the aim NAF ought to spend less effort on presentation and organising via the new (Zachman-esque) matrix and focus on the content as a specification. If there is no specification of view content then consistency will never be achieved.

Comments

Comment on this article

Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event?

Changes have been made to TRAK to support the description of risk and event sequences in the guise of the SVp-11 Solution Event Causes and SVp-13 Solution Risk Viewpoints. This has been a piece of work underway for at least 3 years but it seemed necessary to publish it so that the viewpoints and tuples can be exposed to wider testing i.e. used in anger.

As with most of this sort of work there is a limit to the amount of theorising that is possible and it’s necessary to test the pragmatism and utility. It’s likely therefore to undergo some tweaking. If any relationship or metamodel entity is not needed then it should be removed since the overall aim is to work with the minimum metamodel needed to just be adequate. A larger metamodel is not only harder to maintain and keep consistent but because it is only there to support the concerns in the set of TRAK viewpoints (specifications for views cf ISO/IEC/IEEE 42010:2011) it follows that a larger metamodel makes definition of a consistent set of viewpoints harder. With more entities and relationships it is also likely that an architecture description can become more complex and require more effort to present it clearly to get the meaning across (at least to a Mk 1 Human Being since being based on triples a TRAK architecture description is machine-readable and analysable). Every tuple in the TRAK metamodel has therefore to earn its keep / justify not being removed.

Solution Risk

In a previous posting I identified why we think, in TRAK at least, that a risk is a type of event and why many of the current definitions of risk do not actually define what a risk is (only how you might calculate a number or metric i.e. probability of occurrence x impact severity).

We’ve tied risk to the solution because we think that this is where it most often manifests itself in terms of design features or changes to the design of the system of interest to mitigate it. In engineering terms it is really the cumulative risk exposure to people that drives design change hence it makes sense to be able to relate risk, vulnerability, threats and mitigation to a solution design whether the causing agent or the impacted one.

TRAK therefore supports the following triples / tuples for describing risk:-

https://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons” href=“https://commons.wikimedia.org/wiki/File%3ATRAK_metamodel_part_2_safety_security.jpg”>

• Resource (System, Software, Physical, Role, Job or Organisation) has Vulnerability
• Function has Vulnerability - what the Resource does
• Resource Interaction has Vulnerability - the exchange between Resources
• Interaction Element has Vulnerability - what is exchanged between Resources
• Resource poses Threat (synonym Hazard)
• Threat exploits Vulnerability
• Threat to Resource
• Threat to Function
• Threat to Resource Interaction
• Threat to Interaction Element
• Threat poses Risk
• Resource exposed to Risk
• Risk is managed by Mitigation
• Mitigation uses Function
• Mitigation uses Resource

By way of a small example using a small subset of the above we have a nuclear reactor.

It is possible to identify an external actor as the origin of the threat (hazard) - ‘Resource 1 poses Threat to Resource 2’. Similarly mitigation might be a result of a part of the same resource or it might require a different one (‘Resource 1 is exposed to Risk is managed by Mitigation uses Resource 2’).

In all of this the description of Risk, Vulnerability, Threat (Hazard) and Mitigation can be linked to the description of the solution or part of the solution. This therefore enables the solution design to be modified in response or the mitigation to be altered in response to a design change so the cause and effect is always visible in the architecture description.

So far all of this is pretty straightforwards. The “toughie” is:-

• Risk is a Event

This is tricky not because there is any doubt that a Risk is a type of Event. A risk typically is associated with a probability of occurrence and an impact severity. If we are thinking about an event in the way it would be used in, say, Fault Tree Analysis (FTA) then it also has a probability of occurrence. It too can have an impact severity. So are there differentiating attributes of a risk (event)? We couldn’t think of any - suggestions welcome. The rationale for having a separate Risk metamodel element was simply that people might expect to see elements labelled as ‘Risk’ because they might not equate ‘Event’ with the description of a risk (affordance and visibility).

Note. Although there isn’t a difference in the attributes there is a distinction in the possible values A Risk and an Event can take. A Risk, by definition is always uncertain but possible therefore 0 < probability of occurrence_Risk < 100% whereas a ‘straight‘ Event may be impossible or certain and therefore 0 ≤ probability of occurrence_Event ≤ 100%. Risk therefore seems to occupy a subset of the range of values for Event.

Is this worth having 2 distinct elements, particularly since the inheritance (‘is a’) means that we also have:-

• Risk caused by Risk
• Risk impacts on Resource
• Risk caused by Resource
• Risk AND / OR / etc. Risk

and this is less clear when Risk and Event are separate entities on the metamodel diagram.

If there was the one element, Event, then it would still allow risks (Events) to be clustered or grouped which would allow the SVp-11 to be used to describe and identify common causal risk (events) and therefore suggest ways in which risks might be managed. The only penalty seems therefore to be 1) visibility - can risks be identified as such when typed as Event? 2) affordance - is it obvious that an Event element can be used to describe a risk?

Can anyone justify why Risk and Event should be distinct or why they should be subsumed into Event? Clearly from a TRAK-management point of view it would be better to apply the Highlander Principle (“there shall only be one”) but this might overridden by the UI / HCI aspects.

Thoughts?

Comments

Comment on this article

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

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.

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.name = row.name,
  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.

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.

Comments

Comment on this article

Page 1 of 16 pages  1 2 3 >  Last ›