Archi Forum

Hi All,

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 (http://forum.archimatetool.com/index.php?topic=438.0) 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).
  
• 
  Something else ?
  

Regards,

JB

Edited to add use-case comming from this post (http://forum.archimatetool.com/index.php?topic=438.0)

Hi JB,

First of all, all my best wishes for this new year 2018.

At work, I use the concept sharing for 2 main purposes:

• 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.

Hope this helps.

Best regards
Hervé

Hi Herve,

In turn, I wish you an happy new year!

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).

Regards,

JB

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 :)

Best regards
Hervé

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...

Kind regards,
Marc
[/list]

Hi JB,

From my experience in the past. This kind of functionality needs an repository to avoid indeed multiple open models or copying objects.

Other advantage of an repository is check-out, check-in, status management, etc becomes much easier.

The use case you describes are clear. You can also have External reference models(model from other companies, organizations) where you want to link to.



Jurgen

Hi,

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.

// Erik

I just found this thread and would like to add my vote for this capability.  The last update was July 2018 and I was wondering if this is being actively looked at.

I won't repeat much of what has already been stated other than to support it - I have rolled out Archi in my current client orgranisation's Architecture Practice fully using the Collab' and ServiceNow plugin, and the model has quickly grown.  The latest v4.5 has provided great performance improvements for large models, however there is still a need to segment the model into separate domains specific models, with the ability to cross-reference elements.

The ideal setup would be to have the following models:

• Org-Level Enterprise Model


• Strategy motivations (driver, goals, principles, capabilities)
• Enterprise target architecture
• Business Vertical Specific Models


• Vertical decomposed 'as-is' views
• In-flight projects that must align to the strategy as defined in enterprise model
• Projects motivation, business context, logical application, data models, integration, etc
• External linkage to the ServiceNow model for modelling technology layer as imported from SN
• Enterprise ServiceNow Imported Model


• Full import of SN CI as mapped in configuration
• Viewpoints created using JScript Generate Views scripts

As you can images a single model for all above is not sustainable and there is a real need to cross-reference models.

I hope this can be realised sooner rather than later.

Kind Regards,

Manjit

Hi Phil,

I was wondering if this request is even being looked at and on the roadmap.  If so any indicative timeline of it's availability?

Reason for wanting an update is that I need to know how to take forward the architecture modelling for my client.  Currently, we have the core model where Architects are collaborating on project based designs as well as maintaining the as-is views.  This model will is sizeable and will continue to grow.

A separate model in GIT was created for the ServiceNow import, which is of considerable size (32611 elements and 16100 relationships) and these numbers are a subset of what is in CMDB based on import config.  Ideally, we want to be able to link logical project views to the physical elements brought in from ServiceNow and would benefit from being able to externally reference another model.

I want to avoid importing the SN into the core model as this will make it a significant sized model and will suffer from performance issues, in Search, GIT operations, general scrolling of the Models tree, etc.  This has been evident in the current core model - I know that v4.6 looks to fix performance issues, but still would be good to understand if this capability will be realised.  Nesting another model will at least keep models separate but won't address performance issues when combined, but still worthwhile if this is a smaller implementation.

Thanks,
Manjit

Hi Manjit, no need to start another thread so I merged your post here.

Short quick answer - no I haven't looked at this issue, I've been busy with preparations for Archi 4.6 and other work. A lot of my time now is spent on simply making Archi work at all on latest OSs and Eclipse versions.

I guess we'll have to review this in the coming months.

Phil

Oic - I thought I had updated accidentally on this thread hence why I then modified my text.  A review in coming months sounds great to me.  In terms of you comment of working on 4.6 does Archi Linus installation work on ChromeOS - just a question from my organisation as they are looking to switch the G-Suite and replace Surface devices to Chromebooks (I know I should ask this on the Archi thread).

I don't know about Chromeboooks, but I suspect it won't work. See https://www.quora.com/Is-there-any-way-I-can-run-Java-Eclipse-on-my-Chromebook-so-that-it-s-just-like-the-Eclipse-environment-on-the-Windows-system-we-use-in-my-programming-class

Hello,

Currently, we have the issue. We chose your second solution :
- Copy/paste the concepts, objects needed (or CSV copy) then update the model with data from  the reference model.
The difficulty is that models are static and when the reference model changes, we have to update all models impacted, when needed. In fact, there is no automatic change required all the time: sometimes, it's good to have it, but sometimes no, because some models represent the "enterprise history", the legacy.
So if you develop a feature to support changes between a reference model (core model) and some local/operationnal model, please allow to disconnect some models from the core model.
In my opinion, it should not be mandatory to always stick to the core model.

Another use case :
- we model application component changes from business layer to technical layer. These models can become some core model for other models using the applications.

In my opinion, you can have 2 types of core model :
- a global core model with gobal concepts applicable by all modelers
- some limited core model used to model some concepts in detail: an application component, a business function, a technology (network, identity access management, azure or aws technical services....)

Thank you for sharing your thoughts.
Christine

Regards