TRAK is a pragmatic, simple, general systems-thinkers'/system-centric enterprise architecture framework. It is simple, user-friendly, pragmatic and not limited to IT. TRAK has won an INCOSE award and is also a finalist in the 2011 IET innovation awards.
TRAK allows you to describe a system, its parts (which can include people, software, other systems and physical things) and how it relates to the residual world. It covers everything from the enterprise and its goals to the concept to the procurement of the solution via projects and the introduction or withdrawal of the system from service.
TRAK was originally based on the MoD Architecture Framework (MODAF) but is based on ISO/IEC/IEEE 42010 - the international standard for architecture description. There is a minimal process in which the architect selects the viewpoints (specifications for views) that address the task sponsor's concerns. It has rules that ensure that the description is consistent and also readable by the non technical audience. You don't have to be a softie or a tecchie to be able to use it.
It differs in many way from other architecture frameworks:-
- it covers many aspects, not just IT and computers e.g. systems configured with organisations, roles, jobs, physical and software (and other systems)
- it has typically less than half the number of viewpoints (specifications for views) yet describes everything from system structure, the extent of roles (or organisations and jobs) to claims, arguments and evidence (assurance)
- every view has a specified explicit minimum content in terms of a tuple: object - relationship - object construct
- the original intent of a view is clear - every object and relationship has a visible type and name on the view
- a TRAK view is a set of declarative statements - every view can be read as a set of sentences, indeed sentences are allowed, so you don't need to understand UML etc.
- TRAK has consistency rules that apply to the collection of views
- TRAK is specified as a user requirement - a logical set of requirements, not as a solution or design e.g. a UML profile so you can always see what the intent is and where any limitations in the implementation in a notation lie.
- the design process for TRAK is exactly the same as for anything else and TRAK makes clearly separates the requirement from the various implementations in notation and tools (with some other frameworks the user can only see / experience the implementation in a tool and has no means to determine what is part of the framework definition from what might be a results of a design choice in a notation or tool). See [Implementation of TRAK]
- the TRAK documents specify view content and view collection content - TRAK is not a rolled-up process (how you use it is your choice and it is assumed that organisations know how to manage configuration etc. so there is no point in adding needless words)
- the TRAK process, such as it is, runs only to about 6 short paragraphs (not 100s of pages)
- TRAK is truly open source where the source is open and accessible to all
- you don't have to purchase a license or be a member of anything to use it and it can be used for commercial gain as is
- TRAK actually complies with ISO/IEC/IEEE 42010:2011 including the definitions of 'view', 'viewpoint' and it recognises that the description of an architecture is separate from the architecture itself which is separate from the system of interest (some other architecture frameworks do not separate the description of the architecture from the architecture - so it only exists if it is being described)
Viewpoints are Grouped by TRAK:Perspective
Colour & Presentation Rules - help error spotting
Provides Advice on Choosing an Architecture Description Lang
TRAK Bye Laws - rules for views and architecture description
TRAK Has a Small Metamodel and Viewpoint Set - easy to learn
TRAK is Defined by 3 Documents Free of Implementation