One repository and multiple projects vs one repository per project

[diag]

Hi all,

We are going to create a new repository (DBMS) for EA 9. I would like to ask you what better approach is: one repository and multiple projects or one repository per project.

Our context is the following one. My department is planning to migrate our projects to Enterprise Architect (our current EA version is 12 Ultimate but an upgrade to 13.5 is scheduled). Our projects are large and complex and based on SysML. They can be grouped into operational projects and projects under-development. Additionally, there are elements that are common to all the projects, and therefore they should be shared between the different projects. After some time a project under development is moved from the under-development group to the operational group.

Each project is assigned to a different team. A team can only access to its project and to the common elements. All users are local.

We would like to use a database management system (DBMS) –specifically SQL server- to store the repository/repositories: (https://www.sparxsystems.com/enterprise_architect_user_guide/13.5/model_repository/upsizingtosqlserver.html).

Key points for us are:

• Integrity and preservation of the projects.
• Team working (concurrent access).
• Sharing elements between projects / Common elements.
• Version control / Baseline creation.
• Access rights for each project.
• Backup.
• Performance.
• Potential limitations (model size, database size, commit and merge limitations, etc…).

One repository in one database

What do you think that it is the best approach, one repository in one database for multiple projects or one database for each project?

Thank you very much.

[Geert Bellekens]

In almost all cases I've seen the single repository setup was to be preferred.
Just make sure you enable security with the option "Require user lock to edit". This will make the whole model read-only by default, which is usually enough to avoid accidental changes.

You can also add version control, but I would only do that if it is really worth the overhead.

In terms of performance the size of the database, or the number of concurrent users usually doesn't really matter that much. (Just don't use Oracle)

Geert

[diag]

In almost all cases I've seen the single repository setup was to be preferred.
Just make sure you enable security with the option "Require user lock to edit". This will make the whole model read-only by default, which is usually enough to avoid accidental changes.

You can also add version control, but I would only do that if it is really worth the overhead.

In terms of performance the size of the database, or the number of concurrent users usually doesn't really matter that much. (Just don't use Oracle)

Geert

Thanks, Geert.

We are going to use SQL server 2014 for creating the database for the repository.

Kind Regards

[Sunshine]

In agreement with Geert's advice. One repository with multiple projects in it is what we've found works for us too. We use SQL Server and found its been good. I have tried repositories using Oracle and had performance issues - the DBA's couldn't seem to fix those issues. 
In addition to using a single repository we use baselining to mark significant phases for each project.
Regarding security we create two sets of groups. The first gives users privileges to do things according to user experience. i.e. beginner, intermediate, advanced and administrator. The second is project groups which allow only project members to be able to edit the diagrams and elements in the project. We lock each project to a project group and add team members.
This works fine except on the odd occasion where a project is a "need to know" in which case we are forced to have a separate repository so no-one else can see it.

[Glassboy]

In almost all cases I've seen the single repository setup was to be preferred.

The case where it is not is if your organisation is going to perform a significant process re-engineering which might result in job losses.  In this case it is best to clone your process models into a new repository with access only given to those staff working on the re-engineering.  This also allows the what-if models to be flushed away when the modelling is over.

[Paolo F Cantoni]

In almost all cases I've seen the single repository setup was to be preferred.

The case where it is not is if your organisation is going to perform a significant process re-engineering which might result in job losses.  In this case, it is best to clone your process models into a new repository with access only given to those staff working on the re-engineering.  This also allows the what-if models to be flushed away when the modelling is over.

+1

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

Paolo

[Glassboy]

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

I still wouldn't use the same repository in that instance.  I've seen several instances of personal grievances claims made against an employer when staff felt they were not being consulted about restructuring.  If you keep the "pie in the sky" "what if" process modelling in a separate database to the "production" repository it is completely clear that the models are not in any official or approved.

[Paolo F Cantoni]

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

I still wouldn't use the same repository in that instance.  I've seen several instances of personal grievances claims made against an employer when staff felt they were not being consulted about restructuring.  If you keep the "pie in the sky" "what if" process modelling in a separate database to the "production" repository it is completely clear that the models are not in any official or approved.

Understand your point, but we use status and other codes and Sandboxes for that (blue sky stuff).  I'm not sure having separate repositories changes the semantics (nor would hold up in court).  It does, however, better ensure that if you can't get to it, you can't get to it.

Paolo

[Uffe]

Key points for us are:

• Access rights for each project.

That right there is the clincher. The only way to achieve that is multiple repositories.

It is important to understand that EA's security model is just fluff. It does not actually provide any security.

Actual security is provided by the underlying database, and every user account that accesses an EA project needs read and write privileges in the database -- even accounts without the Update Diagrams and Update Elements permissions.

This means that any user account with access to the database can access all the data in it, both for reading and writing, using raw SQL.

So if you have information security requirements that say that people should only have access to certain EA projects, the only way is to place those projects in different repositories and assign access rights to the user accounts accordingly.
If on the other hand you're not concerned with information security between projects but just want to ensure that team A doesn't make changes to team B's models, you can achieve that with EA's "security". Even with that though, read access applies to the whole project: it's only writing that's restricted.

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

It isn't, and you can't. The model introduced in v14 is strictly hierarchical, meaning you can't set one part of a project up to be visible to team A only, and another to team B only. If team A should not be able to read team B's area you can achieve that by giving team B higher privileges, but that means they will also be able to ream team A's area.

So that fell over right out of the gate, I'm sorry to say.


/Uffe

[Paolo F Cantoni]

[SNIP]

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

It isn't, and you can't. The model introduced in v14 is strictly hierarchical, meaning you can't set one part of a project up to be visible to team A only, and another to team B only. If team A should not be able to read team B's area you can achieve that by giving team B higher privileges, but that means they will also be able to ream team A's area.

So that fell over right out of the gate, I'm sorry to say.


/Uffe

Now that you remind me I think I came to the same conclusion (on reading the proposal).  I'll need to do more checking.  I'm sure the V14 security model is useful for someone.  Perhaps they could raise their hand?

Paolo
Paolo

[diag]

Hi all,

Thank you very for your comments. They are very useful.

We are are going to create two repositories in order to isolate operational projects from development projects. In this way, operational team and development team have different repositories. They are isolated at data-base level.

Every single project (operational project 1, operational project 2...) could be assigned to a sub-node of the root node (operational projects). Do you know if these sub-nodes requires a special property or just a standard package is enough?

The operational repository contains several operational projects (sub-nodes) and they can be read by the whole operational team. Nevertheless, we need to restrict the write rights creating user groups in EA 13.5 to only certain sub-nodes. In this way, a group of users can only write in a group of projects but they can read everything in the repository (user group 1 can write in project 1 and project 2, user group 2 can write into project 3 only, etc...). I think this second security layer can be done via EA v13.5 security functionalities: https://www.sparxsystems.com/enterprise_architect_user_guide/13.5/team_support/usersecurity.html. Is it correct?

Thanks for your comments.

Kind Regards

[PeterHeintz]

To your question regarding special properties:
You do not need special properties, standard packages are enough

The security functionality you refer to, is what you need (at least from my perspective)

[Glassboy]

Every single project (operational project 1, operational project 2...) could be assigned to a sub-node of the root node (operational projects). Do you know if these s

A standard package should be fine.  I also give everyone a sandpit area so they can play in a space easy to clean out.  Rather than having them trying different things inside a project where it can be very confusing to someone else later.

[diag]

Thank you very much for your feedback.

Kind Regards