Show several instances of the same element on one diagram

[matthew.james]

Richard - for me the challenge is that we are using Archimate as well as UML.
From an Archimate perspective, there is no such thing as an instance (or alternatively an element is the instance depending on how you look at it).  The overhead and implications of creating children and generalisations make that quite messy, and breaks the model (in the sense that there are multiple things representing the same thing).

To be clear, I am sympathetic to the argument that whilst putting multiple elements on a diagram to handle layout challenges would be convenient, it's also a bit of a cop-out. However we have use cases where we genuinely need to represent the same element multiple times on Archimate diagrams due to the inherent structure of the type of diagram.  One example is 'box in box' diagrams of a hierarchy, with overlays of a different concept.  For example - a Capability Map (box in box) with an overlay of applications, projects, strategies etc  Usually the overlaid concept has elements associated with multiple capabilities, so needs to appear multiple times; the entire point of the diagram is to see where everything falls, how many for each capability, where there is overlap and duplication etc.

[Glassboy]

Richard - for me the challenge is that we are using Archimate as well as UML.
From an Archimate perspective, there is no such thing as an instance (or alternatively an element is the instance depending on how you look at it).  The overhead and implications of creating children and generalisations make that quite messy, and breaks the model (in the sense that there are multiple things representing the same thing).

That's a strange thing to say about ArchiMate.  Firstly because it doesn't have the generalisation relationship, but from a wider perspective the most practical way of modelling some architectures is to create an archetype and have elements that realise it.

[Paolo F Cantoni]

[SNIP]
That's a strange thing to say about ArchiMate.  Firstly because it doesn't have the generalisation relationship, but from a wider perspective the most practical way of modelling some architectures is to create an archetype and have elements that realise it.

GB, it's a bit more complicated than that (and perhaps goes to your often voiced criticism of ArchiMate).  ArchiMate HAS a specialization relationship and (somewhat unthinkingly) I assumed Specialization => inverse Generalization.  Indeed we have so defined it in our MDG.  We, therefore, allow two forms of Specialization:  Inheritance and Restriction.

But (looking again), the Archimate 3.0 standard says:
5.4.1 Specialization Relationship
The specialization relationship indicates that an element is a particular kind of another element.
The specialization relationship has been inspired by the generalization relationship in UML class
diagrams but is applicable to specialize a wider range of concepts. The specialization
relationship can relate any instance of a concept with another instance of the same concept.
A specialization relationship is always allowed between two instances of the same element.
(my emphasis)
It looks as though the definition is our restriction, not inheritance.  Is that your reading?

Paolo

[Richard Freggi]

Mixing Archimate and UML IN THE SAME MODEL is not a good idea IMHO.  Each has its place, but their metamodels don't play nice together, so.... good luck???

Richard - for me the challenge is that we are using Archimate as well as UML.
From an Archimate perspective, there is no such thing as an instance (or alternatively an element is the instance depending on how you look at it).  The overhead and implications of creating children and generalisations make that quite messy, and breaks the model (in the sense that there are multiple things representing the same thing).

To be clear, I am sympathetic to the argument that whilst putting multiple elements on a diagram to handle layout challenges would be convenient, it's also a bit of a cop-out. However we have use cases where we genuinely need to represent the same element multiple times on Archimate diagrams due to the inherent structure of the type of diagram.  One example is 'box in box' diagrams of a hierarchy, with overlays of a different concept.  For example - a Capability Map (box in box) with an overlay of applications, projects, strategies etc  Usually the overlaid concept has elements associated with multiple capabilities, so needs to appear multiple times; the entire point of the diagram is to see where everything falls, how many for each capability, where there is overlap and duplication etc.

[Glassboy]

It looks as though the definition is our restriction, not inheritance.  Is that your reading?

Well I think you have to be careful to compare apples with apples.  ArchiMate is a notation and UML is a language.  In UML it's useful to talk about the language concepts and abstractions in a theoretical way.  With ArchiMate if you can't produce a viewpoint that conveys the same information to every viewer with symantec consistency you're just wasting everyone's time.

I can't think of a time where I wanted the same element on a view twice because mostly I either have the archetype view, the realised view, or ArchiMate just can't inherently produce the view I need*.

