The definition of the metamodel for TRAK (defines allowed AD elements and relationships i.e. tuples/ triples for the TRAK viewpoints and views). TRAK is a general systems-thinkers'/system engineering enterprise architecture framework. It is simple, user-friendly, pragmatic and not limited to IT.
- defines tuples / triples (declarative statements) that appear in TRAK viewpoints and views
- designed by systems engineers for others & based on need / typical application
- supports simple, pragmatic, no nonsense, just "good enough" way of addressing typical concerns (not populating a data model)
- metamodel (A3) for easy reference when modelling - see snapshot below for example
- defines each TRAK stereotype (object type in architecture description)
- defines attributes/properties of each object type e.g. dublin core, security descriptors, safety-related
- provides tests for/against to determine what type to use when modelling using TRAK
- defines colours to be used for each object
- defines each relationship (between stereotype / modelling object)
- defines tuple set rules (combinations of objects with relationships)
- provides rationale/justification for relationships
- released under GNU Free Documentation License
- written for users/architects/human beings - not specifiers or tool vendors
- designed to be used with TRAK Viewpoints document (http://trakviewpoints.sf.net) - also on Sourceforge
- defines initial baseline against MODAF 1.2
Anonymous thumbs down reviews that simply ask a question "What's the point?" are not terribly reliable or encouraging. TRAK works for me because it offers a system-centric approach which in other frameworks is either missing or obscured by an overburdened metamodel.
I'm not hugely expert on metamodels but I understand from others that this one is, by comparison, very simple and generic. This must make it really useful for making the case for architectural modelling to organisations that need it but don't realise it yet...