Auto creation of a composition with ArchiMate

[MatthiasVDE]

Does EA has a feature that automatically creates a composition if you drag an ArchiMate element into another ArchiMate element?
E.g. a business process into a business proces.

Thanks,

Matthias

[Geert Bellekens]

No, it doesn't.
You'll have to write a little script or add-in if you want to do that.

Geert

[MatthiasVDE]

No, it doesn't.
You'll have to write a little script or add-in if you want to do that.

Geert

I remember that there was something like 'make composite' in a previous version, or am I wrong?

[Geert Bellekens]

That is to the feature to link a "composite diagram" to an element -> drill-down.
Not related to composition relations.

Geert

[Sunshine]

Does EA has a feature that automatically creates a composition if you drag an ArchiMate element into another ArchiMate element?
E.g. a business process into a business proces.
...

Geert is correct if you want to create a composition relationship you need to create a script.

There is a feature that puts the element under the parent in the project explorer creating a parent child relationship when you drag it onto the parent in the diagram. Its not the same thing but it least it structures the elements in the model.
Not sure if this enable by default but its under the options for diagrams somewhere. If memory serves its called "Support for Composite Objects".
You could then write a script to go through the nested elements to add the composition relationship to reflect the parent child relationships. By putting the script in the project explorer folder it will be available via the UI.

This is the thing though, do you want to duplicate the structure parent-child relationship as a composition as you clearly aren't using it in the diagram by the fact you wanting to creating by dropping the business process within another business process. When are you going to use that composite relationship?

Myself, I just use the parent-child relationship in structure of the model for my ArchiMate models without duplicating a composite relationship. Diagrammatically I show this as process within a process so there is no need for the composite relationship in that case.

[matthew.james]

There is a feature that puts the element under the parent in the project explorer creating a parent child relationship when you drag it onto the parent in the diagram. Its not the same thing but it least it structures the elements in the model.

... just keep in mind that this only applies to elements in the same package and has no equivalent for elements in different packages.

[Sunshine]

... just keep in mind that this only applies to elements in the same package and has no equivalent for elements in different packages.

Elements in a different package aye? Shouldn't that be an aggregation relationship you want not composition?

[Geert Bellekens]

In fact I'm not inclined to use the project browser nesting all to much, mostly for pragmatical reasons.

One of main reasons is version control and model security.

Version control only works on package level.
If I were to put all the business processes of my entire enterprise under one root process, all of them would be controlled in a single version control file.
That means that there would only be one person at a time who could work on the business processes.

Same story more or less with security.

Another reason to use explicit composition relations is that you also see them when you add two related elements on a diagram.
The project browser ownership/nesting relation is implicit and not visible on diagrams.
And it is all to easy to move an element up or down the tree by mistake. If you are using only te ownership/nesting relation you might not even know you changed something crucial to your model.

Geert

[Sunshine]

Good points Geert - I agree.

Honestly never heard of anyone being silly enough to have one root process - that is just plain stupid. What would they call it anyway? "Just Do It"?

Just to provide some clarity, I group the enterprise processes using packages, ArchiMate and BPMN elements following the APQC structure. Generally Something like this ;
Package <Category>
   Package <Group>
       Process <ArchiMate Process>
          Activity <BPMN Activity>

There will be diagrams under each level. Highlevel views using ArchiMate and low level ones using BPMN. Occasionally I'll group processes within processes using ArchiMate to deal with some really complex processes but generally I avoid this by using those other grouping mechanisms.
It seems to work okay for my organisation without the need to use composition. But appreciate others model differently and will have a need for composition.

[Glassboy]

Honestly never heard of anyone being silly enough to have one root process - that is just plain stupid. What would they call it anyway? "Just Do It"?

If you'd said "Let's do this" you would have achieved some extremely funny political satire quite inappropriate for a civil servant :-)

[matthew.james]

Elements in a different package aye? Shouldn't that be an aggregation relationship you want not composition?

My intent was to make people aware of the general restriction of this feature (ie that it only applies to elements within the same package)

However, specifically for the case of Archimate and Composition, it's going to depend on how you choose to structure your packages.  For example, if you choose to package your elements by type / stereotype then there are multiple valid scenarios in Archimate for a Composition relationship between different types and therefore across different packages, e.g. Business Process and Business Function.

So aye, elements in different packages with Composition as well as Aggregation :-)

[Paolo F Cantoni]

Make sure there's no confusion between formal nesting and meronymy.  Search for "visual embedding nesting" to see some clarifications on what may be needed.  Particularly, see Re: Advice - to nest or to compose? reply #7.

My U$0.05

Paolo