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.
1. TerminologyArchitecture Description Tuple An architectural description element with a named type which has a named relationship to either the same or another architecture description element e.g. < > A has part < > B. It follows the natural language construct of Subject - Predicate - Object - also used in RDF. See Tuple. TRAK requires each tuple to be explicit. Master Architecture View Each TRAK metamodel stereotype has a master architecture view type. Within an architecture description or model each element has to be declared or shown on its master architecture view type before it can be used on any other view type. Perspective ISO/IEC 42010:2007 refers to an Architectural Perspective as Sharing of architectural models also facilitates an "aspect-oriented" style of architectural description A grouping of related and overlapping architectural views. View ISO/IEC 42010 refers to an architecture view as work product expressing the architecture of a system from the perspective of specific system concerns. A TRAK view is defined as an Architecture Product in the TRAK metamodel. A TRAK view presents a set of Architecture Description Tuples in accordance with its governing viewpoint. Viewpoint ISO/IEC 42010:2007 - A viewpoint defines a set of conventions notations, languages and model types for constructing a certain kind of view. In TRAK a viewpoint is a specification for a single TRAK view.
2. 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 Enterprise Architecture Framework document. This controls TRAK as a whole. It defines the TRAK Architecture Perspectives, colours, bye laws (rules affecting the design of TRAK, architecture views and architecture descriptions, minimal modelling process.
- TRAK Enterprise Architecture Framework Metamodel document. This defines the architecture description elements that can appear in a viewpoint definition.
- TRAK Enterprise Architecture Framework Viewpoints document. This defines the TRAK architecture viewpoints.
3. TRAK Architecture Perspectives
TRAK has 5 architecture perspectives, each of which groups together architecture viewpoints and views of an overlapping subject area:
- Management Perspective
- Enterprise Perspective
- Concept Perspective
- Solution Perspective
- Procurement Perspective
3.1. TRAK Architecture Perspectives 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.
3.2. TRAK Architecture Perspectives 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"!.
3.3. TRAK Architecture Perspectives 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.
3.4. TRAK Architecture Perspectives 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 solutions realise the capability needed by the enterprise and described in the enterprise perspective.
3.5. TRAK Architecture Perspectives 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 models.
4. 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
- EVp-02 Capability Hierarchy
- EVp-01 Enterprise Goals
- Enterprise Perspective
- EVp-03 Capability Phasing
- CVp-05 Concept Activity
- CVp-01 Concept Need
- CVp-04 Concept Activity to Capability Mapping
- Concept Perspective
- CVp-06 Concept Sequence
- CVp-03 Concept Item Exchange
- PrVp-01 Procurement Structure
- PrVp-03 Procurement Responsibility
- PrVp-02 Procurement Timeline
- Procurement Perspective
- SVp-06 Solution Competence
- SVp-05 Solution Function to Concept Activity Mapping
- SVp-01 Solution Structure
- Solution Perspective
- SVp-02 Solution Resource Interaction
- SVp-07 Solution Sequence
- SVp-03 Solution Resource Interaction to Function Mapping
- SVp-04 Solution Function
- SVp-13 Solution Risk
- SVp-11 Solution Event Causes
- MVp-01 Architecture Description Dictionary
- MVp-03 Requirements & Standards
- MVp-02 Architecture Description Design Record
- MVp-04 Assurance
- Management Perspective
These defined in the TRAK Viewpoints specification. Additional information is provided in a community wiki.
5. 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:
- rules that constrain how and in what order relationships can be made to improve the consistency of the set of views that forms the architecture description
- TRAK can represent exchange characteristics associated with human resources - Organisations, Jobs and Roles
- System is central to TRAK and can represent hard systems and soft systems in MODAF 1.2.003 System is an artefact and part of the Physical Architecture and cannot include non physical parts
- TRAK includes the means to plan and describe the architecture task and architecture description and its organisation as a view MV-02 Architecture Description Design Record
- other types of dependency and associations can be represented - physical, membership, responsibility extent
- the TRAK metamodel is aimed at users the MODAF M3 is an abstract UML profile intended as a specification for tool vendors to implement MODAF - there is no metamodel for users only fragments of simplified metamodel which aim to represent the more complicated M3. In TRAK the metamodel shown is the master one.
- TRAK includes means to represent requirements through the Standard document/collection and Requirement atomic metamodel elements and enforced by Contract
- addition of consistency rules for content that apply to the entire collection of views and context to improve navigation and visibility of content
- addition of ISO/IEC 42010 concepts to represent the architectural task, architecture description and architecture views - to allow a description of the task scope, purpose, findings
- TRAK can represent any type of interface exchange / flow - information, energy or resource
Structurally there are other changes:
- TRAK has 22 viewpoints vs c 47 views in MODAF
- the each viewpoint content is defined in terms of tuples a node - relationship - node element construct i.e. a triple or 1,tuple and has mandatory, optional and minimum acceptable content and correspondence rules with respect to other views within the architecture description because this is needed to specify a uniquely addressable path in a metamodel specifying a block metamodel element is not sufficient on its own where there are several relationships involving the element. The smallest unit of architecture description that may appear in a TRAK architecture view is therefore the Architecture Description Tuple.
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).
6. 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.
- Physical. Shield Building -has-> Vulnerability. Structural Weakness
- Claim. System A meets the requirement to. -about-> Standard. Climatic Environmental Specification.
- System. A -is configured with-> Software. B