Strategy for DBMS repository

[quentin]

Hi all,

I setup an EA environment based on EA Enterprise edition with a Microsoft SQL 2008 central repository.

I want to manage and share in the central repository the applications (+- 200 applications) documentation (I will call that as-built documentation) and also each project documentation (~ 300 projects/year).

As the EAP to DBMS import features scratch DB content each time and only import the content of the eap, I wondering what's the best approach to structure my DBMS repository.

My first idea was a unique model for all my company needs. But with regards to the behaviour of the import utility I consider revising my position.

Is another approach is more suitable like:

• 1 database per application with 1 application model (+- 200 Databases)
• 1 database per project with 1 model per project impact 1 or many application

This second approach if implemented will result to hundreds and hundreds of database. This will be unmanageable after 2 years regards access rights, storage, archiving, ...

So is anyone has ideas how to tackle complexity of multiple applications and multiple projects stored in EA DBMS repository.

Or Is there any resources on the web or white papers discussing strategies, approach or solutions for structuring EA repository to Enterprise needs and methodology?

Best regards
Quentin

[OpenIT Solutions]

Hi,

The easiest approach is to have a single model. In which you create a library of applications and an associated current state architecture. You then create a View called Project Architecture, in which you create a folder for each project (ideally it would have a common sub folder structure). In the projects folder you model using "Instances" of your Application components. When a project goes live you *manually* roll the changes into you current state architecture.

Regards,

Jon.