TRAK

TRAK is a general enterprise architecture framework aimed at systems engineers.

Although the original intent was to develop a rail-specific architecture framework, in adapting MODAF to suit local needs any defence or domain-specific content was removed.

Each viewpoint specifies what sets of types of architectural description element and relationships (tuples) can appear.

The architectural description element types and relationships are specified by the TRAK metamodel.

The logical definition of TRAK consists of 3 documents, each of which is an open source project on SourceForge: TRAK has 5 architecture perspectives,[9] each of which groups together architecture viewpoints and views of an overlapping subject area: This perspective covers the enduring capabilities that are needed as part of the bigger enterprise.

It also implies no particular part of a life cycle – it covers everything from concept to disposal ("lust to dust"!).

It provides a way of showing time dependency between projects and is an essential for investigating capability gaps.

It provides ways of defining the scope and findings of the architectural task - structuring the approach and modelling.

[18][19][20] Releases are under change control and all history is maintained by versioning software (Subversion (SVN)).

TRAK architecture descriptions are not therefore UML, SysML or BPMN models although any of these notations can be used to prepare at least some of the views (an ADL might not contain the necessary concepts/stereotypes or might not allow them to be connected in the way needed to represent a TRAK architecture view).

TRAK is a logical definition - it specifies what needs to be shown and minimum acceptable content but does not mandate how you achieve it.

TRAK simply defines the node and connector elements and the allowed combinations (triples) that must / may appear in each view.

A more detailed comparison against the 2011 version of the standard is made separately [23] and is viewable as a set of web pages.

This is a consequence of the constructs available in UML and the particular implementation in the UML Profile for TRAK and arises because different architecture description languages (ADLs) are often design for different purposes and sometimes different domains i.e. in ISO/IEC 42010 the concerns they address are different from those that the architecture framework, in this case TRAK, does.

Structure of TRAK - formed from 1 metamodel, 5 architecture perspectives and 24 architecture viewpoints
Metamodel for the TRAK architecture framework. Shows general elements for use in TRAK architecture views.
Metamodel for the TRAK architecture framework. Shows elements for use in TRAK architecture views describing safety and security.
Metamodel for the TRAK architecture framework. Shows elements that define the structure of TRAK itself.
Metamodel for the TRAK architecture framework. Shows elements used to define TRAK architecture viewpoints and the allowed content of TRAK architecture views.
Example TRAK SV-13 Solution Risk View Presented as a Graph Showing Tuples from the TRAK Metamodel