RW - Navigation

RW - Recent

Last 10 entries [comments]:


Last 10 posts [threads/views]:


Last 10 pages updated:

There are 487 wiki pages in total.

RSS logoRSS Feed

Architecture Description Language (ADL) vs Architecture Framework

by Nic Plum on Sunday 24 October, 2010 - 18:38 GMT

Posted in Architecture FrameworkArchitecture ModellingStandards

Tags: adlarchitecture descriptionarchitecture description languagearchitecture frameworkieee1471iso42010managementplanstandard

This arose out of an email conversation I’ve been having with Rich Hilliard and Dave Emery relating to ISO/IEC 42010 which is now at the Final Committee Draft stage. I’d been looking at ArchiMate in terms an architecture description language for use with TRAK. The ability to use ArchiMate with TRAK will be the subject of another post but it highlights the point that ISO/IEC 42010 will allow multiple architecture description languages to be used within an architecture description.

p15 of ISO/IEC 42010 FCD dated 17th June 2010

architecture description language

form of expression used for the description of architectures

architecture framework

conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders


An architecture description language (ADL) is any form of expression for use in architecture descriptions. Like an architecture framework, an ADL frames some system concerns for some audience of stakeholders using one or more model kinds and/or viewpoints. An ADL can be very specific; defining a single model kind, or it could define several viewpoints, and correspondence rules. Often an ADL also makes available automated tools to aid the creation and analysis of models.


An architecture description could comply with no, one or more architecture frameworks. For an architecture description to comply with more than one framework would imply some reconciliation between each framework’s stakeholders, concerns, viewpoints, model kinds and correspondence rules.


An ADL need not provide any architecture viewpoints; it can define one or more model kinds for use in architecture viewpoints defined elsewhere.

Examples of ADL include - the UML, SysML, BPMN and ArchiMate. There are many other possibilities. Examples of architecture frameworks of relevance to this site include DODAF, MODAF, CNDAF, NAF and TRAK. The UML is a common ADL used for MODAF, DODAF etc and the ADL camp divides into UML/non-UML.

Of interest is what happens when you use more than one ADL or indeed a single ADL. If you use an architecture framework how much of the framework is covered by the ADL? Does this matter? Well it does if you chose the framework because it covers the concepts or areas that you feel are important to be able to represent but then choose an ADL that cannot cover the metamodel of the framework. At the very least this needs to be an explicit and conscious decision that is recorded and periodically reviewed.

Mapping the ADL Metamodel to the Architecture Framework Metamodel to Assess Suitability of the ADL for the Architecture Description Task

Mapping the ADL Metamodel to the Architecture Framework Metamodel to Assess Suitability of the ADL for the Architecture Description Task

If an ADL only partially covers the framework chosen it makes sense to consider using multiple ADLs. There are often other reasons for using ADLs such as familiarity, availability of toolsets. If you do choose to use multiple ADLs you need again to look at the coverage but you also then have to decide when each is best used. This might include a definition of the architecture framework viewpoints each is used for. If there are overlaps how do you deal with them? There are also interoperability considerations - if I create a model using one ADL is is sensible/possible to consider importing this into the other? Will this fragment repositories and if so how do you integrate them or stop things falling into the divide?

Someone has to make an assessment of the suitability/fitness for purpose of the ADL set against the framework proposed and identify any limitations or practical problems. It might be that certain types of model and probably viewpoint are developed and maintained by a particular community so this might drive the choice of ADL.

Where would this assessment and decision-making sit? It isn’t part of the framework as the frameworks are usually ADL- agnostic and the choice in any case is a local one and part of the implementation of a framework. It isn’t also part of a global standard such as ISO/IEC 42010. A standard might highlight these as general or typical considerations but again the choice and the justification of this choice is local. It has to be placed within some local formal framework which sounds like an Architecture Description Modelling Plan for the sake of better terminology.

This plan ought to state at the very least:

  • scope in which the architecture description task as a whole sits
  • architecture framework to be used (with justification/rationale)
  • types of architecture description and purpose / relationships between them
  • architecture description language(s) used
    • justification/rationale
    • coverage of each ADL vs framework
    • viewpoints each is suitable for
  • how interoperability between ADLs is managed
  • limitations / exclusions and impact
  • how the architecture description task is managed

    • organisation(s)
    • toolsets

In this sense it should cover similar areas, or have similar content to other engineering management plans.

Has anyone had any practical experience in this area? What did you do? any problems? Comments welcome, as usual!

External Links


A total of 3 comments have been made. :


-author: Colin Wood

-date: Thu, 18 November 2010

-time: 06:11pm

-IP address: **logged**

In ISO/IEC FDC 42010 the figure for AF and the figure for ADL are practically identical. This is not consistent with the text definitions for AF and ADL.

The AF figure 5 says an AF identifies Stakeholder whereas the Conceptual model figure 1 says the AD identifies the Stakeholder. I think the second is true. If there is a transitive relationship then it should be made clear.


Thumbs-up icon0 likes Thumbs-up icon0 dislikes


-author: Nic Plum

-date: Thu, 18 November 2010

-time: 07:30pm

-IP address: **logged**

They’re likely to be different stakeholders since the AF is often applied across a company or more generally than any architecture description. Any concerns at this level are likely to be more general. Types of? If so then what we have at AF level are types of concern and types of stakeholder.

As architecture descriptions are task and concern-focussed the stakeholders and concerns are going to be quite specific- instances of concern and stakeholder.

It could therefore apply to both but this needs then to be made clear.

Thumbs-up icon0 likes Thumbs-up icon0 dislikes


-author: Rich Hilliard

-date: Thu, 18 November 2010

-time: 09:42pm

-IP address: **logged**

No transitive relation intended. Figures 5 and 2 [not 1] are depicting two different subject matters.

Figure 5 describes the contents of an Architecture Framework (when conforming to the Standard): typical system stakeholders, system concerns, viewpoints, model kinds, etc.

Figure 2 [not figure 1] describes the contents of an Architecture Description (when conforming to the Standard): system stakeholders, system concerns, etc.

The reason for associating typical stakeholders with a framework is to aid users of the framework to determine its suitability in applying it to a system.
One would not apply a framework F in architecture description A if the typical stakeholders of F could not match up the identified stakeholders of A.

Thumbs-up icon0 likes Thumbs-up icon0 dislikes

Leave a comment

If you log-in you don't need to provide your contact details. Site members can also like/dislike comments and rate posts.

Login | Register




required input

Email is not visible after submission - it is only used to notify you.

My Comment:

Return to Previous Page

All articles/posts © of the respective authors

Site design and architecture © 2010 - 2019 Eclectica Systems Ltd.