TRAK Architecture FrameworkTRAK
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.TRAK00004. TRAK. Architecture Framework
TRAK provides a way of describing systems and their place in the world through architectural descriptions. The triples used to make the TRAK architecture views (the "language" of TRAK) is defined by the TRAK Metamodel. The TRAK architecture views are each defined by a TRAK architecture viewpoint where an architecture viewpoint is defined as work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns
ISO/IEC/IEEE 42010:2011
TRAK adopts the ISO/IEC/IEEE 42010 approach where
- the architecture description task sets out to answer concerns raised by the task stakeholder(s)
- a multiple view architecture description is the product of the task
- each viewpoint specifies
an individual TRAK architecture view in terms of:
- the questions or concerns it is designed to answer
- a description of the view
- what you must show
- what you can show if you want
- rules to help ensure that your model remains consistent
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:-
- claims of conformance of TRAK as an architecture framework against the requirements in section 6 of the standard
- claims of conformance of a TRAK-conforming architecture description against section 5 of the standard - so that users of TRAK can see how much conformance they get against the standard when conforming to the requirements of TRAK itself.
The outputs are:-
- the description itself (web pages) - TRAK00013. TRAK. Architecture Description. Conformance Assessment – ISO/IEC/IEEE 42010:2011
- the overall summary document - TRAK00015. TRAK. Architecture Description. Summary. Conformance Assessment – ISO/IEC/IEEE 42010:2011.
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.
System is configured with System - from the SV-01 Solution Structure architecture viewpointRole extends to System Claim about System - from the MVp-04 Assurance architecture viewpointArgument supports Evidence Evidence supports Argument Requirement derived from Requirement - from the MVp-03 Requirements & Standards architecture viewpoint
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:-
- no joins. A query is an instruction to traverse a path through the architecture description. This is very efficient in a graph database whereas successive table joins eventually suffers an exponential increase in time taken.
- relationships are first class citizens. Most of the tools used for enterprise architecture are really software development tools whose focus is on objects and the expression of objects. Relationships are present to help refine the definition of the objects but they don't appear in directories and exploitation / ad hoc queries is often difficult. This is important if you're working with an enduring and large repository and you want to make best use of the information captured.
- no unncecessary ornamentaion / visual artefacts - you just read what you see making it suitable for non-technical readership.
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.
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:
- important ideas for TRAK - general statements about TRAK - what it is, what it isn't and how it is organised
- standards affecting TRAK
- how TRAK relates to ISO/IEC/IEEE 42010:2011
- overall glossary for terms used
- advice on choosing an architecture description language e.g. UML, BPMN to represent TRAK architecture views
- conformance / non-conformance with TRAK - including how to incorporate non-conforming architecture views
- TRAK architecture perspectives
- a definition of the colours used in TRAK
- TRAK Bye Laws - overall rules
- minimal modelling process for TRAK
Where Does this Fit In?
The TRAK Architecture Framework document (TRAK00004. TRAK. Architecture Framework’, TRAK00004, https://sourceforge.net/projects/trak/files/latest) forms part of the logical definition of TRAK.
The TRAK 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 ...