Collaboration from multiple sites - best practices

[Bruno.Cossi]

Hi everyone,

I currently need to have a model updated from multiple (for simplicity's sake, let's assume 2) locations. The problem is that using a DBMS repository is out of the questions, mainly due to the performance issues. It seems that the replication is the way to go.
The problem is that both locations may need to change contents of the same package(s). And both locations need to see the changes made by the other one. And likely the only reasonable communication channel between the locations would be an e-mail.

Seems like regularly, one location would have to e-mail their EAP file to the other location, there the replicas would get synchronized, any conflicts resolved, and the replica sent back to the first location.

Does anyone have any better idea? This sounds like too much pain (although to be fair, not many tools would be able to handle this at all).

Thank you,
Bruno

[Matt]

Bruno,

how big a model are you talking?

XMI export with a tool like DiffDog (XML comparison tool from Altova) is workable.  We used this as a solution on one of the projects I was working on before.  Just try and keep the packages small and you will be fine.  It really falls over if you try and do the whole model in 1 go.

Just my input.

Regards,

Matt

[TrtnJohn]

Have you seen this white paper on EA site?

http://www.sparxsystems.com.au/WhitePapers/EA_Deployment.pdf

[Bruno.Cossi]

Hi Matt,

I expect the model to be rather small, probably just a few packages, a couple hundred elements at most in total.
Is there any advantage to using the XML as opposed to synchronizing the whole model file besides the size of the data we would need to move via e-mail? When you used the diff tool, what would you do with the reported differences?

Thanks,
Bruno

Bruno,

how big a model are you talking?

XMI export with a tool like DiffDog (XML comparison tool from Altova) is workable.  We used this as a solution on one of the projects I was working on before.  Just try and keep the packages small and you will be fine.  It really falls over if you try and do the whole model in 1 go.

Just my input.

Regards,

Matt

[Bruno.Cossi]

Hi John,

thank you, I read the paper a while back and just re-read it, but I do not think it provides an aswer to the situation I have described above.
I guess we will have to remove some of the constraints (e.g. the need for the same package to be modifiable from both locations).

Thanks!
Bruno

Have you seen this white paper on EA site?

http://www.sparxsystems.com.au/WhitePapers/EA_Deployment.pdf

[Paolo F Cantoni]

Hi Folks,

The reason why this topic is here is that Bruno and I discussed off-line the possibility of placing models on the User Group Site and making them available for download and (hopefully synchronisation).  This would allow a really collaborative approach.

One of the models we discussed is something I've developed which keeps track of anomalies and defects in EA.

I have a diagram that has a list of classes representing different parts of EA and when you select the class with the Maintenance window open you get the list of issues, defects etc associated with that thing...  That way, new (especially evaluating) users can quickly check if it's a known problem or something else.

What we want to know is...

Is it possible to place a master on a web site (such as the User Group).  Can each user have a local copy and regularly synchronise with the master?  What issues need to be considered?  What security might need to be thought through?  And so on...

Is anybody using EA across the web like this?  The White Paper hints at it, but has anybody actually done it?  On a daily basis, the amount of synchronisation information should be relatively small...

Paolo

[thomaskilian]

What I do is the following:
- I have a master stored in subversion
- persons working on the model have a replica and they know which parts are their own
- from time to time master and replica are synchronized and the master is checked in

The advantage is: simple use; works effectively. Disadvantage: works only with few people; inconsistent changes can easily happen if people don't work stringent.

[Evil_Genius]

One of the models we discussed is something I've developed which keeps track of anomalies and defects in EA.

I have a diagram that has a list of classes representing different parts of EA and when you select the class with the Maintenance window open you get the list of issues, defects etc associated with that thing...  That way, new (especially evaluating) users can quickly check if it's a known problem or something else.

Words fail me.

[Bruno.Cossi]

Why?  

Words fail me.

[Evil_Genius]

Why?  

Mr Cantoni may have his own motives for his one man crusade to criticize EA at every opportunity, but to record his criticisms in a shared repository for all to enjoy... Astonishing conceit!

[Bruno.Cossi]

Hi,

I think I will have to disagree. Nobody likes criticism to be sure (a client of mine just ripped through a document we worked on quite hard, so I know how it feels), however I would hardly say that Paolo is on a crusade to criticize EA at any cost.
It might seem that Paolo is nitpicking, but many of his observations make perfect sense to me. Believe it or not, when we run EA training our life would often be much easier had the consistency Paolo swears by been enforced throughout EA.
Enterprise Architect is a great product, I think that is one of the reasons why the forum here is so busy. Most of the users here (if not all) love EA and try to help to shape it into an even better product than it is.

The shared repository Paolo mentioned is meant to supplement the "Suggestions & Requests" section of this forum - somewhat better structured way for the users to record their issues/requests and to keep track of them.

If you go through the forum, you will see that there have been examples of great communal action, when several of the users would work together on identifying an issue or a requirement, coming up with a proposed solution and then submitting it to Sparx Systems. Thus, Sparx can get requirements they know the users care about, in enough detail that it can save them time and effort. That is what the shared repository should help us with.

I would think that is a good thing.

Bruno

Mr Cantoni may have his own motives for his one man crusade to criticize EA at every opportunity, but to record his criticisms in a shared repository for all to enjoy... Astonishing conceit!