My reading of the ArchiMate specialisation is that it is a kludge and that you're applying more rigour to it than the ArchiMate authors.

* For example how do you show what a product is used for (and no this is not any of the motivation elements).

[Paolo F Cantoni]

It looks as though the definition is our restriction, not inheritance.  Is that your reading?

Well I think you have to be careful to compare apples with apples.  ArchiMate is a notation and UML is a language.

Surely a notation is a language or at least a rendering of a language?

In UML it's useful to talk about the language concepts and abstractions in a theoretical way.  With ArchiMate if you can't produce a viewpoint that conveys the same information to every viewer with semantic consistency you're just wasting everyone's time.

Surely that's true of any graphical language?

I can't think of a time where I wanted the same element on a view twice because mostly I either have the archetype view, the realised view, or ArchiMate just can't inherently produce the view I need*.

Well, we produce our own viewpoints (as required) and one in particular uses visual grouping to indicate relationships (without seeing the relationships - similar to visual embedding) if we are showing the relationship between (say) business functions and the systems that serve them, where a system serves more than one business function then it needs to be shown in two places on the same diagram. We now manage this with VCEs.

My reading of the ArchiMate specialisation is that it is a kludge and that you're applying more rigour to it than the ArchiMate authors.

Rigour is your friend!

* For example how do you show what a product is used for (and no this is not any of the motivation elements).

In the case of our MDG, we have (tried to) constructed a graphical language which provides as much rigour as is necessary and whose notation is sufficiently "ArchiMate" like to allow our new architects to "come on board" with as little friction as we can muster given the "foibles" of EA.

Paolo

[matthew.james]

Mixing Archimate and UML IN THE SAME MODEL is not a good idea IMHO.  Each has its place, but their metamodels don't play nice together, so.... good luck???

Richard - I agree completely.  But the "IN THE SAME MODEL" are your words not mine.  We use both notations for different purposes within our practice - a fact which I mentioned only to clarify why we have difficulty with your initial proposal, which may (or may not) be appropriate for UML but is not effective for Archimate.

Richard - for me the challenge is that we are using Archimate as well as UML.
From an Archimate perspective, there is no such thing as an instance (or alternatively an element is the instance depending on how you look at it).  The overhead and implications of creating children and generalisations make that quite messy, and breaks the model (in the sense that there are multiple things representing the same thing).

That's a strange thing to say about ArchiMate.  Firstly because it doesn't have the generalisation relationship, but from a wider perspective the most practical way of modelling some architectures is to create an archetype and have elements that realise it.

Glassboy - I'm not sure from your comment what specifically you find strange ... ? The use of the work generalisation? I was couching my response in terms of Richard's suggestion which inherently relies on the concept of classes and instances (both supported explicitly by Sparx) which don't translate into Archimate; attempting to do so (using specialisation not generalisation as pointed out by Paolo) would be cumbersome at best.

I can't think of a time where I wanted the same element on a view twice because mostly I either have the archetype view, the realised view, or ArchiMate just can't inherently produce the view I need

... and Paolo and I have provided specific examples of when we have this need and which are completely valid Archimate, but which Sparc cannot produce.
(There are a vast plethora of features in Sparx that I have never used and likely will never need, just because I don't need them doesn't mean than no-one does)

[Glassboy]

That's a strange thing to say about ArchiMate.  Firstly because it doesn't have the generalisation relationship, but from a wider perspective the most practical way of modelling some architectures is to create an archetype and have elements that realise it.

Glassboy - I'm not sure from your comment what specifically you find strange ... ? The use of the work generalisation? I was couching my response in terms of Richard's suggestion which inherently relies on the concept of classes and instances (both supported explicitly by Sparx) which don't translate into Archimate; attempting to do so (using specialisation not generalisation as pointed out by Paolo) would be cumbersome at best.

It's like you don't bother to read what people reply to you with.

[Sunshine]

Mixing Archimate and UML IN THE SAME MODEL is not a good idea IMHO.  Each has its place, but their metamodels don't play nice together, so.... good luck???

Well we use both ArchiMate, UML and BPMN together in harmony in the same model for different levels of abstraction required in doing both Enterprise Architecture and Solution Architecture. There are a few papers on using these three notations together and its not rocket science.

