TRAK

TRAK is a general enterprise architecture framework aimed at systems engineers based on MODAF 1.2.
History.
TRAK was originally commissioned by London Underground Limited. Development started in 2009 and was based on the then current views of architectural description within London Underground which were based on ISO/IEC 42010 and tied to the systems engineering lifecyle defined in ISO/IEC 15288 .
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 and the result was a domain-free metamodel and viewpoints that were only based on representing complex systems.
TRAK was released under open source licenses in February 2010.
It has been formally adopted by the UK Department for Transport who chair the TRAK Steering Group that manages the overall direction, strategy and formal releases of TRAK.
The TRAK development team received a Working Group award. (photo on the INCOSE Transportation Working Group page ). TRAK was a finalist for the 2011 IET Innovation Awards.
TRAK Structure.
TRAK is defined in a logical way - that is to say free of any notion of how TRAK is implemented in any tool or any architecture description language.
TRAK has 24 architecture viewpoints which are grouped into 5 perspectives. Each viewpoint belongs to a single perspective and specifies a single view (type). 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 Architecture Perspectives.
TRAK has 5 architecture perspectives, each of which groups together architecture viewpoints and views of an overlapping subject area:
Enterprise Perspective.
This perspective covers the enduring capabilities that are needed as part of the bigger enterprise.These are high level needs that everything else contributes to and form part of the long term strategic objectives that need to be managed.
Concept Perspective.
The concept perspective covers the logical view of what is needed in response to the capabilities required by the enterprise in the enterprise perspective. It covers the logical connection of nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It also implies no particular part of a life cycle – it covers everything from concept to disposal ("lust to dust"!).
Procurement Perspective.
The procurement perspective provides a top level view of the solution to the enterprise capability needs outlined in the enterprise perspective and developed in the concept perspective. It provides a way of showing how projects deliver the solutions described in the solution perspective to provide capability. It provides a way of showing time dependency between projects and is an essential for investigating capability gaps.
Solution Perspective.
The solution perspective provides views about the solution – whether proposed or realised. It covers the parts of ‘systems’ whether human or machine, their exchanges and protocols. The solution perspective describes how organisations and equipment are organised and governed. The solution perspective describes how the logical requirements outlined in the concept perspective are realised and shows how the solution(s) realise the capability needed by the enterprise and described in the enterprise perspective.
Management Perspective.
The management perspective provides views that describe the architectural task and those relationships that are common across other perspectives. It provides ways of defining the scope and findings of the architectural task - structuring the approach and modelling.
The management perspective provides ways of describing the normative standards that apply. It contains views that provide supporting information to aid the portability and understanding of the model(s).
TRAK Architecture Viewpoints & Views.
Each architecture view in TRAK is specified by a corresponding architecture viewpoint. The viewpoint is designated using a 'p' in the numbering e.g. a CVp-01 is the architecture viewpoint that specifies a CV-01 architecture view.
In general use if there is a risk of confusion with a similarly-numbered view in another framework such as DODAF or MODAF then a namespace prefix is used e.g. TRAK::SV-01
TRAK defines 24 architecture viewpoints (by comparison DODAF 2.0 has 52 views/models, MODAF 1.2.004 has 47 views and NAF 3.1 has 49 subviews )
These defined in the TRAK Viewpoints specification. Additional information is provided in a community wiki.
TRAK Metamodel.
The TRAK Metamodel both simplifies and extends the basic concepts within the MODAF 1.2 metamodel. It has removed and redefined stereotypes and any defence-specific constructs have been removed. The TRAK Metamodel specification contains a comparison of the TRAK metamodel at initial release against MODAF 1.2.003. This is also outlined separately.
The TRAK metamodel is shown below. "Note that this is not a controlled copy".
Significant changes vs MODAF include:
Structurally there are other changes:
The way in which TRAK is managed and released via a set of open source projects is also quite different from other enterprise architecture frameworks. All change requests and feature requests and the sentencing of them are fully visible to anyone, not restricted to those who specify or develop the framework. Releases are under change control and all history is maintained by versioning software (Subversion (SVN)).
Presentation of TRAK Views.
TRAK does not specify a notation or presentation language (architecture description language in ISO/IEC 42010 terminology) in which to present the architecture views. 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 requires the metamodel element name of every architecture description element in a TRAK architecture view to be explicitly shown so that each TRAK view can be read as a set of declarative statements e.g. 
Tuples can be presented using nodes and relationships with directions (a directed graph).
TRAK also allows a view to be constructed from textual statements. Since a TRAK view is a set of tuples / triples it is possible to use a graph or a set of RDF triples to present a TRAK view. A RDF ontology description of the TRAK metamodel elements is being developed. This takes the definitions of the elements from the TRAK Metamodel specification output from a graph model of TRAK within a Neo4J graph database. A TRAK architecture view consisting of RDF triples can be linked to the RDF TRAK metamodel ontology to form a knowledge graph. Each triple represents a fact or assertion.
TRAK also requires every block and every connector to have a name and for these to be visible (explicit). The intent of this is to ensure that a TRAK architecture view is read as the author of the view meant it and improve semantic consistency. Presentation rules that apply to all TRAK architecture views are specified in the overall TRAK specification (as 'Bye Laws').
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. It does not specify or mandate any particular notation or language. For example a simple block and connector diagram (as above) is acceptable as is a set of plain text statements, a diagram using the UML, a graph or a set of RDF triples. For the same reason TRAK View content is specified using an abstract and different notation from any notation that might be used to implement a TRAK architecture View to avoid a common fault arising from a fault in a single notation affecting both the TRAK viewpoint content definition and the 'design response' - the content of a particular TRAK view.
ISO 42010 Considerations.
TRAK applies ISO/IEC 42010 in the following ways:-
An overall comparison between TRAK and ISO/IEC 42010 is made in the TRAK Enterprise Architecture Framework document. A more detailed comparison against the 2011 version of the standard is made separately and is viewable as a set of web pages. These, together with a compliance matrix, compare:-
Creating an Architecture Description Using TRAK.
TRAK itself does not mandate process. There is an element of process introduced, however, because TRAK adheres to ISO/IEC 42010 which states that an architecture description is produced in response to a task and the task stakeholder concerns and also because TRAK has master architecture views which creates dependencies between views and results in minimum allowed architecture view sets.
This gives rise to a minimal process which is:
Licensing.
TRAK is released under 2 forms of open source license:
Tool Support.
TRAK supports modelling tools through the following mechanisms:
A comparison of the stereotype (concepts) in the UML against those in the TRAK Metamodel provides an analysis, for the UML Profile for TRAK, what TRAK Viewpoints and therefore TRAK Views UML is able to represent fully, partially and not at all. 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.
As tools represent an implementation of the logical definition of TRAK they may contain limitations or errors owing to the notation language (architecture description language) used and tool-specific capabilities.