View TRAK:About TRAK - Important Ideas
From the TRAK Enterprise Architecture Framework document:
This provides essential ideas that help in understanding what TRAK is, and what it isnt:
- TRAK is a standard to promote consistency and therefore interoperability and exchange of architecture models or descriptions. It is designed to encourage re-use, collaboration and sharing of architecture models. For this you need a consistent set of modelling elements and relationships and rules that determine what can be shown on an architecture view.
- 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/thinking activities and concerns.
- TRAK can represent 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 is not UML, SysML, BPMN or any other architecture description language. 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 object types and use the relationships specified for the view being created. See Choice of Architecture Description Language.
- TRAK provides a controlled grammar or language for architectural modelling. TRAK provides a way of describing context, constraints, dependencies and associations using natural language so that 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 relationships and therefore meaning is all important. Relationships are portable.
- flexibility and re-use of model elements is achieved by a small set of element types but with many combinations. TRAK provides a rich set of combinations 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 relationships.
- TRAK is not a process, unlike TOGAF, TRAK mandates no process.You can create the views you need in the order you want appropriate to the task.
- architectural models 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 model of yours or your companys 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.
Covered by TRAK IPR and licenses
TRAK is also unusual amongst architecture frameworks because it applies systems engineering principles and processes to the architecture, design and definition of TRAK.
References
- TRAK Enterprise Architecture Framework document https://trak.sourceforge.io