Page 1 of 3 pages  1 2 3 > 

Using Relationships and a Repository - Visualisation

This is a recurring theme. Systems-thinking, systems engineering and architecture description are primarily concerned with identifying and managing the important relationships with other things in the world. They are relationship-centric rather than object-centric.

It is often hard for folks used to using flat 2D diagrams produced in PowerPoint or Visio to appreciate the potential power behind relationships. Having said this a lot of tools marketed for architecture description or enterprise architecture are software development tools which are naturally and properly object-oriented rather than relationship-oriented.

Having a repository with a rich set of (consistent) objects and relationships allows you to explore beyond the immediate vicinity to assess impacts and dependencies. Although not intended for this purpose there is a very nice example on TED.com of the use of relationships by ecologist Eric Berlow which is helped by the ability to visualise them in a nice way. This could equally be achieved using a repository.

This is why sticking to the flat-land isn’t adequate to understanding where things sit and therefore how best to manage risk. The world isn’t flat!

Anybody used visualisation software for this sort of thing? What works best? Any good case studies where this has helped to either save the day or revealed something unexpected?

Comments

Comment on this article

Architecture Description Language (ADL) vs Architecture Framework

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

p25

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.

p31

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.

p32

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

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!

Comments

Comment on this article

Trapped in an Unfulfilled Relationship? Perhaps Wise Not to Rush for a Tool Just Yet

Relationships are one of the cornerstones to using an architecture framework, even more so if you’ve constrained the permutations of allowed relationships and object types though imposing a metamodel. For starters if you select (choose) an element in your model you know that it can only be connected to a limited set of other types of object and using one or a few relationships. So before you even touch the element you have expectations and therefore ideas about how you might then navigate through the model. Equally it helps you to spot errors.

If someone comes and asks what, if any dependency there is between System A and System P you immediately know what possible paths to look for in terms of the constructs provided by the metamodel.

So why, then are relationships very much second class citizens in modelling tools? I suspect the answer lies in their pedigree. Most will have developed from tools for the creators of software where the focus is on defining classes and attributes and on the objects themselves. Of course you can explore relationships but there are often very few ways of making these more explicit. For a software project the scope is often much more limited - usually local to the organisation whereas often what we’re up against is trying to map out how bits of an entire sector relate to each other. In this case we’re often asked to define or explore the relationships between a system and the ‘residual world’ as much as any exploration within the system itself. For the software creator the end result is the generation of code (from the same tool) rather than a model of their world where probably the number of relationships far exceed the number of objects.

The exploration of relationships is concerned primarily with access to the underlying database rather than the views that sit on the top. How easy is it in your tool of choice to expand or follow paths? Is it purely manual with experience driving it or does the tool itself help or offer suggestions? Does it offer many ways to query the database and how easy or hard is it? One of the best exploitations of relationships in a tool I’ve seen was in the probably now defunct ISSE, the then prescribed tool for the MoD’s Integration Authority within the Defence Procurement Agency. What ISSE did nicely was provide a dialog from which you could add a succession of lines, each representing a metamodel stereotype - relationship - stereotype so that you could construct a path. For example, you might simply have Capability Configuration - Resource Interaction - Capability Configuration. What ISSE would then allow is for the architect to tell it how many of these steps (iterations) to follow when starting from the selected model element and the result could be shown in detail or using a summarised notation with a dotted line. This made it much easier to quickly explore the database and find out if and how things depended on each other.

I’ve not seen anything quite like this since which is a shame. I suspect Im going to have to wait patiently as all sorts of clever features for coders are delivered and keep my fingers crossed that someone has actually figured out that the needs of the 2 communities that use these tools are different.

Comments

Comment on this article

Page 1 of 3 pages  1 2 3 >