[matthew.james]

It's like you don't bother to read what people reply to you with.

1) Communication is the responsibility of the communicator - if someone doesn't understand what you say, and so asks questions to clarify what you mean, then the fault is yours not theirs. If your response is going to simply be "you're not listening to me" then the value of discourse and the opportunity to really share knowledge is gone.

2) Pot. Kettle. Black.

[Glassboy]

It's like you don't bother to read what people reply to you with.

1) Communication is the responsibility of the communicator - if someone doesn't understand what you say, and so asks questions to clarify what you mean, then the fault is yours not theirs. If your response is going to simply be "you're not listening to me" then the value of discourse and the opportunity to really share knowledge is gone.

<sigh>  I'll repeat myself.

In ArchiMate the most practical method of modelling can be to model an archetype and then elements that realise the archetype.   

[matthew.james]

<sigh>  I'll repeat myself.

In ArchiMate the most practical method of modelling can be to model an archetype and then elements that realise the archetype.

Thank you for making the effort, and clarifying what specifically you found strange (I'll forgive the dramatics).
My interpretation of your comment is: even though there are not classes and instances in Archimate, the pattern of using an archetype with elements that realise that archetype can still be used. Hopefully that is the right interpretation, or close to right.

If I have understood your point then I certainly agree that it is a valid modelling pattern and can be used. Whether I have understood your point or not, I'd still assert that pattern isn't appropriate for all scenarios, and not for the specific ones that I have provided (in this thread and others);  and that there are genuine use cases for modelling when the most practical approach is to have the same element visualised on a diagram multiple times.

For a concrete example:
- I have an element, type Archimate Application Component, let's call it "SAP ERP" (in this sense "SAP ERP" is an instance of Application Component, but as stated earlier this is not useful in this context as the archimate meta-types aren't part of the model)
- This element realises (directly or indirectly) a number of Archimate Application Services, Business Processes, Business Services and Capabilities (again this is a different sense, these are not archetypes being realised)
- It so happens that "SAP ERP" realises multiple Capabilities and I wish to illustrate this in a diagram
- I could show "SAP ERP" and all the relevant Capabilities on a diagram with the connectors between them, however there are in fact multiple other Application Components i wish to show on the same view, so lots of arrows all over the place and no insights from the diagram
- Instead I choose to use block style (box in box) diagram of the Capabilities (Capability Map) and overlay all the Application Components on each of the relevant Capabilities they realise
- But I can't because I can only have one "SAP ERP" on the diagram.

Yes, I could create multiple Application Components, one for each of the Capabilities.  I could call each of them "SAP ERP" (or some variant), I could even establish a formal relationship between these and the 'real' "SAP ERP". Then I could place these all on the same diagram.  But these elements genuinely represent the same thing, their sole purpose is to make the diagram work - there is no value having them in the model.

[Sunshine]

I've had this problem of showing several instances of the same archimate element on one diagram.
Originally I created this script to create multiple diagram elements pointing to the same element.

Code: [Select]

option explicit
 
'!INC Local Scripts.EAConstants-VBScript
 
'
' Script Name: Add Element to Diagram
' Purpose: This adds the currently selected element to the currently visible diagram
' Date: 11/08/2010
'
 
sub main
       Dim currentElement as EA.Element
       Set currentElement = Repository.GetTreeSelectedObject
       Dim currentDiagram as EA.Diagram
       Set currentDiagram = Repository.GetCurrentDiagram
       Dim diagramID
      
       if ( currentDiagram is Nothing ) then
              Session.Output("No Current Diagram Selected")
       else
              Session.Output("Adding " & currentElement.Name & " to " & currentDiagram.Name)
              diagramID = currentDiagram.DiagramID
              Repository.SaveDiagram(diagramID)
              Dim currentDiagramObject as EA.DiagramObject
              set currentDiagramObject = currentDiagram.DiagramObjects.AddNew("l=10;r=130;t=10;b=82", "")
              currentDiagramObject.ElementID = currentElement.ElementID
              currentDiagramObject.Update
              currentDiagram.DiagramObjects.Refresh
              currentDiagram.Update
             
              Repository.CloseDiagram(diagramID)
              Repository.OpenDiagram(diagramID)
       end if
