The Residual World::Tag = 'Management'
Entries that have been tagged with 'Management'.-
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% )
- 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% )
- Definitions - What Exactly is a Risk Part 2? (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 Sunday 06 December, 2009 - 09:52 GMT
—Edited to reflect changes in names of TRAK Enterprise and Concept Perspectives—
Architectural frameworks normally provide ways of grouping views that have a common aspect and these collections are known as perspectives.
TRAK provides the following perspectives:-
- Enterprise (was ‘Capability’) concerned with the overall enterprise and capabilities needed.
- Concept (was ‘Operational’) concerned with the logical ‘what’
- Procurement concerned with projects and delivery of solutions
- Solution concerned with the behavioural and physical aspects of the solution
- Management concerned with the management of architectural views
They provide a way of simplifying and organising the architectural description.
TRAK defines a set of architectural viewpoints and view contents. Elements shown on a view have to be part of the underlying metamodel and can only be connected using the allowed relationships. TRAK specifies what can be shown and how it is presented and organised. This is shown in the context of IEEE 1471 in Figure 4?1. It is the architecture element conforms to metamodel relationship outside the IEEE 1471 space and the framework defines architecture viewpoint and framework defines perspective that provide conformity and consistency.
This perspective covers the enduring capabilities that are needed as part of the bigger enterprise. These are high level needs that everything else contributes to and form part of the long term strategic objectives that need to be managed. It provides a mechanism to link into the higher level goals such as Keep London moving.
The concept perspective covers the logical view of what is needed. It covers the logical connection of concept nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It provides a means of stating the operational exchange needs and information required.
The procurement perspective provides a top level view of the solution to the problem outlined in the capability perspective and developed in the operational perspective in that it provides a way of showing how projects deliver solutions to provide capability. It provides a way of showing time dependency between projects and is an essential prerequisite for investigating capability gaps in the capability perspective. It also provides a mechanism for showing how organisations and projects relate to the systems being delivered.
The solution perspective provides views of the solution or potential solution, recognising that there may be many potential solutions which might meet the logical needs expressed in the operational perspective. Functional views provide a means of describing the behaviour in terms of functions, activity, sequence, state and interactions. Physical views describe how the system is organised, how information is routed and where parts are or must be.
The management perspective covers views that are concerned with the management and production of the architecture products. It enables the scope of any architecture task to be defined and the provides ways of recording what was done and capturing the intended understanding so that the architecture can be provided to others or re-used.
- Risk and Threats - The Common Ground Between Security and Safety? (30% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )
- Definitions - What Exactly is a Risk? (10% )
- Just When You Thought It Was Safe - EntiTy Returns (10% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )