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. . TRAK was a finalist for the 2011 IET Innovation Awards.

Terminology

;Architecture Description Tuple
;Master Architecture View
;Perspective
;View
;Viewpoint

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. Each viewpoint specifies what sets of types of architectural description element and relationships 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, 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.

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.

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 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.

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
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.

Presentation of TRAK Views

TRAK does not specify a notation or presentation language 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.
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.
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. TRAK also requires every block to have a name. 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 .
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 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 is acceptable as is a set of plain text statements or a diagram using the UML.

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:-
  1. TRAK as an architecture framework against the requirements of section 6.1 of ISO/IEC/IEEE 42010:2011 and;
  2. a TRAK-conforming architecture description against section 5 of ISO/IEC/IEEE 42010:2011.

    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:
TRAK is released under 2 forms of open source license:
TRAK supports modelling tools through the following mechanisms:
A comparison of the stereotype 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 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 used and tool-specific capabilities.

Examples of Architecture Description Using TRAK