Different representations of the same element?

[stevesavage]

Question: how are other people handling what are conceptually the same things in EA when you need to create a separate element for each diagram standard you want to work with.

Background: As we undertake project, we are building up a common catalog of elements for re-use, for example the organizations and roles that make up the business.  

At the moment I've created a shared catalog containing packages for each org/role and then different elements for each diagram standard I need to create.  e.g.

The package "Deputy Minister" contains elements called "Deputy Minister" with the following types/stereotypes:

• "Business Actor" element for using in Business UC diagrams, a
• "ArchMate_BusinessRole" element for Archimate diagrams,
• a "Class" element to use in Conceptual Models, and
• a "Lane" element to use in BPMN diagrams.

I've create a "sameAs"  stereotype to use with a traceability relationship, all the "alternate" versions traceTo the "class" version used in my Conceptual Models (contains the generic description of the org/role)

To make this less painful, I create an EAscript that given an element of type="Actor", automatically creates the package, and all the alternate versions if they don't already exist.  The "note" in the alternate contains a link to the "class" version of the element.

I'm doing this for traceability
For example, to generate reports that show what IM/IT solutions are used by a specific role or org.
Or to show what org or roles would be impacted by a change.

And clarity, to show that each version is the same thing.

[stevesavage]

What I'd love to have is the ability to have "shortcut/symbolic link" elements in EA.

If these "shortcut elements" also let me set the type, and stereotype and associated custom tags, but would otherwise be kept in sync with the target element (notes, name, other attributes), the previous process I described would no longer be needed.

This would also be useful for project management.  I'd be able to have the shortcuts listed in a project package, for readability, report generation, and usability (when creating diagrams for a project, I'd be able group shortcuts for the related elements in one spot)

[Paolo F Cantoni]

Hi Steve,

This is a common problem faced by enterprise scale modellers.

I've sent you an IM with some ideas on this issue.

Paolo

[Geert Bellekens]

Steve,

It is indeed natural to have different representation of the "same" element in you different (viewpoint) models.
I've put "same" between quotes because these thing are usually not completely the same thing.
Let's say I create a class Person in my Business Model (CIM) my Functional Analysis Model (PIM) my Technical Analysis Model (PSM) and my Data Model (PSM).
I would then have 4 classes in my repository all with the name Person.
They are however not really the same thing.
In each model I want to describe different aspects of this person concept.
This one Person in my Business Model could even lead to multiple classes in my Functional Model (to model details, versioning, whatever).

So what we do is we create all these elements in all the models (when we need it) and we use the <<trace>> relations to trace the concept between the different models.

Geert

[Paolo F Cantoni]

Hi Geert (and Steve),

You are absolutely correct that we often conflate what appear to be the same thing but actually aren't.  Over the last 12 months or so, I've come to a much better understanding of this separation - such as you are suggesting.

However, to a great extent (and here I'm putting words in your mouth Steve, so please correct or confirm) the example Steve has quoted is exactly wanting to provide different renderings of the same thing.  Indeed, he has entitled the topic in that way.

Steve wants the SAME classifier to be represented sometimes as a UML Actor, sometimes as a ArchiMate Business Role, other times as a BPMN Lane and sometimes as a UML Class.

This is a perfectly acceptable requirement and I've recently been grappling with how best to manage this.  You may recall qwerty and I exchanged some words on "doppelgangers".  I think this is more what Steve is talking about.

Paolo

[stevesavage]

Using the termed by Paolo:

My approach is:
I have a script that creates the typical doppelgangers for the element, links them with a "sameas" relationship, and syncs all the attributes and notes.   The controlling element is the "class" element I use in my conceptual models.

Select the control or a doppelganger, and re-run the script to re-synchronize the doppelgangers with the control (using the sameas relationship), if one of the doppelgangers has been modified since the last sync, show a warning (proceed yes/no).

This allows the user to manually merge changes from the doppelganger into the control element, then re-run the script.

[stevesavage]

Let's say I create a class Person in my Business Model (CIM) my Functional Analysis Model (PIM) my Technical Analysis Model (PSM) and my Data Model (PSM).
I would then have 4 classes in my repository all with the name Person.
They are however not really the same thing.

Hi Geert, I agree that they aren't always the same thing once you get in to the data model and technical models, but what I found in the business models, that they are often conceptually the same thing.

Example: I have a business role in an archimate diagram called "Reviewer", I have the same role represented by a Swimlane in a BPMN diagram, and again as a class for a conceptual diagram.

What I want to show in the model is that they all represent the same business entity.  What would be different is their relationships to other elements.

When I want to describe a role in a specific context/situation.  I found I use two approaches:

• The notes feature for relationships
• The notes for the diagram (view)

Again my main desire is for traceability, especially between roles and the business policies and rules that guide and constrain them.