How ISO/IEC 42010 Controls Architectural Description

ANSI/IEEE Std 1471 :: ISO/IEC 42010 - Recommended Practice for Architectural Description of Software-Intensive Systems

ISO/IEC42010:2007 states that ‘most architects must work within an architecture framework’ where this is defined as ‘a predefined set of concerns, stakeholders, viewpoints and viewpoint correspondence rules; established to capture common practice for architecture descriptions within specific domains or user communities’.

It controls architectural modelling at a high level by requiring architecture viewpoints that specify what concerns a particular view answers and what content a view must contain. It does not specify how the modelling is done or what presentation language must be used, for example UML, SysML, BPMN.

ISO/IEC 42010:2007 Conceptual Framework for Architecture Description

UPDATE. The re-issue of the standard as ISO/IEC/IEEE 42010:2011 changes the underlying conceptual metamodel in the standard. This is shown on ISO/IEC/IEEE 42010 website.

IEEE 1471 does not specify any particular one because it states that these are specific to the needs of a particular domain and there is not, as yet, any consensus on generic architecture frameworks. 

In ISO 42010:2007 it specifies that an analysis be undertaken of the consistencies across the architectural views and any known inconsistencies be identified. Where does this consistency arise from, however, and what is the scope? It is perfectly possible for an architecture description comprising a set of models to be self-consistent. The problem is that another architect can choose to model using different object types and whilst again consistent the 2 architects will have produced 2 architecture descriptions that can’t easily be exchanged or re-used.

IEEE 1471 is evolving and not only has the name changed to better reflect the application of architecture modelling - ‘Systems and Software Engineering - Architecture Description’ [draft 7, 25th January 2010]. It also has more on architecture frameworks and states that

Correspondences and correspondence rules as specified in 5.7.2 and 5.7.3 may be used to express, record, enforce and analyze consistency between models, views and other AD elements.

IEEE 1471 is definitely heading in the right direction and provides useful principles and rules. Simply making a reference to IEEE 1471, however, is not sufficient in order to control architectural modelling to the level needed to be able to maximise the likelihood of success for the exchange of architecture descriptions (or models). Correspondence rules are necessary but there are potential problems with sets of text-based rules (this affects any requirement collection). A metamodel defines that only the allowed element types and relationships that can be used in a model or architecture description. In essence it provides the architect with a mandated language of nouns (element types) and verbs (relationships) to describe the system of interest. It is also visual and a very concise form of specification. There will always be the need for additional rules to specify consistency between views for the system of interest but having a metamodel is essential to a consistent set of building blocks from which to construct the views.

I’d argue strongly that having a declared metamodel is fundamental to defining an architecture framework and that without one you can’t hope to control consistency of modelling or meaning (semantics).

Even with a well-defined and controlled architecture framework there will be problems in exchanging architecture descriptions (and models) since modelling is a creative art providing many ways of modelling a particular thing and we have local or personal modelling styles. If we don’t share or have good access to a central set of definitions which includes elements and probably agreed boundaries (i.e. agreed understanding of the system breakdown structure) it is likely that elements will have different semantics.

IEEE 1471 is a good start and an architecture framework with a metamodel helps, but there is a lot more to put in place to be able to successfully exchange and collaboratively develop architecture descriptions (and models).

Comments

Comment on this article

Related Articles

{REL[6165][related1_blog]iSyrenwNREL}

Sharing tags:

• Risk and Threats - The Common Ground Between Security and Safety? (20% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )
• Definitions - What Exactly is a Risk? (10% )
• Definitions - What Exactly is a Risk Part 2? (10% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )

External Links

• Wikipedia - IEEE 1471
• ISO/IEC/IEEE 42010 website