Login  ·  Register

TRAK Community  ::  Wiki  ::  Implementation of TRAK in a Tool
Search Wiki  
  

Enterprise Architecture

Navigation - General

Keep Up to Date

Active Members:

Search:

 

Create or Find Page:

 

View Implementation of TRAK in a Tool

TRAK_logo_60.jpg

Overview

The implementation of TRAK in any tool needs to be as consistent as possible to support exchange of architecture descriptions. There are a number of elements to this and therefore ways to control or improve consistency. Since the definition of TRAK itself is logical / free of implementation this has to be done via things that respond to this central definition.

Elements of Implementation

There are several elements to an implementation of an architecture framework like TRAK and each of which might introduce errors or limitations:

Choice of Architecture Description Language

An architecture description language such as UML, BPMN, ArchiMate has its own set of concepts or elements and is designed for a particular purpose. This purpose and therefore the elements you can select will be different from that of an architecture framework such as TRAK. Depending on the ADL you choose therefore the extent that you can represent TRAK viewpoints and therefore views depends on whether the ADL has the elements and the connector types to be able to represent the content required by a TRAK viewpoint. For example, if the ADL does not contain something to represent an Enterprise it is not then possible to use it to construct any views in the Enterprise Perspective.

There is always some difference between an ADL and a framework in terms of the concepts that can be represented and therefore you should always choose an ADL having done an analysis to understand how well a framework such as TRAK can be represented using the ADL.

TRAK as an organisation is unable to control the implementation of any ADL and therefore all that can be done is to make the implications of a particular choice of ADL visible.

In the case of TRAK an assessment of the use of UML to represent TRAK viewpoints/views has been made and is provided in the trak project on Sourceforge. It makes sense to keep the assessment centrally to save others having to repeat the exercise.

Implementation of an ADL within a Tool

The definition of an ADL is controlled completely separately from that of a tool (as it should be). There is always the possibility that a tool vendor will either interpret a specification differently or possibly a bug will be present in their implementation of the ADL within a tool.

This is outside the control of TRAK and because a modelling tool will typically only use particular ADLs the choice of tool affects the choice of ADLs that can be used.

Implementation of TRAK Definition within a Tool

The definition of TRAK is completely solution / implementation-free. It does not specify an ADL, a tool or any other means of implementation.

The implementation of the stereotype names, the attribute names and possible values needs to be controlled to be consistent and this is done via a separate specification ‘TRAK. Implementation. Architecture Description Elements’.

This specification defines:

  • the implementation of stereotype names

  • the implementation of attribute names

  • the implementation of attribute values

    • values in enumerated lists
    • the standards that apply to the format
  • A means to rank the compliance against the implementation specification

Other Frameworks

No assessment of the suitability of an ADL for use for DNDAF, MODAF, DODAF or NAF appears to be made public.

There is a mapping between the elements in the UPDM and MODAF/DODAF but this is not complete because it doesn’t identify limitations or where additional constraints are introduced as a result of using the UPDM to implement MODAF/DODAF (i.e. where the UPDM specification either falls short of that for MODAF/DODAF or where it adds constraints not in the original MODAF/DODAF specification.)

References

 

© 2010 Eclectica Systems Ltd.