Centralized repository capability in EA?

[cgarski]

I am new to EA and wondering if someone can advise me on whether it can be used by multiple project teams working on multiple systems over time, in a large IT organization, to build a library of system documentation.

I work in the PMO of a large IT shop that supports and enhance many systems, small and large, legacy and new.  Our legacy systems in particular are not very well-documented, and we pay the price for this with every new project.   We are moving toward adopting UML as a documentation notation in our shop, and I see this as an opportunity to address the problem by making sure our "new" UML-based documentation is stored centrally.

Rather than having project teams start by creating their EA "project", I would like them to be able to start by reviewing the existing current state documentation that has been built up over time by past project teams.  And at the end of each project, the future state system documentation that the team created would be stored centrally as the new current state.  In effect it is no longer "project documentation", it is now "system documentation".

Can EA be set up so that models and diagrams that have been created in the past can be easily located and reused?  Is there any capability for version control, checking-in, checking-out, that sort of thing?

Or is EA strictly a project-by-project tool, and any centralization and version control would have to be handled as a separate issue, outside of EA.

Thanks for any comments!

[sargasso]

Unfortunately, the overall answer to your question is yes and no.

I understand only too full well the problems you are facing.  So I'll just give you the benefit (?) of my experiences.

Rather than having project teams start by creating their EA "project", I would like them to be able to start by reviewing the existing current state documentation that has been built up over time by past project teams.  And at the end of each project, the future state system documentation that the team created would be stored centrally as the new current state.  In effect it is no longer "project documentation", it is now "system documentation".

I consider the model delivered at implementation to be part of the configurable system, that is, the model, the implemented code version, the source code and the system configuration data should all be stored as a single release.  All of these should be locked from change.  

Everytime a "point change" is made to one of these, say for a patch or a system config data change, the reference data (the model) as well as the operational data should be adjusted.   A modern VCS will provide the necessary lock control via check in check out but still wont ensure that maitenance programmers etc will update the model.  Cie la vie.

When a new release of a system is undertaken as a project, the entire suite should be  copied out and managed by the project team until implementation, whereupon it should be checked in in toto as a new release  after archiving the retired version.

That is, the project will need to use its' own VCS during the project.

This to my way of thinking is better than trying to use the model as a separate entity to the implemented part of the system.

Now EA, viewed from this point is an excellent tool.  It has fairly sophisticated VCS integration capability and functionality.

However, I have also found many instances of projects that involve the models from more than one system (or component).   And it is here that EA (and in fact all the other products I have used) falls down.  You cannot easily  integrate external "reference" models from other systems.  This usually means that each team tends to build up a different view and set of documentation for these, and over time  confusion and error creep in.  

But finally, having used about a dozen tools over the last decade I have to say that EA is the best by a country mile.

hth
Bruce

[cgarski]

Thank you for your advice.  We do have a third-party version control system in place that we could certainly use for managing changes to our UML models.  

If I'm understanding correctly, the challenge will be with projects that impact multiple systems (and most of ours do), in that "linking" models together is not something that EA handles well.

Would it be to our advantage then, to plan to minimize the number of separate .EAP files we have, perhaps structuring them along our lines of business rather than our mechanized systems?   In that scenario we'd have multiple projects (everything going on in one LOB) having to coordinate their changes to a single model, but at least the model would be a complete representation of the systems used within that LOB.  

Does that make sense, or am I missing something?

[sargasso]

Without prejudice!  (i.e. I haven't had the opportunity to try this   )

In this situation I'd look at  component based design processes and a strict architectural group having control over the inter-system flows and intrfaces.  Perhaps an enterprise, or LOB level, set of architectural models could provide the structure that would let individual system models contain te detail pertinent to them and leave the corporate cosmos undisturbed.

bruce

ops ... perhaps " an architecural group having strict control"...