Page 9 of 9 pages ‹ First  < 7 8 9

Perspectives - Structure / Grouping of TRAK Viewpoints

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

• Enterprise (was ‘Capability’) – concerned with the overall enterprise and capabilities needed.
• Concept (was ‘Operational’) – concerned with the logical ‘‘what’’
• Procurement – concerned with projects and delivery of solutions
• Solution – concerned with the behavioural and physical aspects of the solution
• Management – concerned with the management of architectural views

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.

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

Related Articles

{REL[126][related1_blog]pQd6sFaqREL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (30% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (20% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (10% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (10% )
• TRAK Article Published by The Institution of Engineers (Singapore) (10% )

External Links

What is TRAK?

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

Related Articles

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (22% )
• ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released (11% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (11% )
• TRAK Article Published by The Institution of Engineers (Singapore) (11% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (11% )

External Links

• London Underground website (part of the Transport for London (TfL) site
• MODAF
• MODAF Metamodel (M3) - version 1.1

What is the Point of this Site?

Indeed, what is the point of this site? Why go to the trouble and suffer the frustrations in creating it? Why not simply “get a life”?

Background

It started with TRAK (very nearly a Hot Chocolate hit there!) - The Rail Architecture Framework - which I’ve been developing over the last year for London Underground Limited. This is based on the MODAF, the MoD Architecture Framework which is important to the rationale for the site. At the beginning it was thought that a framework would need to contain rail-specific constructs and views but in the end we realised that we’d created something that was domain or industry-free. It should have been obvious from a system-thinker’s perspective, but the journey to this point is just as important as the realisation.

Of course in developing and trying out the views, the UML profile and the plugin for Sparx Systems Enterprise Architect modelling tool similar questions arose. It was also valuable because it meant that the development was led by the pragmatic, down to earth needs and problems faced by architects delivering views and models to meet deadlines.

In reality the experience in TRAK is building upon the experience over many years first at the MoD at Abbey Wood and then at the Architectures Lab at Malvern. Most of the support and help was provided by the group itself. It had to be this way because we were modelling in the days before MODAF and discovering and making rules based on practical experience. Like most things in life you need to experience failings and problems to properly appreciate the wisdom of others!

Geneology

Since DODAF first appeared many other related enterprise architecture frameworks have appeared. They all continue to borrow ideas from each other as they evolve.

Many Enterprise Architecture Frameworks are Related to DODAF

The Perceived Need - Support

The sorts of areas where help, advice and support is needed for enterprise architecture include

• frameworks
• definition - what must appear
• advice - what should appear
• what a framework can represent, what it can’t represent
• when something else is best used to represent
• modelling style
• how to represent particular configurations, functionality
• modelling patterns or conventions often encountered
• types of model
• utility or usefulness
• best views for a purpose
• fitness for purpose
• when to use a model / when not to
• dealing with stakeholders
• applicability of views to common development scenarios / lifecycle e.g. design review points, activities
• collaboration
• preparing for sharing models
• working with remote colleagues
• keeping in sync - models & understanding & consistency
• dealing with privacy
• communication - the primary objective as we need to be able to communicate findings, analysis, implications (as interesting as it might be it’s not for our own benefit!)
• detail, scope - what to include / leave out
• adjusting for stakeholders - maintaining the model & avoiding the simple powerpoint/visio syndrome (“just a diagram”)
• organisation of views / model - navigability - “telling a story” / the user-interface of the model presented
• documenting the model, findings
• tools for modelling
• limitations
• features
• compatibiity/interoperability with other tools
• model / repository organisation
• model/repository consistency

Apart from the very obvious framework-specific part many of these areas overlap and face common problems. Solved once the solution ought to be able to help others even if the framework being used is different.

Then there’s the people side. Many of us who work with one framework have and will work with others so why create silos? As with the models produced it makes sense to try and reuse, adapt and extend wherever possible. The centre of gravity ought to reside with the users and user-generated content not with the standards themselves - it has to be of use and pragmatic.

It therefore seemed if a means of enabling support were provided, to recognise this overlap between all the DODAF-related frameworks.

The Purpose

In short

The purpose of the site is to provide a means for users and practioners of DODAF/MODAF-related architecture frameworks

• to get practical advice and help
• to give advice and help

to help create, share and build-upon (extend) existing architecture models.

The watchwords are - useful, practical, understandable

The Belief

It might be that everything is already covered - there’s enough “how to”, FAQ, examples, advice when faced with typical project situations. It might be that as a bunch we like best to keep quiet and keep it all to ourselves or that we believe that knowledge is power. I’d rather believe that we like helping others (and in doing so we often help ourselves).

If you’re in the latter category then please sign up and please contribute - whether comments on entries, discussions in forums, examples of architectural views or adding to the wiki. You never know when it might prove useful. It’s also self-help and therapeutic to share!

Comments

Comment on this article

Related Articles

{REL[129][related1_blog]pQd6sFaqREL}

Sharing tags:

• Conformance Assessment vs ISO/IEC 42010:2011 (8% )
• TRAK is a Finalist in the 2011 IET Innovation Awards (8% )
• TRAK Article Published by The Institution of Engineers (Singapore) (8% )
• Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint (8% )
• Risk and Threats - The Common Ground Between Security and Safety? (8% )

Forums

• See discussion thread in forums

External Links

• Wikipedia - Enterprise Architecture Framework
• The MOD Architecture Framework -  (now hosted within MoD site
• Wikipedia - DODAF
• DODAF - version 2.0
• NATO Architecture Framework (NAF)
• Department of National Defense/Canadian Forces Architecture Framework (DNDAF)

Page 9 of 9 pages ‹ First  < 7 8 9