Tips on collaborative MDG development?

[PeteC]

I have been developing an MDG. Does anyone do that collaboratively with colleagues? If so are there any tips on how the process is managed?

Obviously it is possible for multiple people to jointly edit the model from which the MDG is built, but at the time either hits the generate MDG button then the work of all the updates gets built. I would envisage each person working on different tasks; as one person is working they will want to build the MDG to test what they have been doing, but at the same time they might get half done bits of work from someone else. I guess that if tasks are truly independent then it doesn't matter, but there could be bits of the MDG that are shared. Once it is at a stage to release to users, there would need to be an agreement that all development is finished and the design is ready to build.

I'm interested in how that MDG generation/testing is handled, even if it is a "never had an issue".

[Geert Bellekens]

A couple of hints:

- Use version control to manage your MDG files (generated xml files, but also icon files etc..)
- Make sure everyone maps the version control workspace to the same path (e.g. H:\VC\MDG) because EA uses absolute paths to link images in stereotypes
- Use version control and/or security locking (Require user lock to edit) on a central database repository
- Communicate!

Geert

[qwerty]

The issue with MDG development is development. You have lots of stakeholders (usually) and they are never happy to see their basis being changed. Depending on your CM you might have individual repositories each with a different MDG version (over time). Getting these to synch is a PITA. Also if you make certain changes you will need a script to migrate from one MDG version to the next. Finally (there is much more but I have to do other things ;-) you have no idea about which MDG version was used in a repo unless you make certain clever precautions (hint: there is no silver bullet or at least we did not find one).

q.

[Geert Bellekens]

My solution to that problem is "central control"

I'm the MDG developer, and if I release an MDG version to production, then all repositories will be updated.
No "if's" and no "but's"

Geert

[timoc]

A couple of hints:

- Use version control to manage your MDG files (generated xml files, but also icon files etc..)
- Make sure everyone maps the version control workspace to the same path (e.g. H:\VC\MDG) because EA uses absolute paths to link images in stereotypes
- Use version control and/or security locking (Require user lock to edit) on a central database repository
- Communicate!

Geert

Can you use a central/shared Team Library for this?

[qwerty]

My solution to that problem is "central control"

I'm the MDG developer, and if I release an MDG version to production, then all repositories will be updated.
No "if's" and no "but's"

Geert

My customer was very (!) special with that. We had lots of different releases out in the company. Some of the local majesties were not fond of changes. Even less to cope with the consequences they introduced. It was always the architect group to be blamed. (Honestly I was only a little cog wheel and would have taken your position if it had been possible. Well...)

q.

[Sunshine]

As you've probably experienced MDG development isn't straight forward and there are lots of bear pits to fall into. It's difficult enough developing MDGs alone without the complexity of others messing it up, so my advice is don't develop collaboratively. By all means consult with others when developing the MDG but don't allow others to develop the MDG.
In the last 20 years I've experienced too many people mess up models that have caused so much pain trying to fix. I wouldn't let anyone near an MDG I was developing knowing all too well it would end in tears.

[PeteC]

Thanks for all the suggestions to help not mess up the MDG development. We want one or two (so not loads more people to get it all messed up hopefully) to help out and remove the single point of failure.
Was timoc's Team Library suggestion intended as a way of team communication? I've never used that feature but it doesn't seem to address any other issue.

[qwerty]

I never recommend that (marketing) feature. People use other means of communication they are used to. If they do...

q.

[timoc]

Thanks for all the suggestions to help not mess up the MDG development. We want one or two (so not loads more people to get it all messed up hopefully) to help out and remove the single point of failure.
Was timoc's Team Library suggestion intended as a way of team communication? I've never used that feature but it doesn't seem to address any other issue.

Team Library is a part of a model database that can be 'shared', with others working on other model databases. The Team Library seems to have been created with a specific idea about how teams should communicate, share information, etc. with a detailed review/team-support workflow in mind.  It essentially allows you embed 'assets' with documents in a document tree. Where an asset can be a package an element, other resources that can be exported via XMI. This tree can be 'shared' with other model databases. Shared in this case means that it is available and editable while working in other model databases, and so can be used to share packages like a poor mans version control. Think of it like a kind of wiki+model pastebin? The manual seems to imply the documents are supposed to be some kind of team forum or something, i am not sure why.

The upshot is, if it is an asset that can be exported via XMI or 'cut and paste' to another model, then you can store it as a Resource alongside a document in the Team library. It is a nice feature if you are not using a central modelling database, a RAS or version control.

Anyway, my experience with Team library since EA 12, is that it has not seen alot of love since it was created. The implementation seems to rely on a cached index or something, and i have had to go back to backups in the past to recover library information. It seems a bit wobbly in EA16 with qeax files (bug submitted), but YMMV.

As a side note: Like pretty much everything else in EA (not just 'marketing features') the manual describes all of the menu options and what each option does. The manual assumes you know why it was designed the way it was, how and who it was designed to support, how it links to other features (associated report templates, calendar features, journals etc.). I am sure there are well defined user roles, use cases, review workflows etc. somewhere, but they are not in the manual. Users are essentially forced to bend the underlying design to fit their needs, re-implement 'out of the box' reports, possibly relying on edge cases or unintended features to support your reverse-engineered re-interpretation of the Team Library feature.

Meaning: the wobbly nature of EA16 may be due to my misusing Team Library in some way