Using EA for an Enterprise Repository

[BCGoitcwoodard]

Greetings!  I am the Data Architect for Baltimore County, Maryland, USA.  In launching a Data Architecture program, I first surveyed the market for a tool to use as a metadata repository.
We purchased licenses for Sparx EA Unified Edition.

I have a number of questions as I learn the tool..  and how to apply it in various situations.  I am running on several tracks at the same time...  which actually causes me to explore different EA perspectives, element types, etc.

I have created a number of projects and models, both locally and in an EA repository in Oracle.

My first question:  What is the recommended approach for managing enterprise models and project-specific (not necessarily EA projects) models?  Do you establish one central repository of all models, both an enterprise (i.e., integrated/concolidated) model of each type and the set of project models in progress, and then perform integration merges from project models into the enterprise models - all within the central repository?

  (From the EA documentation, it seems that "project" and "model" are used interchangeably.  I think I can see that multiple models can be contained within a single project. This would be the case with the implementation I describe above.  Is there a size issue or other issue with this implementation?)

I have not been able to get up to speed on model management and version control yet. 

Any comments or helpful links would be appreciated.

Thank you,
CCW

[Geert Bellekens]

Hi,

The first thing you'll want to do is switch to another database then Oracle.
Go for SQL Server or MySQL or even Postgres, but not for Oracle.

For some reason EA and Oracle just don't work well together. You might not notice it in the beginning, but the performance of EA will degrade to the point it becomes almost unusable.

Another thing I recommend is to model everything in the same big enterprise model.
Don't setup different islands that do their thing in their little corner, and are supposed to merge this back to the central repository.

That just doesn't work. Merging models is almost impossible and definitely very time consuming.

Geert

[BCGoitcwoodard]

Thank you, Geert.

1. We can probably migrate from Oracle to SQL Server.  Is that simple using the Project Transfer function?

2.  To use one big enterprise model --  How do you isolate different OIT projects (not EA projects ) from each other, promote reuse of elements/models from the enterprise model, and merge approved models/objects into the enterprise model in controlled stages?  Do you use a version control tool integrated with EA to manage concurrent work, checkin/out, model/element promotion, etc.?  (I need to study that...)

Thank you,
CCW

[qwerty]

1. Yes, that usually works without issues. Only if you have Windoze authentication set up you need to redo that after a transfer.

2. Many questions. Just regarding VC: it should be avoided in favor of using a central repo with Require User Lock to Edit (security setting). VC (my experience) just locks your work down in many cases. Only if you have remote teams there might be a reason to use VC. It's a complicated area and getting a consultant (Geert recommended) is a good thing to do.

q.

[BCGoitcwoodard]

Thanks, q. 

Re VC:  I will have to set up user security within EA, and learn about the functionality of Lock, etc...   Right now, my only point of reference for our needs are the ideas like branching, etc. used in source code management, which I am not an expert on.  So I will 1) see if we can set up EA on a SQL Server and transfer models, and 2) read more.

Trying to use EA for an enterprise metadata repository, I will have plenty of questions for all of you experts as it progresses.

Thanks again.
CCW

[qwerty]

No. A model is not code. This is a big misconception. You have local changes in code steming from clear instructions. Here you can branch and try out certain concepts. A model is to discuss and decide. These discussions can not be branched. Everyone would get mad on a branching discussion. You try to set a goal and see what implications it will have to reach it.

q.

[Paolo F Cantoni]

No. A model is not code. This is a big misconception. You have local changes in code stemming from clear instructions. Here you can branch and try out certain concepts. A model is to discuss and decide. These discussions can not be branched. Everyone would get mad on a branching discussion. You try to set a goal and see what implications it will have to reach it.

q.

(my emphasis)  Wot 'e sed!

Some have used VC, but my view is that you are better served with snapshots on an appropriate cadence.  Use the project transfer facility to create the snapshots.

A number of us have been maintaining enterprise-scale repositories for many years, so feel free to ask questions.  As Geert suggests, things may not be apparent at small scale and only show up later.  Getting off on a good footing will make life a lot easier.

Besides, the best mistakes to learn from are other peoples...

HTH,
Paolo (also a Data Architect)

[Uffe]

Everyone would get mad on a branching discussion.

AKA an internet forum.

When it comes to version management, it can work in a limited fashion but it is critical to understand that, as you say, models are not code.

I do think that reusable assets and baselines can be used to good effect both for model versioning and distribution, but you need to keep dependencies one-way. You must also understand that "model versioning" does not include branching.

With a RAS setup, you store versions of models as "reusable assets", which are then imported into various projects where they're used. You have to decide (and implement!) your own update policy to ensure there are no update conflicts -- basically, no asset may ever be updated from two different projects, you must keep ownership controlled.

The issue is complicated by the fact that there are aspects of model content which isn't modelled but configured per project as "reference data". RAS manages dependencies up to a point, and it can also store reference data, but I don't think it can manage model-to-refdata dependencies. Which really shouldn't be that hard to do, so if it's not in place maybe it will be included in a future release. Storing baselines directly in RAS is new in 15.1, so this is an area that is being actively worked on (or at least, it has recently been actively worked on).


/Uffe