Birth of an Enterprise Architecture Framework - TRAK - The Rail Architecture Framework

TRAK is an architecture framework that was created and developed by Eclectica Systems Ltd. for London Underground Limited (LUL).

Background

On the SSR Upgrade Programme (SUP) LUL were creating architectural models and had 5 collections of views - Operational, Function, Physical, Geographic and an undesignated Management one. Each view was constructed in accordance with a specification - a viewpoint in accordance with IEEE 1471 / ISO 42010. Architectural views were produced using Visio which LUL recognised was only a short term solution as it was already then proving difficult to maintain consistency between each visio drawing. The types of object most commonly used - Physical, Human and Composite together with Function were controlled in use through the viewpoints but there was nothing that defined the set of object types nor the relationships allowed between them.

It was in this context that Eclectica Systems was asked to add some ‘intellectual rigour’.

Solution

A metamodel was needed to define and limit the types of object used in architectural modelling and the allowed relationships between the object types. In the true spirit of re-use it was decided that the MoD Architectural Framework (MODAF), something which Eclectica Systems had been involved with both at Abbey Wood and at Malvern, provided the best starting point. It also provided benefits in terms of familiarity to others and good tool support which could be leveraged. Defence-specific concepts were removed and then the MODAF metamodel (M3) was simplified where possible.

One of the choices was how to present / describe the TRAK metamodel. In the end a simple ‘block and line’ approach seemed the best because:-

  1. no technical knowledge is needed - you simply read what you see i.e. a good user interface
  2. it is part of the ‘user requirement’ in systems engineering terms and should be free of any implementation or solution
  3. the notation for the requirement needs to be different from that in its implementation to avoid introducing common cause faults which affect the requirement and the solution

Reasons 2) and 3) mean that a notation used to implement TRAK, such as the UML or SysML, cannot be used in its metamodel.

The ‘block and line’ was also fundamental because:-

  • each block - line block is a tuple and forms a statement or assertion
  • each tuple forms a simple english-like sentence which can be read e.g. System. Radar performs Function. Detect Target
  • the assertions can be tested, verified and others derived from them
  • relationships therefore have to be visible and explicit - otherwise meaning is hidden, lost or inconsistent - which can lead to technical debt
  • a tuple can be represented by a graph and therefore queried - making use of the model / repository
  • a tuple is the smallest permissible unit of architecture description i.e. an isolated block or node tells us nothing about architecture because it has no relationship with anything else

Extract of TRAK Metamodel - Assurance Elements - Claim, Argument and Evidence

Extract of TRAK Metamodel - Assurance Elements - Claim, Argument and Evidence


The emphasis of the TRAK metamodel is on the ‘system’ and also allows for dependencies, for example physical ones such as proximity or alignment to be represented as well as exchanges of information, energy or materiel.

Extract of TRAK Metamodel - Centered on the System Element

The Emphasis of the TRAK Metamodel is the System Element


An assessment of the content and purpose of the LUL viewpoints showed that these could be accommodated within MODAF. The problem with MODAF, however, was that it had too many views [in MODAF terminology a viewpoint is a collection of views, not a specification for one] and had to respect its logistic tail with respect to tools and also origins in DODAF and parity with other frameworks. LUL needed something simpler and therefore the number of viewpoints and views was simplified. The number of viewpoints affects the degree of overlap and therefore the ability to select the right one i.e. affordance and visibility in the user interface.

Viewpoints (specifications for views in ISO/IEC/IEEE 42010 terms), were grouped by similarity of domain and content into Perspectives - Capability, Operational, Procurement, Solution and Management.

As LUL were keen on applying ISO 42010, viewpoints were created to specify for each architectural view

  • the concerns or questions that the viewpoint addresses
  • the TRAK metamodel elements that have to be shown (and therefore the relationships needed)
  • the TRAK metamodel elements that can be shown for completeness or best practice
  • the presentation method(s), for example, connected block, matrix
  • consistency rules with other related TRAK viewpoints


As a result of this although TRAK had the aim of being rail-oriented the framework is domain agnostic and has been used to represent both the products, such as a signalling and service control centres, as well as the business and its organisation that produces or develops the products.

Recognising the wish to move away from Visio towards an object-based modelling tool with a repository that will enable models to be integrated and shared, a decision was made to use Sparx Systems Enterprise Architect. Eclectica Systems set up the modelling environment, installing MySQL as the DBMS to hold the model repository. It also developed the UML profile for TRAK to allow other UML modelling tools to more easily produce TRAK-compliant architectural models.

It developed a custom extension for Sparx Systems Enterprise Architect - a MDG Technology - that

  • defines each TRAK view
  • defines a toolbox palette containing the objects and relationships needed for each view
  • extends the EA Quicklink mechanism that offers only the allowed relationships depending on the source and destination object types
  • defines TRAK-specific searches - some using the built-in search filters and others using custom SQL for viewing newly added content, potential quality problems and also matrix views

More information on the plugin is provided separately.

Skill/Technology Keywords

  • MODAF
  • DODAF
  • Enterprise Architecture
  • Model-Based Systems Engineering (MBSE)
  • MySQL
  • SQL
  • Sparx Systems Enterprise Architect
  • Universal Modelling Language (UML)

External References

Categories: • ServicesEnterprise Architecture / Architectural ModellingTask

Article 2 of 4 articles  <  1 2 3 4 >