Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

What is TRAK?

by Nic Plum on Monday 02 November, 2009 - 18:46 GMT

Posted in Architecture FrameworkTRAK

Tags: colaborationexchangehistorylondon undergroundmodafmodelportabilitystandardtrak

TRAK - The Rail Architecture Framework - is an architecture framework (Editor - ‘no kidding’?) that was born within London Underground Ltd. based on MODAF and hence also DODAF.

Like other architectural frameworks it provides a fixed grammar (objects and relationships) for representing the real world in architectural models - everything from the enterprise down to the technical products and interfaces. It also forms an interoperability or exchange standard to allow models to be exchanged with others.

It has it’s beginnings in proprietary attempts to establish standards for system architecture. Prior to this there were single views of purely physical architecture. Architectural views of the physical, functional and geographic architectures of the underground were developed and the relationships between views established.

A metamodel with a richer langauge for describing rail architecture was needed. There wasn’t any obvious architecture framework available within the rail industry that could describe systems other than computer or IT systems and after deliberation it was decided to adapt the MODAF metamodel for use within the rail domain.

The driving needs have been:-

  • simplicity
  • pragmatism - good enough / fit for purpose is all that’s needed
  • recognition of hard and soft ‘systems’
  • supportable by tools

 

The objectives in developing TRAK are:-

  • Standardising the content and presentation of rail architecture views. At present different companies, different projects present diagrams that mix ideas and presentation and which have no means of checking for consistency. Typically they are on paper, difficult to maintain and each diagram represents a fresh start in terms of the objects, descriptions and relationships shown.
  • Providing a standard for the exchange of architectural models of rail ‘systems’. There is no means to allow incorporation of the architecture represented on a diagram within another project or companies architecture.
  • Enabling portability of architectural models of rail architecture. Diagrams are paper or CAD files. One is portable but not easily integrated, the second is portable very restricted in those who can use it.
  • Collaboration. If models can be exchanged and re-used and standards define the component parts of the model then it becomes possible to collaborate.
  • Providing the means to show interactions and dependencies between enterprise, project, operational and solution component parts – i.e. a more complete systems engineering (holistic) view.

 

The thing is .. having set out to create an architecture framework for the rail community we stripped out all defence-specific concepts, added things to better represent systems and organisations and have ended up with something that is generic. This shouldn’t have been a surprise - a system is a system and it doesn’t know whether it’s in rail or telecomms nor whether it is a hard or soft system.

External Links

Comments

Be the first to comment on this post.

Leave a comment

If you log-in you don't need to provide your contact details. Site members can also like/dislike comments and rate posts.

Login | Register

Name:

Email:

URL:

required input

Email is not visible after submission - it is only used to notify you.


My Comment:

Return to Previous Page

All articles/posts © of the respective authors

Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.