mapping to Reference Models

[Neil Henderson]

I want to have 2 separate models, one containing a Solution Architecture, the other containing Reference Models (Business and Services) of our organisation.
How can one relate elements in one model with elements in another? Can this be done in Sparx EA?
Thanks

[beginner]

Not easy. Elements have a GUID which can be used to map models to each other. We used that in parts. Packages out of our reference are exported via XMI and imported in refactored models. Later you can use model compare to merge changes in the references model (re-export, compare to XMI).

However, this sounds easier than it is in reality. The model merge implemented in EA is not really useable¹. So we merge by moving parts around to transfer packages and importing these to replace old stuff. It's a tedious work but we haven't found an easier solution.

b.

¹The problem is that if you add elements you also have relations and occurrences in diagrams. Each results in a single change which needs to be merged separately. There is no way to say: Add everything related to an element. So it's a lot clickediclack...

[Geert Bellekens]

Neil,

We have a similar setup.
We have a reference data model that is used by two projects/databases.
(things like nationality codes, civil status, ...)
For this reference data I've setup version control integration.
The shared model is integrated in both projects.

This works pretty good if you make absolutely sure that there are only dependencies from the using projects to the reference data model.
Depencies the other way around would be wrong, and those dependencies would be lost when the ref data model is changed in the other project.

We only have a limited number of 'senior' users who have the ability to checkout the refdata model and make adjustments.

So in case you are sure that the dependencies always go from the Solution Architecture model to the Reference Model you can use this technique.

Geert

[Neil Henderson]

Hi Geert,
    How do I use EA to create the reference between the two models - is there a 'relationship' button somewhere?
   I am very new to this product and am stumbling through getting started :-/
 
    Neil

[Geert Bellekens]

Neil,

If you have both models into one repository as I suggested you can just use the elements from the reference model in your solution architecture model.
You can use them as types in attributes/parameter, and target in associations, dependencies,... as long as you make sure the solution architecture elements depend on the reference models elements, and not the other way around.

Geert

[RoyC]

Sorry Geert - you might have to be more precise in describing your set up. Can you distinguish between projects, databases and models?

It sounds to me as if you have a project on database A and a project on database B, and each project contains a Solution Architecture model plus a [copy of the] reference model. I don't think that Neil is concerned (yet) about the security and version control of the reference data model.

Looking at the question that Neil asked in his original post, if the project contains two models (which is quite common), there is little difficulty in creating relationships between elements and objects in one model and objects in the other. Your last post seems to discuss that. The Relationship Matrix might be the easiest tool to do that.

If you are saying that the Reference Model lives in another project (on another database?) then things are more complicated as beginner suggests. In that case ... carry on, Sar'nt Major.

[Geert Bellekens]

Hi Roy,

I'll try to define the terms as I've used them:
Model: Root element in EA (sort of like a package, but not quite)
Repository: a database containing one or more models
Project: see Repository
Database: see repository

As I understood the initial problem is that Neil currently has two repositories, each of them containing a single model. And now he wants to use (relate to) one model in the other model.
Another assumption is that the "reference model" is likely to be used by multiple "solution" models (maybe not currently, but in the future...).
And for various organisational reasons there is a chance that the various "solution models" will end up in seperate repositories, while still using the same "reference model".

So under these circumstances, sharing the "reference" model as a version controlled model in the various "solution" repositories can be the best solution.

Geert

[beginner]

Hmm. The other team working with EA at my current customer is using this version control approach. They had major issues with that as "Get All Latest" severely clobbered their database so they had to use the backup. If everybody know exactly (!) what's going on during such checkout/in I think it's okay. But most of the modelers don't care. Because they weren't told and even if, they should not be confused by such CM stuff. From my point of view the multi-user potential of EA is very little. I don't blame it for that since having it function in a smooth way evolves an enormous effort in design and development of EA which I would not will to pay.

CM needs to be designed individually for each situation. If a tool supports it in parts that's nice. But definitely there is no One-Fits-All solution!

Just may few cents.

b.