1
General Board / How to hide Work In Progress in a shared model
« on: October 30, 2008, 07:56:36 pm »
I am working on trying to introduce EA into my organisation where we will have up to 200 analysts and designers working on various models - not all concurrently - approx 40 concurrent. I'd like to get some views on the proposed options - pitfalls etc.
The 2 options currently being considered for the deployment are
1) a shared model approach using SQL server + version control
2) a local model approach using EAP file + version control (in effect using the version control system as the master repository). Each user then gets the bit of the model (and its dependencies!) that they are interested in into their own locla workspace/model.
Any thoughts on the best option?
In terms of the models these will be representative of business processes and applications that support those processes. Over time various projects will come and go and be updating the models to move the business and its applications forward.
Before deciding on the most appropriate approach I have a specific question.
Specific questions:
1) Is there any way when using a shared model to hide work in progress from other users? This would mean we could get the benefits of managing, comparing and securing a shared model in SQL (local models seem a bit flaky at times) and allow users to work on the models before committing to the 'master'.
I realise I could export the packages I am interested in to a local EAP file but that seems like quite an overhead and then means each analyst is responsible for backup etc.
2) If we went down the shared model route what is a good configuration. All models in a single SQL database? - are there known size limits / issues etc.? There will be cross dependencies between model packages, typically at the service interfaces.
3) Does anyone have an example of code (C#/java)that uses the automation interface to export packages as XMI?
Thanks.
Andy
The 2 options currently being considered for the deployment are
1) a shared model approach using SQL server + version control
2) a local model approach using EAP file + version control (in effect using the version control system as the master repository). Each user then gets the bit of the model (and its dependencies!) that they are interested in into their own locla workspace/model.
Any thoughts on the best option?
In terms of the models these will be representative of business processes and applications that support those processes. Over time various projects will come and go and be updating the models to move the business and its applications forward.
Before deciding on the most appropriate approach I have a specific question.
Specific questions:
1) Is there any way when using a shared model to hide work in progress from other users? This would mean we could get the benefits of managing, comparing and securing a shared model in SQL (local models seem a bit flaky at times) and allow users to work on the models before committing to the 'master'.
I realise I could export the packages I am interested in to a local EAP file but that seems like quite an overhead and then means each analyst is responsible for backup etc.
2) If we went down the shared model route what is a good configuration. All models in a single SQL database? - are there known size limits / issues etc.? There will be cross dependencies between model packages, typically at the service interfaces.
3) Does anyone have an example of code (C#/java)that uses the automation interface to export packages as XMI?
Thanks.
Andy