Listing all articles in The Residual World under the category 'Architecture Framework' :

Perspectives - Structure / Grouping of TRAK Viewpoints

by Nic Plum on Sunday 06 December, 2009 - 09:52 GMT

Posted in Architecture FrameworkTRAKStandards

Tags: capabilityconceptieee1471iso42010managementoperationalperspectiveprocurementsolutiontrak

—Edited to reflect changes in names of TRAK Enterprise and Concept Perspectives—

Architectural frameworks normally provide ways of grouping views that have a common aspect and these collections are known as perspectives.

TRAK provides the following perspectives:-

They provide a way of simplifying and organising the architectural description.

TRAK defines a set of architectural viewpoints and view contents. Elements shown on a view have to be part of the underlying metamodel and can only be connected using the allowed relationships. TRAK specifies what can be shown and how it is presented and organised. This is shown in the context of IEEE 1471 in Figure 4?1. It is the ‘architecture element conforms to metamodel’ relationship outside the IEEE 1471 space and the ‘framework defines architecture viewpoint’ and ‘framework defines perspective’ that provide conformity and consistency.

IEEE 1471 Model - with links to TRAK Metamodel

IEEE1471 Conceptual Model with TRAK Metamodel Elements Added

Each TRAK viewpoint (and therefore view) is designed to address specific concerns or questions.

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. It provides a mechanism to link into the higher level goals such as ‘Keep London moving’.

Concept Perspective

The concept perspective covers the logical view of what is needed. It covers the logical connection of concept 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 provides a means of stating the operational exchange needs and information required.

Procurement Perspective

The procurement perspective provides a top level view of the solution to the problem outlined in the capability perspective and developed in the operational perspective in that it provides a way of showing how projects deliver solutions to provide capability. It provides a way of showing time dependency between projects and is an essential prerequisite for investigating capability gaps in the capability perspective. It also provides a mechanism for showing how organisations and projects relate to the systems being delivered.

Solution Perspective

The solution perspective provides views of the solution or potential solution, recognising that there may be many potential solutions which might meet the logical needs expressed in the operational perspective. Functional views provide a means of describing the behaviour in terms of functions, activity, sequence, state and interactions. Physical views describe how the system is organised, how information is routed and where parts are or must be.

Management Perspective

The management perspective covers views that are concerned with the management and production of the architecture products. It enables the scope of any architecture task to be defined and the provides ways of recording what was done and capturing the intended understanding so that the architecture can be provided to others or re-used.

Comments

Comment on this article

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.

Comments

Comment on this article

All articles/posts © of the respective authors

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