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

The Residual World::Tag = 'Plan'

Entries that have been tagged with 'Plan'.-

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!


Comment on this article

Related Articles

    Sharing tags:

    External Links

    Putting the Architectural Modelling Community First - What You Can Expect to See

    by Nic Plum on Saturday 02 January, 2010 - 14:03 GMT

    Posted in Site

    Tags: blogforumfunplansitestructurewiki

    This current site is really only a interim site. What is intended is a site that properly supports the folks using TRAK or other MDAF-based architecture frameworks and one which represents the ethos behind it:-

    • pragmatic - led by need and application - the human interface to the framework (usability, affordance etc.)
    • open - decisions, rationale, explanation
    • democratic - involve the community in the site content rather than broadcast top down what I/we think folks need. The centre of gravity ought to be with the users rather than the specifiers-of the framework
    • fun - why not? Systems thinkers/engineers and architects are real, dare I say it ‘whole’ people and all sides need to be addressed
    • dynamic - the content needs to be able to change and adapt to new circumstances, thinking or practice

    What You Might Expect

    The features that you should expect to see are:-

    • each section of the site is a ‘blog’
      • articles can be discussed and commented on by site members
      • updates notified by RSS news feeds
    • articles can be linked together, tagged, put into categories and dynamically sorted/displayed and searched for by users
    • discussion forums
      • tool support
      • use of architecture frameworks
      • modelling / repository organisation - not governed by frameworks but important and common to all
    • architects can submit examples of views to help others
    • wiki to hold facts on architecture frameworks e.g. metamodel elements, use of UML tools, tips, plugins etc.
    • single sign-on to comment, add a forum discussion or to add to the wiki
    • everyone can see everything - nothing hidden
      • only site members can contribute or comment - contributors and commenters recognised and stand up to the mark!
    • fun / anarchic humour
      • the lighter side
      • not taking life too seriously


    Comment on this article

    Related Articles


      Sharing tags:

      External Links

      1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat

      All articles/posts © of the respective authors

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