cross-project "model libraries"

[eckmann]

The whitepaper "Version Control Best Practices for Enterprise Architect" has a note on the bottom of page 5: "Future updates to this whitepaper will also address the concept of distributing 'model libraries' – models that serve as self-contained components to be reused across several projects by any number of 'consumers'."

That sounds like exactly what we need: a way to partition subsystems into separate (and separately managed) projects.  But is it possible to "include" a "model library" project in another project, or create relationships between components across projects, or am I looking for something that doesn't even make sense in EA?

[Geert Bellekens]

No, it actually makes sense.
We sort of do the same here.
We have to main models (on SQL Server) that both share a Common "framework" model.
This framework model is version-controlled in TFS.
Whenever we check-in changes to the shared model from one of our models we do a get-latest in the other model to see the changes.

This is working pretty good for us so far.
Just be careful that you only create dependencies TO the framework model, and not FROM the framework to the "users".

Geert

[Uffe]

A structure with reference models is very simple to set up.

You have one master project for each such reference model, and distribute either XMI-exported packages, version-controlled packages or baselines to the various target projects (depending on your CM policy).
This is a good fit for things like company-wide standards, architectural guidelines, etc; models that are only used as references and not modified in the target projects. As long as you observe the connector-direction restriction Geert mentioned, you'll be fine.

Connectors both ways across projects (strictly speaking, across XMI file boundaries) will cause headaches, and there is no concept of "live" interchange between projects. Models must be exported/imported between projects in one of the ways mentioned above, and EA provides no automation to do it in the background.

A different approach is to separate your models into different projects and never move anything between them. You could for instance have one overview project, with detailed models for the individual systems in separate projects.
Hyperlinks can be added to relevant diagrams to provide navigation points between the projects.

There are two advantages to this approach. There are no synchronization issues, because no models are moved between projects. You can also restrict users' permissions in different projects, which you cannot do within one.
The disadvantage is that you need to run one EA session for each project.

Cheers,


/Uffe

[eckmann]

Thanks Geert and Uffe,

Either of the approaches you describe could work for us. We'll explore both.

Steve