TRAK

For Thyrotropin Receptor Antibodies, see Grave's disease.
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 based on MODAF 1.2.

History

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

Terminology

Architecture 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. <<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.
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'[6] 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.

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,[7] 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[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]

TRAK Metamodel

Metamodel for the TRAK enterprise architecture framework. Defines Allowed Object Types and 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[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)).

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 type 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. 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 [7][18] (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.

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 [19] and is viewable as a set of web pages.[20] These, together with a compliance matrix,[21] 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:

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 [26] 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

References

  1. ↑ IET Forums - TRAK - The Rail Architecture Framework
  2. 1 2 Rail Value for Money Study. Whole System Programme Management Report. 25 May 2011 http://www.rail-reg.gov.uk/upload/pdf/rvfm-atkins-programme-management-250511.pdf
  3. ↑ INCOSE 2010 Working Group Award http://www.incose.org/practice/techactivities/wg/transport/
  4. ↑ INCOSE Transportation Working Group http://www.incose.org/practice/techactivities/wg/transport/
  5. ↑ IET Innovation Awards 2001 - Finalists http://conferences.theiet.org/innovation/finalists/index.cfm
  6. ↑ ANSI/IEEE Std 1471 :: ISO/IEC 42010 Recommended Practice for Architectural Description of Software-Intensive Systems
  7. 1 2 3 TRAK Enterprise Architecture Framework
  8. 1 2 TRAK00001 TRAK. Enterprise Architecture Framework. Viewpoints
  9. 1 2 TRAK00002 TRAK. Enterprise Architecture Framework. Metamodel
  10. ↑ Trak-community.org::Wiki::Architecture Framework Comparison http://trak-community.org/index.php/wiki/Architecture_Framework_Comparison
  11. ↑ http://trak-community.org/index.php/wiki/TRAK:TRAK_Viewpoints
  12. ↑ http://trak-community.org/index.php/wiki/TRAK:Initial_TRAK_Baseline_vs_MODAF_-_Stereotypes
  13. ↑ MODAF Metamodel 1.2.004 MODAF version 1.2.004
  14. ↑ The MODAF System Viewpoint(SV) 26 April 2010
  15. ↑ Sourceforge. TRAK Project Bug/Change Trackers. http://sourceforge.net/tracker/?group_id=393432
  16. ↑ Sourceforge. TRAK Metamodel Project Bug/Change Trackers. http://sourceforge.net/tracker/?group_id=304403
  17. ↑ Sourceforge. TRAK Viewpoints Project Bug/Change Trackers. http://sourceforge.net/tracker/?group_id=304405
  18. ↑ TRAK Enterprise Architecture
  19. ↑ TRAK00015 TRAK. Architecture Description. Summary. Conformance Assessment – ISO/IEC/IEEE 42010:2011. http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00015_TRAK_AD_Summary_Conformance_with_42010_2011.pdf/download
  20. 1 2 TRAK00013 TRAK. Architecture Description. Conformance Assessment – ISO/IEC/IEEE 42010:2011 http://trak.sourceforge.net/TRAK%20vs%20ISO_42010_AD/index.htm
  21. 1 2 TRAK00014 TRAK. Compliance Matrix. Conformance Assessment – ISO/IEC/IEEE 42010:2011 http://sourceforge.net/projects/trak/files/ISO%2042010/TRAK00014_TRAK_vs_ISO42010_compliance.ods/download
  22. ↑ MDG Technology for TRAK
  23. ↑ trakmoodtemp Project on Sourceforge
  24. ↑ trakomnigraffle Project on Sourceforge
  25. ↑ trakforvisio Project on Sourceforge
  26. ↑ trak project on Sourceforge
  27. ↑ Technical Strategy Leadership Group (TSLG). Railway Functional Architecture. http://www.futurerailway.org/Research/Pages/Railway-Function-Architecture.aspx
  28. ↑ RSSB Research & Development E-newsletter. Issue 66. Oct. 2010. Topic T912 The Railway Functional Architecture http://www.rssb.co.uk/SiteCollectionDocuments/research/enews/rd_enewsletter66.htm
  29. ↑ The Railway Functional Architecture Summary Report http://www.rssb.co.uk/sitecollectiondocuments/pdf/reports/research/T912_rpt_final.pdf
  30. ↑ RSSB. Project T912 The Railway Functional Architecture. http://www.rssb.co.uk/RESEARCH/Lists/DispForm_Custom.aspx?ID=955
  31. ↑ The Railway Functional Architecture (HTML) http://www.futurerailway.org/research/Pages/EA%20HTML/index.htm
  32. ↑ InfraGuidER Deliverables http://www.infraguider.eu/prodotti_7.html
  33. ↑ Minutes: D22: 2nd Workshop for EURNEX poles of excellences http://infraguider.eu/doc/INFRAG_WP5_NIT_DV_022_B.pdf
  34. ↑ Integrated EA 2011: Managing Risk and Cost with an EA Approach http://www.integrated-ea.com/file_download/101/
Wikimedia Commons has media related to TRAK.
This article is issued from Wikipedia - version of the 8/5/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.