TRAK
Encyclopedia
TRAK is a general enterprise architecture framework aimed at systems engineers based on MODAF
MODAF
The British Ministry of Defence Architecture Framework is an Architecture Framework which defines a standardised way of conducting Enterprise Architecture, originally developed by the UK Ministry of Defence....

 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
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...

 lifecyle defined in ISO/IEC 15288
ISO 15288
The ISO/IEC 15288 is a Systems Engineering standard covering processes and life cycle stages. Initial planning for the ISO/IEC 15288:2002 standard started in 1994 when the need for a common Systems Engineering process framework was recognised. The first edition was issued on the 1st of November...

 .

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
Complex systems
Complex systems present problems in mathematical modelling.The equations from which complex system models are developed generally derive from statistical physics, information theory and non-linear dynamics, and represent organized but unpredictable behaviors of systems of nature that are considered...

.

TRAK was released under open source licenses in February 2010.

It has been formally adopted by the UK Department for Transport
Department for Transport
In the United Kingdom, the Department for Transport is the government department responsible for the English transport network and a limited number of transport matters in Scotland, Wales and Northern Ireland which are not devolved...

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

Terminology

Architecture Tuple
An architectural element with a named stereotype which has a named relationship to either the same or another element e.g. <> A 'has part' <> B. It follows the natural language construct of Subject - Predicate - Object - also used in RDF
Resource Description Framework
The Resource Description Framework is a family of World Wide Web Consortium specifications originally designed as a metadata data model...



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
ISO/IEC 42010
ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.-Overview:...

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


Viewpoint
ISO/IEC 42010
ISO/IEC 42010
ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.-Overview:...

:2007 - A viewpoint defines a set of conventions (notations, languages and model types) for constructing a certain kind of 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 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
SourceForge
SourceForge Enterprise Edition is a collaborative revision control and software development management system. It provides a front-end to a range of software development lifecycle services and integrates with a number of free software / open source software applications .While originally itself...

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

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
MODAF
The British Ministry of Defence Architecture Framework is an Architecture Framework which defines a standardised way of conducting Enterprise Architecture, originally developed by the UK Ministry of Defence....

 then a namespace prefix is used e.g. TRAK::SV-01

TRAK defines 22 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-02 Concept
    • 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

  • Management Perspective
    • MVp-01 Architecture Description Dictionary
    • MVp-02 Architecture Description Design Record
    • MVp-03 Requirements & Standards


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:
  • 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
    Hard systems
    In systems science Hard systems is a title sometimes used to differentiate between different types of systems problems. It is opposing soft systems.- Overview :...

     and soft systems
    Soft systems
    Soft systems methodology is a systemic approach for tackling real-world problematic situations. Soft Systems Methodology is the result of the continuing action research that Peter Checkland, Brian Wilson, and many others have conducted over 30 years, to provide a framework for users to deal with...

     (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) stereotypes 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
  • 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 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 22 viewpoints (vs c 47 views in MODAF)
  • the each viewpoint content is defined in terms of tuples (a stereotype - relationship - stereotype construct) and has mandatory, optional and minimum acceptable content and correspondence rules with respect to other views within the architecture description


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
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

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

ISO 42010 Considerations

TRAK applies ISO/IEC 42010
ISO/IEC 42010
ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.-Overview:...

 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)
  • each TRAK architecture view is specified by a viewpoint within the TRAK architecture framework
  • 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
  • correspondence rules are defined by viewpoints and for an architecture description using 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 emerging version of the standard (as represented by the Final Committee Draft version dated 8 June 2010) is made separately.

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
    Profile (UML)
    A profile in the Unified Modeling Language provides a generic extension mechanism for customizing UML models for particular domains and platforms...

     for TRAK - for use with any UML modelling tool
    UML tool
    A UML tool or UML modeling tool is a software application that supports some or all of the notation and semantics associated with the Unified Modeling Language , which is the industry standard general purpose modeling language for software engineering.UML tool is used broadly here to include...

     that can import a UML profile
  • a plugin for Sparx Systems Enterprise Architect
    Enterprise Architect (Visual Modeling Platform)
    Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. The platform supports: the design and construction of software systems; modeling business processes; and modeling industry based domains...

     based on the UML profile for TRAK. Released as open source on Sourceforge
  • a template for Salamander MooD 2010 (developed by Vega Consulting Services Ltd - part of the Finmeccanica group
    Finmeccanica
    Finmeccanica S.p.A. is an Italian conglomerate. Finmeccanica is the second largest industrial group and the largest of the hi-tech industrial groups based in Italy. It works in the fields of defence, aerospace, security, automation, transport and energy...

     ). Released as open source on Sourceforge.
  • a stencil for OmniGraffle
    OmniGraffle
    OmniGraffle is a diagramming application made by The Omni Group. OmniGraffle is built only for Mac OS X and the iPad. It may be used to create diagrams, flow charts, org charts, and illustrations. It features a drag-and-drop WYSIWYG interface...

     (Mac OS X
    Mac OS X
    Mac OS X is a series of Unix-based operating systems and graphical user interfaces developed, marketed, and sold by Apple Inc. Since 2002, has been included with all new Macintosh computer systems...

    , iPad
    IPad
    The iPad is a line of tablet computers designed, developed and marketed by Apple Inc., primarily as a platform for audio-visual media including books, periodicals, movies, music, games, and web content. The iPad was introduced on January 27, 2010 by Apple's then-CEO Steve Jobs. Its size and...

    ). Released as open source on Sourceforge.
  • a template for Microsoft Visio
    Microsoft Visio
    Microsoft Visio , formerly known as Microsoft Office Visio, is a commercial diagramming program for Microsoft Windows that uses vector graphics to create diagrams.- Features :...

    . 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 (ADL
ADL
Adl is an Arabic word meaning justice.The abbreviation ADL may refer to:*Activities of daily living, a term used in medicine and nursing, especially in the care of the elderly...

s) 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.
  • 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.
  • 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

External links

The source of this article is wikipedia, the free encyclopedia.  The text of this article is licensed under the GFDL.
 
x
OK