end sub
Initially that worked but after a few Sparx EA versions later it didn't work so well.
So now I have resorted to creating an instance of the ArchiMate element similar to a UML instance of a class. I had to create stereotypes with shapescript for the instance so it looked like the ArchiMate element. I put all the instances of the ArchiMate element under the original in the project explorer. Seems to work but kind of a hack.

[Graham_Moir]

<sigh>  I'll repeat myself.

In ArchiMate the most practical method of modelling can be to model an archetype and then elements that realise the archetype.

Thank you for making the effort, and clarifying what specifically you found strange (I'll forgive the dramatics).
My interpretation of your comment is: even though there are not classes and instances in Archimate, the pattern of using an archetype with elements that realise that archetype can still be used. Hopefully that is the right interpretation, or close to right.

If I have understood your point then I certainly agree that it is a valid modelling pattern and can be used. Whether I have understood your point or not, I'd still assert that pattern isn't appropriate for all scenarios, and not for the specific ones that I have provided (in this thread and others);  and that there are genuine use cases for modelling when the most practical approach is to have the same element visualised on a diagram multiple times.

For a concrete example:
- I have an element, type Archimate Application Component, let's call it "SAP ERP" (in this sense "SAP ERP" is an instance of Application Component, but as stated earlier this is not useful in this context as the archimate meta-types aren't part of the model)
- This element realises (directly or indirectly) a number of Archimate Application Services, Business Processes, Business Services and Capabilities (again this is a different sense, these are not archetypes being realised)
- It so happens that "SAP ERP" realises multiple Capabilities and I wish to illustrate this in a diagram
- I could show "SAP ERP" and all the relevant Capabilities on a diagram with the connectors between them, however there are in fact multiple other Application Components i wish to show on the same view, so lots of arrows all over the place and no insights from the diagram
- Instead I choose to use block style (box in box) diagram of the Capabilities (Capability Map) and overlay all the Application Components on each of the relevant Capabilities they realise
- But I can't because I can only have one "SAP ERP" on the diagram.

Yes, I could create multiple Application Components, one for each of the Capabilities.  I could call each of them "SAP ERP" (or some variant), I could even establish a formal relationship between these and the 'real' "SAP ERP". Then I could place these all on the same diagram.  But these elements genuinely represent the same thing, their sole purpose is to make the diagram work - there is no value having them in the model.

There is a workaround to this provided you are prepared to work bottom up and accept slightly more onerous maintenance and apply some extra structure to the project browser.

The approach is to create an individual capability-app component diagram for each capability and overlay the application components in the way you want on each of these diagrams.  Obviously this will work as you won't be trying to put an element on the same diagram twice. 

Then to present the consolidated diagram that you really want, create another diagram and insert/drag-drop the specific diagrams you've created as diagram frames.  Move them around to get the information where you want it.  This works quite well in my opinion, especially if you use the appearance options to remove the diagram frame borders.  The consolidated diagram then looks pretty much as if you've created it directly.  The consolidated diagram is also dynamic and so updates automatically should any of the lower level individual diagrams be changed. 

[Glassboy]

Yes, I could create multiple Application Components, one for each of the Capabilities.  I could call each of them "SAP ERP" (or some variant), I could even establish a formal relationship between these and the 'real' "SAP ERP". Then I could place these all on the same diagram.  But these elements genuinely represent the same thing, their sole purpose is to make the diagram work - there is no value having them in the model.

You don't have a model or element problem, you have a viewpoint problem which is fairly typical with ArchiMate.  It also sounds like you are creating the SAP ERP archetype but you want to mix it with other archetypes.

I'd suggest two things.  Firstly the larger view may satisfy a desire you have but may not be the best communication tool.  Secondly don't start at that point.  See if you can create a number of A4 landscape views of the major application components and the application services they serve.  Once you have those print them all out and see if you can add application collaboration elements in a way that make sense.

Then and only then jump up to your wacky strategy level capabilities.  You might find that your capability map might be better as a mapping of capability to application function, or to technology function if you are consuming web services.  It will also allow you to include missing functions that are not being provided but are needed for the organisation to have the capability.