The Residual World::Tag = 'Plan'
Entries that have been tagged with 'Plan'.-
by Nic Plum on Sunday 24 October, 2010 - 18:38 GMT
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.
architecture description language
form of expression used for the description of architectures
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.
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
- 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
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!
- What Would a TRAK View Look Like in a Graph Database? Part 1 (22% )
- Definitions - What Exactly is a Risk Part 2? (11% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (11% )
- MODAF is Dead - Long Live ‘NAF’? (11% )
- Definitions - What Exactly is a Risk? (11% )
- Latest draft of ISO/IEC 42010 http://www.iso-architecture.org/ieee-1471/docs/ISO-IEC-IEEE-latest-draft-42010.pdf
- ANSI/IEEE Std 1471 :: ISO/IEC 42010 site - http://www.iso-architecture.org/ieee-1471/
by Nic Plum on Saturday 02 January, 2010 - 14:03 GMT
Posted in Site
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
- This is But One Part of a Bigger “Whole” (29% )
- Standards - Site Appearance in Internet Explorer 8 vs Anything Else (14% )
- Keep Clear Separation Between the Concerns that Each Architecture View Addresses (14% )
- Risk and Threats - The Common Ground Between Security and Safety? (14% )
- Architecture Description Language (ADL) vs Architecture Framework (14% )