For several reasons, I'm trying to figure out what the best solution is regarding concept/model sharing, ie: using concepts from another model in a view. I'd like to discuss the ideal feature set before going into the technical solution itself.

I know that Herve's DB plugin allow this in different ways, so feedback from people using his plugin is welcome.

FWIW, I personally see several, slightly different use-cases. Let's say that MyModel is the model in which I want to create a new view, and RefModel is a model that contains concepts (and maybe views too) that I'd like to reference in my new view:

One way is to just reference concepts from RefModel into the new view. Drawback: I need a way to open all needed RefModels when I open MyModel, and this will fail if referenced concepts have been deleted from RefModel. Last point can be somewhat mitigated if there's a way to reference a specific version of RefModel (which can be plugin dependant or simply a copy of the needed .archimate file).

Another way is to first copy needed concepts from RefModel into MyModel and then work "locally" inside MyModel. This can be done using a CSV export from RefModel followed by a CSV import into MyModel. This allow later synchronization that will update existing concepts, add new ones, but will leave removed one. This is safer that the previous option. Drawback: this is not as simple as: open a both models and work with them. Not being able to detect that concepts have been removed from RefModel can be an issue in some cases. What about views themselves: one could want to also import/reference some views from RefModel into MyModel.

This Post discuss a related use-case: There are some cases where people have to collaborate on a model without having full access on it. In such case, being able to reference concepts from RefModel, and then merge MyModel into RefModel is a typical workflow. Maybe this widen the scope to model merge (which is possible using CSV export/import with big exception of views).

