TRAK

Structure of TRAK - formed from 1 metamodel, 5 architecture perspectives and 24 architecture viewpoints

TRAK is a general enterprise architecture framework aimed at systems engineers. It is 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 life cyle 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. The result was a domain-free metamodel with 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.

Terminology

Architecture Description Element

An individual architecture description object that is used to describe or represent an item of real-world architecture. An architecture description element can appear in an architecture description. Only Architecture Description Elements are used to form TRAK Architecture Views. An Architecture Description Element may be a node element or a connector element. A connector element and either two node elements are used to form an Architecture Description Tuple.

Architecture Description Tuple

A named architecture description element connected by a named relationship to a named architecture description element. i.e. subject - predicate object - the basis of a sentence. e.g. Organisation A 'has part' Job B. It follows the natural language construct of Subject - Predicate - Object - also used in RDF. See Tuple. TRAK requires each tuple to be explicit. The Architecture Description Tuples are defined by the TRAK Metamodel. There are at least 750 Architecture Description Triples or assertions provided by the TRAK metamodel.

Master Architecture View

Each TRAK metamodel node has a master architecture view. Within an architecture description or model each element (individual) has to be declared or shown on its master architecture view before it can be used on any other architecture view. For example, before describing functions using, say, 'System performs Function' on a SV-04 Solution Function View the System element would be first created and presented on a TRAK SV-01 Solution Structure View.

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.

(Architecture) 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.

(Architecture) 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. Each TRAK Viewpoint defines both the allowed content and the minimum acceptable view content as sets of Architecture Description Tuples.

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, by-laws (rules affecting the design of TRAK), architecture views and architecture descriptions, minimal modelling process.
• TRAK Enterprise Architecture Framework Viewpoints document. This defines the TRAK architecture viewpoints.
• TRAK Enterprise Architecture Framework Metamodel document. This defines the architecture description elements that can appear in a viewpoint definition.

TRAK architecture perspectives

TRAK has 5 architecture perspectives, each of which groups together architecture viewpoints and views of an overlapping subject area:

• Enterprise Perspective
• Concept Perspective
• Procurement Perspective
• Solution Perspective
• Management Perspective

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 and 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 )

• Enterprise Perspective
  • EVp-01 Enterprise Goals
  • EVp-02 Capability Hierarchy
  • EVp-03 Capability Phasing
• Concept Perspective
  • CVp-01 Concept Need
  • CVp-03 Concept Item Exchange
  • CVp-04 Concept Activity to Capability Mapping
  • CVp-05 Concept Activity
  • CVp-06 Concept Sequence
• Procurement Perspective
  • PrVp-01 Procurement Structure
  • PrVp-02 Procurement Timeline
  • PrVp-03 Procurement Responsibility
• Solution Perspective
  • SVp-01 Solution Structure
  • SVp-02 Solution Resource Interaction
  • SVp-03 Solution Resource Interaction to Function Mapping
  • SVp-04 Solution Function
  • SVp-05 Solution Function to Concept Activity Mapping
  • SVp-06 Solution Competence
  • SVp-07 Solution Sequence
  • SVp-11 Solution Event Causes
  • SVp-13 Solution Risk
• Management Perspective
  • MVp-01 Architecture Description Dictionary
  • MVp-02 Architecture Description Design Record
  • MVp-03 Requirements & Standards
  • MVp-04 Assurance

These defined in the TRAK Viewpoints specification. Additional information is provided in a community wiki.

TRAK metamodel

Metamodel for the TRAK enterprise architecture framework. Defines Allowed Metamodel Elements including Relationships for Use in TRAK Architecture Descriptions.

Defines the Architecture Description Elements (the triples / tuples that may appear in TRAK architecture views) that describe safety, security and risk.

Part of the TRAK metamodel (used in the TRAK enterprise architecture framework). Describes the management perspective elements and their relationships (tuples).

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.

There is an ontological description of the TRAK metamodel elements using RDF at. This is also presented as HTML.

Significant changes vs MODAF include:

• 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.
• 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 can represent any type of interface exchange / flow - information, energy or resource
• TRAK can represent exchange characteristics associated with human resources - Organisations, Jobs and Roles
• TRAK includes means to represent requirements through the Standard (document/collection) and Requirement (atomic) metamodel elements and enforced by Contract
• 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
• TRAK includes the means to describe assurance cases (including design verification) using the Claim - Argument - Evidence construct
• TRAK includes the means to describe safety / security - threats/hazards, vulnerabilities, mitigations and risk and causes / impacts
• 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
• addition of consistency rules for content that apply to the entire collection of views and context to improve navigation and visibility of content
• 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

Structurally there are other changes:

• TRAK has 24 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 allowed 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).
• Since ISO/IEC/IEEE 42010:2011 defines architecture in terms of the relationship of a system to its environment the smallest unit of architecture description that may appear in a TRAK architecture view is therefore the Architecture Description Tuple i.e. node - relationship - node.

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.

