trak Project

TRAK SourceForge Projects

Definition

Implementation

TRAK Information

 

 

 

 

 

 

 

 

 

TRAK

TRAK is a general purpose and pragmatic enterprise architecture framework which has its roots in the UK MoD's MODAF 1.2.

TRAK allows you to describe an enterprise, a concept, a solution (and its procurement) and an architecture task. In ISO/IEC/IEEE 42010 terms each is a ‘system of interest’ and has stakeholders who have concerns that need to be addressed through the resulting architecture description.

TRAK provides a way of describing systems and their place in the world through architectural descriptions. The elements used to make the TRAK views is defined by the TRAK Metamodel. The TRAK views that contain these elements are each defined by a TRAK Viewpoint.

TRAK adopts the ISO/IEC/IEEE 42010 approach where

Governance of TRAK

Release of the TRAK Viewpoints are under the control of the TRAK Steering Group,

ISO/IEC/IEEE 42010

The international standard for architecture description for systems and software engineering is ISO/IEC/IEEE 42010. The latest release was in 2011 (i.e. ISO/IEC/IEEE 42010:2011).

TRAK was designed from the outset to be compliant with the standard. The basis of the claim of conformance together with the supporting arguments and evidence is described using TRAK MV-04 Assurance Views (based on Claims, Arguments and Evidence (CAE) metamodel elements) and presented as an architecture description (too good an opportunity to miss!) exported as a separate set of linked web pages. This contains the output provided for formal assessment of the claims.

The claims fall into 2 main areas:-

The outputs are:-

Graphs & Graph Notation

TRAK itself isn't a notation. TRAK Viewpoints in accordance with ISO/IEC/IEEE 42010 are specifications for TRAK Architecture Views. A TRAK Architecture View is therefore not an 'instance' of a TRAK Viewpoint but an architecture description that meets the requirements of its viewpoint in terms of required / allowed / minimum content, presentation, consistency rules and interpretation.

TRAK Viewpoints are defined using only tuples (triples). e.g.

In a TRAK Architecture Description what is shown are Architecture Description Elements - both nodes and relationships. The minimum allowed unit of Architecture Description is the Architecture Description Tuple, In mathematical terms this is a graph and therefore TRAK Viewpoints and TRAK Views can be described using graphs. By way of an experiment/ example the architecture description created using Sparx Systems Enterprise Architect describing the claims of conformance of TRAK against ISO/IEC/IEEE 42010 have been exported and placed into a graph database. The graph database used is the Community Edition of Neo4J which provides a browser visualisation and command line for issuing queries. The result is a directed property graph since all relationships in TRAK have a type and a direction and relationships and nodes have properties. Neo4J provides a very suitable platform.

The advantages of graph notation are:-

An example of a view using graph notation of the requirement structure of ISO/IEC/IEEE 42010:2011 is shown below. In TRAK this is a MV-03 Requirements & Standards Architecture View.

Partial extract of MV-03 Describing requirements in ISO/IEC/IEEE 42010:2011

This is a small part of the overall MV-03 architecture view. To view the whole thing as a PDF click on this link.

 

The view above was produced using a simple query:-

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

The query contains an instruction to follow a named path in the specified direction starting at the named element representing the standard, looking for every 'has part' relationship and recursing through the hierarchy returning the nodes and relationships found. If you tried to do the same in a SQL database where the objects were held in one table and the relationships in another you'd need a JOIN for every level and without any proprietary SQL commands you'd need to know how deep the structure was beforehand. The graph approach is much simpler and more intuitive because the instruction to follow a path describes what you see in the result and is much more akin to natural language.

For many reasons therefore graph notation and graph databases are a natural fit if you use TRAK.

TRAK Enterprise Architecture Framework Document

The TRAK Enterprise Architecture Framework document is a specification.

It contains:

Where Does this Fit In?

The TRAK Enterprise Architecture Framework document is part of the logical definition of TRAK.

The TRAK Enterprise Architecture Framework document invokes the other parts of the definition:

Implementations of TRAK

TRAK can be implemented in a wide range of modelling tools and architecture description languages (a term taken from ISO 42010) such as UML, BPMN etc can be used to represent parts of the TRAK metamodel and therefore can be used in creating TRAK architecture views.

The known implementations of TRAK are listed separately.

Where Do I Get It?

The TRAK document is available here ...

Modification Date: January 24, 2022