Multi-Repository Environment

[Eamonn John Casey]

Hi!
I was wondering if anyone has come across a site that has multiple Repossitories? We are a large organisation With approximatly 17 EA shared Repositories.
The reason for this is to fin tune Security to stop users in one business unit from having too much knowledge about the inner workerings of systems in another.
We are using a mixture of ToGAF and ArchiMate to structure the content. Centerally we got a main Repository thta contains elements and models of interest to the entire organisation. Local business units get to decide Access to their own Repositories themselves.

Is there anyone that has some advice on how to make sharing and collaboration easier without affecting local Security?

Thanks,
Eamonn J.

[qwerty]

Unless you have a need for classification (that is some parts must be completely hidden for parts of the users) you can go by EA security. Working with Require User Lock to Edit lets you deal with multiple roots rather easy.

q.

[Uffe]

Hi Eamonn,


I have set up several such installations for clients in the past. Here are some general pointers.

The EA security model is essentially in two layers. There's access to a repository's underlying data store (file or database), then there's what's kown as "user security" on a per-repository basis.

The repository is the lowest level (finest granularity) where you can control access to information. In other words, if a certain OS user account has access to an EA repository they can read everything in it; it is not possible to restrict access to parts of a repository.

In addition, any EA repository access requires read and write permission in the underlying data store, whether that is a file or a database. This is because the EA client needs to be able to write information into certain tables even if the in-repository user account only has read access.

Since repositories can only be accessed fully or not at all, partial information sharing cannot be implemented by giving users different levels of access to a single repository. The only available alternative is to selectively distribute information from the repository. This can be achieved using XMI export / import, external version control, reusable assets, document generation, or HTML exports. Successful implementation of any of these strategies will require detailed knowledge of the model information content in order to correctly select what gets exported.

XMI export / import, external version control and reusable assets all give the option of model collaboration over repository boundaries, while document generation and HTML exports do not. However, if the key requirement is for information sharing, HTML exports in particular can be a quick way forward.

Of the collaboration options I usually recommend the reusable asset service. It adds a layer of security, which can be used to control access to reusable models, and it provides the ability to manage dependencies between models.


HTH,

/Uffe

[Geert Bellekens]

I have used a connection to a version control system in the past in order to share common parts the model across repositories.

That was before the concept of Reusable Asset Services existed, so that might replace the need for an external VC

Geert

[Uffe]

I have used a connection to a version control system in the past in order to share common parts the model across repositories.

That was before the concept of Reusable Asset Services existed, so that might replace the need for an external VC

It does, if model sharing is all you need. It also allows you to revert to previous versions of reusable models.

It does not have a built-in concept of branching, however. You can set it up to provide that, but it'll be pretty much hand-cranked.

And I do have one niggle: the set of permissions available in user security has not been updated to include permissions to control interaction with the reusable asset service. Using version control requires you to have certain permissions, but using the reusable asset service does not.

So as long as you have the proper access to the asset storage, you can upload ("register") assets from, and download ("import") them to, your repository. It is true that access restrictions are implemented at the server end, so each asset storage has one password for read-only and one for read-write access, but omitting permissions for this service leaves the user security model lopsided.

/U