View Consistency


Consistent architecture is a big goal in architectural modelling.

It applies in different ways:

  • consistency of meaning (the semantics - using the same elements to mean the same things)
  • consistency of representation (consistent modelling) - using sets of elements in the same way to represent a real world situation (modelling is creative and there are often several ways of representing a situation). There will always be house styles.
  • consistent model organisation - if model elements are in unexpected places it makes it harder to share externally
  • consistent presentation - if views are to be presented to a wide audience this can be important

It can, however, be a pain trying to keep things consistent. Some tools are better than others in enforcement or maintenance of consistency. For example, a simple drawing tool will never be as good as one where a common pool of objects is available for re-use.

In order to constrain the types of architecture element used and their meaning you have to have an enterprise architecture framework based on a metamodel. This is the minimum necessary to enable meaningful exchange of architecture models.

Frameworks cannot specify everything that is needed to ensure consistency, however. Some of this has to be by process. A framework is necessary but not sufficient at the larger consistency scopes (see below).

Consistency Scope

The following scopes of consistency apply:

  • within an architecture view
  • between architecture views (in the same architecture description or model)
  • within an architecture description (AD) or model (irrespective of views)
  • between different ADs within the same repository
  • between separate or isolated ADs in different repositories

How Consistency is Maintained in Architecture Frameworks

Different architecture frameworks will have different approaches and mechanisms used to try and maintain consistency.






TRAK consistency rules.




© 2010 Eclectica Systems Ltd.