TRAK is a general enterprise architecture framework aimed at systems engineers based on MODAF 1.2.
TRAK was originally commissioned by London Underground Limited.[1][2] 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.[3] (photo on the INCOSE Transportation Working Group page [4]). TRAK is a finalist for the 2011 IET Innovation Awards.[5]
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 22 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 has 5 architecture perspectives,[7] 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.These are high level needs that everything else contributes to and form part of the long term strategic objectives that need to be managed.
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”!).
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.
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 equipments 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.
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).
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 22 architecture viewpoints[8] (by comparison DODAF 2.0 has 52 views/models, MODAF 1.2.004 has 47 views and NAF 3.1 has 49 subviews [10])
These defined in the TRAK Viewpoints specification. Additional information is provided in a community wiki.[11]
The TRAK Metamodel[9] 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.[12]
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.[15][16][17] Releases are under change control and all history is maintained by versioning software (Subversion (SVN)).
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 is a logical definition - it specifies what needs to be shown and minimum acceptable content but does not mandate how you achieve it.
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 emerging version of the standard (as represented by the Final Committee Draft version dated 8 June 2010[18]) is made separately.[19]
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:
TRAK is released under 2 forms of open source license:
TRAK supports modelling tools through the following mechanisms:
A comparison of the stereotype (concepts) in the UML against those in the TRAK Metamodel [24] 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.