• 'System. A -is configured with-> Software. B'
• 'Claim. System A meets the requirement to ... -about-> Standard. Climatic Environmental Specification.'
• 'Physical. Shield Building -has-> Vulnerability. Structural Weakness <-exploits- Threat. Deliberate Aircraft Impact'

Tuples can be presented using nodes and relationships with directions (a directed graph).

Example TRAK SV-13 Solution Risk View Presented as a Graph Showing Tuples from the TRAK Metamodel

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 architecture description is a response to a task which addresses a stakeholder's concerns (this is addressed using the TRAK::MVp-02 Architecture Description Design Record Viewpoint against which a view can be produced to define the task, concerns addressed and findings)
• each TRAK architecture view is specified by a viewpoint within the TRAK architecture framework. For example, the MVp-04 Assurance Viewpoint specifies the content of any MV-04 assurance view.
• each TRAK viewpoint identifies the stakeholders, concerns addressed, anti-concerns (things the viewpoint is not to be used for), the metamodel tuples needed, the metamodel tuples allowed, well-formedness (minimum acceptable content) and consistency rules with other views within the architecture description e.g. in a MV-04 Assurance View before 'Evidence proves Claim' can be asserted there has to exist 'Evidence supports Argument supports (same) Claim'
• correspondence rules are defined by viewpoints and for an architecture description using the TRAK metamodel. Rules are defined using triples from the TRAK metamodel.

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 (Architecture Frameworks) of ISO/IEC/IEEE 42010:2011 and;
2. a TRAK-conforming architecture description against section 5 (Architecture Descriptions) 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:

• identify the task stakeholder and their concerns
• using the TRAK Viewpoints select the Viewpoints needed to address the stakeholder concerns
• develop views that conform to these viewpoints that address these concerns
• these in turn may require additional views to be prepared to form a legitimate allowed view set
• document the purpose, concerns, findings and the architecture description using a MV-02 Architecture Design Record View supplemented by a MV-01 Architecture Dictionary View

Licensing

TRAK is released under 2 forms of open source license:

• GNU Free Documentation License (GFDL) for the logical definition - TRAK Overall, TRAK Metamodel and TRAK Viewpoints documents
• GNU Public License (GPL) for implementations of TRAK - UML profile for TRAK for general UML modelling tools and TRAK MDG Technology for Sparx Systems Enterprise Architect modelling tool.

Tool support

TRAK supports modelling tools through the following mechanisms:

• a UML profile and SysML profile for TRAK - for use with any UML modelling tool that can import a UML profile
• a plugin for Sparx Systems Enterprise Architect based on the UML and SysML profiles for TRAK. Released as open source on Sourceforge
• a template for MooD International's MooD 2010 software platform (developed by Vega Consulting Services Ltd - part of Leonardo). Released as open source on Sourceforge.
• a stencil for OmniGraffle (Mac OS X, iPad). Released as open source on Sourceforge.
• a template for Microsoft Visio. Released as open source on Sourceforge.

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.

Examples of architecture description using TRAK

• Sub Surface Upgrade Programme (SSUP). Upgrade of signalling and rolling stock for Circle, Hammersmith, Metropolitan and District lines on London Underground. Cited in Rail Value for Money Study. Whole System Programme Management Report. 25 May 2011.
• Technical Strategy Leadership Group (TSLG). Railway Functional Architecture
• Rail Safety & Standards Board (RSSB). UK Railway Functional Architecture. Ongoing research - RSSB Research & Development E-newsletter. Issue 66. Oct. 2010. Justification for the selection/use of TRAK is provided in the summary report for the task. The T912 railway functional architecture project is described separately. The Railway Functional Architecture is made available as a set of HTML pages.
• University of Birmingham. InfraGuidER (Infrastructure Guidelines for Environmental Railway Performance) deliverables 9 and 18., minutes: D22: 2nd Workshop for EURNEX (European Rail Research Network of Excellence) poles of excellences
• Integrated EA 2011. Managing Risk and Cost with an EA Approach. Mike Brownsword (Atego) & Joe Silmon (Centre for Railway Research and Education).,
• An architecture description describing the claims of compliance of TRAK as an architecture framework and a TRAK-conforming architecture description against the requirements of ISO/IEC/IEEE 42010:2011. Includes examples of the following views: MV-02 Architecture Description Design Record, MV-03 Requirements and Standards and MV-04 Assurance. The underlying model was then used to produce the compliance matrix as an example of Model-Based Systems Engineering.

External links

• TRAK Enterprise Architecture Framework project site
• TRAK Enterprise Architecture Framework. Metamodel project site
• TRAK Enterprise Architecture Framework. Viewpoints project site
• UML Profile for TRAK
• TRAK MDG for Sparx Systems' Enterprise Architect project site
• OmniGraffle Stencil for TRAK project site
• Visio Stencil for TRAK project site
• TRAK Community support site