Login  ·  Register

TRAK Community  ::  Wiki  ::  TRAK:Application of Systems Engineering to the Design of TRAK
Search Wiki  
  

Enterprise Architecture

Navigation - General

Keep Up to Date

Active Members:

Search:

 

Create or Find Page:

 

View TRAK:Application of Systems Engineering to the Design of TRAK

An architecture framework like everything else is an engineered product and therefore needs to be designed.

The System of Interest that is applicable to TRAK as an architecture framework includes:-

  • The expression / definition of TRAK itself - primarily the TRAK Metamodel and TRAK Viewpoints based on the metamodel.
  • The implementation of TRAK architecture description elements from the metamodel, for example as a UML or SysML profile
  • Any tool implementing track, for example a UML modelling tool which loads the UML profile for TRAK
  • The users of any modelling tool that implement TRAK
  • Any business processes that constrain how the users create and manage architecture descriptions

All of these system elements can affect other parts of the system and result in a mixture of wanted and unwanted end results.

  • For example in describing systems using the MODAF it seemed obvious to use the MODAF::System element. Unfortunately this was defined as part of the Physical Architecture and you couldn’t add or configure a System with anything else. You could, however, do this with the MODAF::Capability Configuration and therefore over time modellers would use the Capability Configuration element to represent a System. Semantically this made no sense but the behaviour of the tool in implementing the definition of the MODAF::System meant that this was the only practical method to achieve what was needed from a presentational point of view.
  • If the allowed content of two viewpoints overlaps too much it becomes difficult for the modeller to decide which viewpoint to use. Different modellers will make different choices leading to inconsistency. This results from a lack of affordance and possibly visibility from a human factors point of view. An example of this in the MODAF is is you wanted to describe an organisation hierarchy you could use the MODAF::OV-4 Organisational Relationships Chart Viewpoint* or the MODAF::SV-1Resource Interaction Specification Viewpoint**
    • * MODAF doesn’t conform to ISO/IEC/IEEE 42010:2011 - its ‘viewpoint’ is a collection of views/view descriptions unlike the 42010:viewpoint - see Architecture Framework Comparison
    • ** Confusingly system structure is defined using a view which focusses on the exchanges between the system elements - there is no separate view for strucure

As part of a system of interest it is essential to apply standard systems engineering practice to the design and expression of an architecture framework.

TRAK applies systems engineering practice in the following ways:-

  • Keeping the specification of “the what” separate from that of “the how”. The 3 principal specifications (TRAK, TRAK Metamodel, TRAK Viewpoints) are agnostic of any possible implementation. This not only applies to whole documents but the notations used within them, for example the definition of the TRAK metamodel does not use any implementation notation. This avoids possible problems such as common mode failure or a failure where a fault in the notation used for the agnostic-specification also appears directly in the design.
  • Applying Requirement Engineering practice to the TRAK specifications (rather than rely on inference by the position of elements within a diagram frame in a model):-
    • The requirements for a TRAK-conforming Architecture Description are specified.
    • Allowed view content is specified unambiguously as a set of atomic requirement statements - verifiable
    • Minimum acceptable content is specified unambiguously as a set of atomic requirement statements - verifiable
    • TRAK has been verified against ISO/IEC/IEEE 42010:2011 and published as a compliance matrix based on a standard assurance pattern of Claim(of conformance) - Argument - Evidence. This has includes conformance for any TRAK-conforming architecture description to save work for anyone who uses TRAK. Almost every framework claims compliance but doesn’t support the claims with any clause-by-clause analysis.
  • Considering the whole system-of-interest and its interactions
    • Consistency requirements apply to the collection of views in an architecture description - not just single views
    • Requirements apply to the order in which architecture description tuples are created to avoid possible inconsistent statements or short-circuiting information gathering e.g. identify an interface before characterising it, do not assert that a claim is proved without supporting arguments and supporting evidence
    • TRAK views have a defined sequence of creation in order to make it easier for the reader of the AD to understand where to find particular things (visibility, affordance)
  • Considering typical non-functional aspects
    • Human Factors - naming / making it easier for the modeller to pick the correct viewpoint
    • Human Factors - controlling the amount of overlap between viewpoint definitions to make it possible to construct a navigable story whilst ensuring sufficient separation to avoid one viewpoint being used in place of another
    • Human Factors - visibility - names are short, colours are used to visibly group parts of documents, each document defines where it sits in context
    • Human Factors - ease of understanding - plain english - no technical notation or language is used hence accessible to more than the usual “technical priesthood”
    • Human Factors - each TRAK view consists of a set of simple statements that can be easily understood e.g.
    • Maintenance - small metamodel and number of viewpoints, use of architecture description tuples makes the definitions testable and errors discoverable, no special tooling required - reducing maintenance burden over the lifetime of the architecture framework

References

 

© 2010 Eclectica Systems Ltd.