TRAK Architecture FrameworkThis page reproduces parts of the overall TRAK0004 specification for information only. It may not therefore reflect the master source content at https://sourceforge.net/projects/trak.
TRAK - Important Ideas
TRAK is a general purpose and pragmatic enterprise architecture framework which has its roots in the UK MoD's MODAF 1.2. but is substantially different both in content, the specification of architecture views, consistency rules and the design approach used.
The following are ideas that are important to understanding what TRAK as an architecture framework is and also what it isn't.
TRAK provides a set of standards to promote consistency and therefore interoperability and exchange of architecture descriptions. It is designed to encourage re-use, collaboration and sharing of architecture descriptions. For this you need a consistent set of architecture description elements and relationships and rules that determine what can be shown on each architecture view.
Architecture Description is bedevilled with inconsistencies - inconsistency of presentation, inconsistency or meaning, inconsistency of terminology, inconsistencies of triples or relationships between architecture views and across an architecture description.
TRAK is a general purpose architecture framework. Whilst it is system-centric it does not use any domain specific language or constructs. It is oriented towards typical systems engineering activities and concerns.
A system doesn't know what domain it's in. As TRAK has been created by systems engineers it describes things that we often observe or deal with in our jobs.
TRAK can describe concepts ranging from high-level business or enterprise goals to the detailed working of a solution, whether an organisation or a physical product. It is important to be able to place the solution in proper context of the enterprise and projects.
TRAK’s purpose is to provide a means to answer a task sponsor’s concerns - not populate an underlying data model. Once created, however, it may be possible to use the relationships and attributes to answer queries depending on the implementation. TRAK can therefore support Model-Based System Engineering (MBSE).
Architecture repositories are expensive to create and maintain and they do not happen overnight. They grow and evolve over time by describing much smaller parts of the world.
TRAK is not UML, SysML, BPMN or any other architecture description language. See Choice of Architecture Description Language (ADL) -TRAK is TRAK. It allows you to use any architecture description language to describe the real world and form architecture views. All TRAK mandates is that you stick to the allowed set of architecture description triples specified for the architecture view being created.
TRAK provides a controlled grammar or language for architecture description. TRAK provides a way of describing context, constraints, dependencies and associations using natural language so that architecture views are easy to read. Relationships provide hard-wiring such that in a modelling tool you can analyse, query, navigate between elements to get the information needed. This is very different idea from a ‘flat’ diagram where you are limited to presentation, such as colour to provide meaning. Getting consistent triples and therefore meaning is all important. Triples are portable.
The triples provided by the TRAK metamodel provide the statements to describe real world architecture. Since the metamodel provides a fixed set of elements and triples it forms a controlled grammar. This langauge or grammar is not that of any other notation or modelling language. It follows therefore that TRAK architecture views do not replicate diagrams or views of any other modelling language.
TRAK, in providing a controlled language and having atomic requirements to restrict the statements presented in each TRAK architecture view, provides the means to reduce inconsistencies.
Flexibility and re-use of architecture description elements is achieved by a small set of element types but with many combinations. TRAK provides a rich set of triples forming statements that can be used to describe most situations.
no one tool or methodology is suited to everything. TRAK does not seek to replace your existing requirement management, project management or other tool sets - it augments them and is very good at showing context (flows, ownership, governance, membership, precedence, responsibility, structure boundaries) using triples.
TRAK is not a process, unlike TOGAF. TRAK mandates no process. You can create the architecture views you need in the order you want appropriate to the task.
TRAK has a tiny minimal process - just sufficient to address a task and to keep the architecture product consistent and no more. It isn't the responsibility of TRAK to define a company process.
Architectural descriptions are long term stores of information - they are a significant investment and should be built on rather than start afresh for every task or project.
An architecture repository is a step towards forming a description of yours or your company’s world - a “wikitecture”. Architecture description works best if the people contributing reflect the breadth of the TRAK metamodel - in other words not just those with ‘architect’ in their job title. This helps ensure that the right people own and maintain their respective parts of an architecture description for the collective good.
TRAK uses simple natural language statements, for example, 'Organisation makes Claim about Software'. It requires these statements to be visible and hence you simply read what you see. This requires no specialist knowledge of modelling languages and therefore pretty much anyone in a company is able to understand the statements made in a TRAK architecture description - not just a specific 'technical priesthood'.
TRAK00004. TRAK. Architecture FrameworkTRAK is subject to the terms of open source license: GNU Free Documentation License (Version 1.3, November 2008) at https://www.gnu.org/licenses/fdl-1.3.html.