Modeling infrastructure concepts (like virtualization farms, storage clusters, datacenters, etc... that need to be common to all the other models. Every change done on one of those concepts need to be visible in all the models that use this concept.

Modeling relationships between models. I organised my models per project (one application per project) and need to model relationships between those projects and between applications modeled inside those projects.

Of course, this is needed when people from my teamwork inside Archi during modeling, but when I communicate through the website generated by Archi where I do not want to have separate concepts even when used in several projects (thus in several models).

And you're right when you talk about versions. My database plugin does work with versioned concepts. When importing a model, it is therefore possible to import linked concepts: - as it was when modeling the model (version stored in the database) - as it is now (the latest version stored in the database) - or whatever version in the past.

Your point #1 is the typical use-case I had in mind. From your experience, how often do you face "conflicting" changes (deleted concepts used in other models) ?

Re point #2: why did you choose this solution instead of on "big" model that would contain all applications ?

Re your DB plugin: from your experience which of the 3 options (old version, latest version, other version) is the most frequent, and why?

To provide a little bit more background: I'd like to find a nice and elegant way to manage this by default in Archi (independently of DB or Collaboration plugins). So I'm trying to find the minimal but best feature set (KISS principle).

I do not need this feature at the moment as shared concepts model infrastructure components that may change are not removed.

So my plugin does not manage (yet) deleted concepts. I planned to never physically delete a concept in the database, but to manage logical delete (the "deleted" column is present in the database but not yet used).

What I planned to do in a future version is that when the plugin imports a model that contains deleted concepts (i.e. concepts that have a non empty "deleted" column) is to open a popup that lists the deleted concepts and give the user a choice: 1. show up the model as it was before the concepts were deleted, so import the model with the deleted concepts 2. import the model without the deleted concepts

Of course, deleting an element would also delete in cascade all the relationships to and from this element. This is the easy part.

I am facing 2 issues here: - If the user choose to import the deleted concepts, I then would like o be able to see in Archi that the concepts are deleted (like a trash icon or a red font) - I need to provide an "undelete" feature: undelete for the current model only (i.e. just changing the concept ID so this would become a new concept as far as the database is concerned) or undelete for all models (i.e. remove the "undelete" flag in the database"

I preferred this solution (one model per project with shared concepts) because it is easier for people to manage their own model and pickup what they need from a common repository.

But I know another company that did the opposite choice: they all work on a single repository. Each architect has got its own sets of folders and they've got their common concepts in a common folder.

At the moment, this situation is not comfortable for them because my plugin is an export/import plugin, not a collaboration plugin. I mean that when several people work on the same model at the same time. my plugin raises too many conflicts. I am working on an update that will mix export and import. I mean that when user A will export its changes to the database, the plugin will automatically import changes done by user B and conflicts will be raised only when the same concept is changed by both users (not sure I make myself clear here).

#2: From the REX I've got from some users, the latest version is used most of the time. Personally, I use old version of models for reference (see the evolution of an application for instance). I only used once the replacement of a concept by an older version from the database.

You are right when you state that it may be very simple. I humbly admit that my plugin is quite complex, because it is an export/import plugin and because of my lack of knowledge about the Eclipse framework.

To hide this complexity, I started to work on the version 3.0 of my database plugin that will not be an export/import plugin but a a real time collaboration plugin. Of course, it will require some network bandwidth but every change done on a concept will be seen real time by all other people having the same concept in there model.

Of course, from a technical point of view, all concepts will continue to be versioned but I was thinking to hide the version behind a timeline so users won't need to compare the concept to version x but compare with how it was x days/weeks/month ago.

I had a look to the CDO Eclipse framework but it is far too complicated for my little knowledge (and I cannot find working tutorial) and is not real time. So I will develop my own framework.

Please do not hesitate to tell me if you wish that we discuss this by phone or we may have lunch together one day as we did once

It appears there are several people on this forum requesting the same thing - being able to re-use concepts from other, external models in their own models. If I understand the RfC correctly, it is not as much a question of IF this should be done, but rather HOW it should be done, true?

If so, at first there's the matter of which way to go about it. It seems that there's a lot of demand for 're-use from another model', but we should also consider the possibility of 'one big model', wherethere are authorizations on different parts of the model. In the end, I think both methods are equivalent in support for functionality. Archi however has no notion of 'user', let alone user authorization, let alone authorization on a part of a model, so I think this would be quite a challenge to create.

So concentrating on 're-use from another model', there's also two ways to go about it, this can be seen in the two bullets in the first post and also in the database plugin by Hervé: copy-by-reference and copy-by-value. These behave in a different way and both have their merits, and I think the user should be presented with the choice (as is done in the database plugin). The challenge now is to make Archi behave predictably for the user: what will the model containing re-used concepts look like in different circumstances.

My proposal for this behaviour:

'Copy by reference'. MyModel only contains a pointer to the concept in RefModel. This means, RefModel needs to be open in Archi AND RefModel needs to contain the concept that MyModel refers to. If this is the case, the user can (implicitely, explicitely) refresh the concepts in MyModel and all will be well. What if RefModel is not open? Well. Remember the ugly markings in Word, if a reference in the text could not be resolved? You get the picture.

If the model is not open, Archi could detect this and tell the user. The desired action for the user is simple, (re-) open RefModel (Archi helps here, keeps the models open until you close them explicitely).

If the model is open and the concept is no longer there, now that is where things become interesting. The author of RefModel evidently had a reason to remove the concept. The author of MyModel should now make a conscious decision: remove the reference in MyModel, replace it with a new concept in RefModel or - three cheers for the collaboration plugin - retrieve a previous version of RefModel and refer to the concept in *that* model. I would argue against the copy-by-reference support somehow retrieving previous versions, as the user already has all the options she needs to resolve the situation.

This behaviour can be softened if Archi could somehow provide a kind of 'cache' of the properties of a re-used concept, so it remains useable (it would be a bit like a copied-by-value concept).

'Copy by value'. MyModel contains a fresh copy of the concept as it was in RefModel, including all its properties (but without its relations? Or only the relations to the concepts that are also present in MyModel?). MyModel remains standalone and the life cycles of the concept in MyModel and RefModel are independent. If the concept is removed or modified in RefModel, the author or the readers of MyModel are not alerted. Could this behaviour be softened? Archi could add a reference to the original concept in the copied-by-value concept, so that a explicit refresh action could still be made available to the user (making this behaviour a bit like copy-by-reference).

For both types of re-used concepts, I think it is ok if they are flattened to regular concepts upon export to Open Exchange format.

Incidentally, I would argue that re-used concepts in MyModel always get their own GUIDs, if only to keep supporting the notion that a GUID is unique. For example, we publish all our models to a single wiki; if two models contain an element with the samen GUID one of them will surely be a victim...

I am in general a friend of non-online-repository tools. Living on the country side and with a significant part of my focus time during commuting I'd like to have things working offline.

Therefore; For the mechanism I would suggest a cached reference.

When the element is linked from the source model to the target model a reference is made with cached copy. This is used for proper display if the source mode is not available. If the source is available the cache will be updated. If the source is opened and the element is lost, one might have the option to recreate it from the cache or at least know what is missing to find another element to use instead. Perhaps there shall be a function to list all cached objects and when they where last updated.

In general there is then no need to have the source models open during general work. The cached copy works and can be used.

Before a model with links to other models is frozen/set in sharp revision/sent to management or what ever, all linked source models need to be opened to get things synchronized. I recall this is (or used to be) how Excel solves it; if a Excel sheet uses information from another that is unavailable it screams and uses the last know information.