EA use for a large Corporate Archietcture project

[bsidhu]

Hello EA users,

Our organization is going through a corporate optimization effort and we are documenting our business processes, business goals, infrastructure, data entities, system designs (from Analysis models down to detailed designs for new systems).

It is my responsibility to figure out a mechanism to store all of this information in an easily accessible and referenceable manner.  Tools like Troux (http://www.troux.com) cost a lot and are not necessarily the best solution.  I like EA and here is what I plan to do:

Create one EA project with two root level models - Corporate and Projects.  Corporate root model contains corporate wide business processes, business goals, data entities, actors etc under an easy to navigate tree structure.  Only few senior company members will have modify access to this.

The Projects root model has project sub-packages i.e. a package for each project or system.  Each project will then contains its various models like Business, Domain, Class etc.  Individual project teams will have modify access to specific projects.

This should allow our company to establish relationships between Corporate information (roles, data entities, business goals, processes etc) and individual projects under the Projects root model.

So we should be able to do impact analysis such as - Project A implements Use Cases H and P; which support Business Processes B, D and G; which are carried out by Actors J and K; and reference corporate data entities F and L; and satisfy corporate business goals A through D.  This in essence will allow us to use EA for Corporate wide Architecture efforts.

Questions:

-- If you have used EA in a similar fashion, what was your experience?
-- Since EA cannot reference models across Projects, all information (Corporate and Projects) will need to be kept in one EA project.  This project will grow very large very quickly.  What is the largest project size anyone has implemented?  I am hoping that storing the project in a SQL server DB should allow us to grow it significantly without seeing degradation in performance.  Am I on the right track?
-- Needless to say this project will require fine grained security, so that a developer cannot modify the corporate goals.  What was your experience with EA security?

Does anyone have any ideas on what EA's limitations are on such a large project?

Any help/information you can provide is appreciated.  Thanks.

Bobby

[thomaskilian]

Bobby,
I just can't tell you anything about big numbers as I use EA more or less for myself. Your approach however seems to be the right one and also the concerns that you have with it seem reasonable. I can tell you that quite a lot threads here on the board deal with these issues. So my advise is: search the forum and see what's already in here. You will likely not find any concrete number. Just maybe issues where big databases will not work well over WANs and the like.

Good luck.

[Jeff Odell]

We are using ES for a large development project with 15-20 folks using EA daily.  I'm not sure how to compare the size of the repository, but we are storing a lot of models and data in there.

The only reason we up-sized was to make EA work faster for our users coming in with VPN (and it does).  Otherwise, on a LAN, the .eap file was working fine.  

I think you will be pleasantly surprised how well EA will scale up.

I can't really comment on the security side as I haven;t had the need to implement it.

[«Midnight»]

Hi Bobby,

Thomas is right, but I'll try to shed some additional light on this.

I have used EA for something similar, but won't go into details. What I can say is:

• You may need to develop some kind of metamodel for this; try to determine if this will be required and do it as early as possible.
  
• Like Troux' tools and such, consider the ability to import bulk information from some other sources; round-trips are interesting, but don't incur the overhead of developing these unless absolutely required.
  
• EA can probably handle the 'richness' you will require.

EA can comfortably handle models with thousands of entities, and with complex connection networks. Try not to put everything on a single diagram if you want to stay sane. Overall, the results will not always be pretty, but you already understand that if you've seen a complex model rendered with Metis. What EA does do is keep a complete record of the semantic information behind everything. You might be able to do this with Visio etc. but it will be a lot of work. EA will enforce this well, with almost no overhead. Other tools - Visio included - are often error prone unless you take extreme precautions.

There have been reports of slow startup with EA and large repositories. Sparx treats these as bugs and resolves them quickly. Usually they are limited to specific builds of EA on a single DBMS engine. Recently Sparx made an adjustment to their repository back end that was supposed to improve some performance aspects of very large (many thousands of elements) models. Overall performance is usually satisfactory in a local (i.e. LAN) environment. There have been some load time issues reported when models are shared over very wide networks - between countries using undersea cabling for example - but users have reported that Sparx was able to improve this somewhat. Search this forum for more information on large models.

For security, you'll need to think this through. One consideration will be whether you use a source control (or version control, whatever the term) system. Then think about how you will control access to your back end DBMS - does it allow the granularity you require while still allowing users to access enough of a schema to allow EA to work. Look into the EA security capabilities in the user guide. While doing all this make sure you keep consulting the Sparx Resources page for white papers etc. Also search this forum, a lot!

HTH, David

[bsidhu]

Hello,

Thank you everyone for sharing your experiences.  I have started looking more through the forum for large projects and have found more queries and interesting insights into the topic of large projects.  There are no concrete numbers.  So far I have loaded about 500 different elements in various diagrams in a project and the load time still about 3 seconds.  The next step in the testing is to install VSS in the test environment.

There is a commonly requested feature in this forum – Referencing elements from other projects.  I believe this will be a useful feature.

A sample scenario - an Activity diagram in Project B makes references to actors and enterprise data entities in Project A.  These are external references, and the Project B team only has view permission to Project A elements.  When Project B is loaded, the user gets a msgbox like “Would you like to scan for any updates to external references?”.  If the user clicks “Yes” they see a list of everything that has changed in Project A actors and enterprise data entities since the last time Project B was saved.  User is then given option to update the reference.  Of course this will only work well with version control.  

Benefits:
-
Organizations can break down their enterprise scale projects into smaller parts,
-
Reduced clutter in Project Explorer,
-
Simplified security structure required.

What are your thoughts on this?  Is this feature expected in EA in near future?

Thank you again.
Bobby

[Dave_Bullet]

Hi Bobby,

My organisation is using EA to do exactly what you are intending to do.

We implemented the same high level structure you have  (being a "corporate" model and "projects" model)on SQL Server 2000.

Here are some stats on our database size to date:
# of packages = 1,503
# of elements / objects = 5,352
# of connections = 2,517
# of diagrams = 343
# of tagged values (as we use custom stereotypes) = 37,161

SQL Server DB size = 1.1Gb (without optimisation).

Here are my observations (all local LAN access / high speed):
Performance:
=-=-=-=-=-=-
1. EA takes approx 12 seconds to open the project
2. The more elements that are on a diagram - the slower it will open.  It's not that bad though - I have an "overall" diagram of our applications and with 100+ it only takes about 5 seconds
3. Adding and deleting elements has slowed somewhat.  It now takes about 1 - 2 seconds per element.  This is now my biggest concern as this is a frequent operation.

Security
=-=-=-=-
Remember in EA every user has read access to everything when given access.  There is no way to restrict this.  Why is this an issue?  Confidentiality.  Consider you might have vendors / external consultants working on a project... do you really want them to be able to browse things not relevant to their project?

We have implemented a "domain" level group - who can read/write the corporate model, then a "project" group who can only read the corporate model but update the project model.

Governance / maintenance
=-=-=-=-=-=-=-=-=--=--=-=
You need to make sure you have worked through how project created elements get moved into the corporate model on project completion.  This allows you to slowly "grow" the corporate structure

Standards
=-=-=-=--=-
Agree on all stereotypes to be used and additional metadata.  Key elements I would recommend you stereotype are "application", "database" and "node".  Lock this down so project people can't create tagged values and stereotypes otherwise you'll get a real mess.

Keeping data current
=-=-=-=-=-=-=--=-=-=
The more you put in, the more useful it is, but easier to get out of date which erodes user trust.  I suggest you automate feeds directly into the back end DB to keep things current .  I am doing this now for our  infrastructure - feeding off a Computer Associates AMO database that maintains stats on our nodes

I did evaluate Metis (from Troux) and whilst a powerful tool - was expensive.   I have also found Sparx support extremely good and responsive.  I was the one who reported the slow WAN open performance problem - and Sparx fixed it their next build which was released only 10 days after I logged the bug!  I don't know any other vendor with that level of responsiveness!

Single database and "newbies"
=-=-=-=
The newbie can trash a corporate database easily.  Undo in EA is limited.  Make sure you mitigate this with "playpens" for newbies, adequate training, locking down the security, implementing a version control system.

There's a few other small gotchas but nothing major.  I think you are heading down the right path (or at least your ideas concur with mine )

Hope the above helps.
David.

[nara_c]

Excellent write up from David.  Though I have setup EA in this manner in my enterprise there were a few new things I learned from David's post.


Node/Package Structure
=================
We use EA to hold a single model file that has a 2 Root nodes "ENTERPRISE VIEW", "PROJECTS VIEW".  The Architecture group owns the Enterprise view while project teams own the Projects space.  A standard package template is used via an import operation for each project to maintain consistency.  A single administrator (moi) is responsible for setting up new project teams workspaces in EA.

Security
======
All projects start off with a seperate package in the Projects view and the main package say "Project X" is locked for a group called "Project x" into which I add all the project members.  This way even if a user works across multiple projects they have edit access to only the ones they work on while they have read access to the entire model.  Useful to also establish cross model references to Enterprise elements.

Version control
===========
Used Version control for a while but our expereince was that is was restrictive and hence had to be turned off.  For example, if version control was set at the project package level, only one member can edit the model at a time.  To allow all groups to edit we had to move the version control to the lower package level.  But the impact of this was that all users had to complete numerous version configurations for each package or be annoyed by the messages up front.  Have now decided to use an export/baseline approach when significant milestones are achieved.  The SQL server on which the model is hosted is backed up and so we can recover for any fall overs (which has not occurred to date).

Other details
=========
* No performance issues encountered to date
* Around 2 dozen users and growing
* Number of:
   - packages - 480
   - Diagrams - 548
   - Elements - 6334
* Hosted on SQL server 2005(?)
* Used CVS as version control system
* Had raised 2 issues which were resolved by next release.  Never seen a company so responsive.
* Have created 2 custom UML Profiles with stereotypes which we use to minimize extra stereotypes coming in.

> One note of caution, with ver 6.5 EA loads all ad-hoc stereotypes into the model's stereotypes list even if not inserted by administrator.  This is a bit undesirable and had a bad impact on our project.  

Due to the denormalised nature of drop downs in EA, you can either select from a list or add some text ad-hoc.  This will now get inserted into the model the next time someone loads it.


Ideally if EA introduced the cross-model reference, then many of these issues can be resolved.  

Hope this helps.

Cheers

[bcrier]

Thank you nara_c for sharing information about your project.  I agree, if and/or when EA implements cross model reference (across projects) it will automatically address a lot of the issues that we are facing right now.

We have implemented very similar models for our projects and so far my experience has been very good as well.  The project size is growing but the performance is very good.

We have run into some issues with customization of the RTF templates.  I will be posting those findings and workarounds in a separate post.

Thank you again.

Bobby

[bioform]

...
Version control
===========
Used Version control for a while but our expereince was that is was restrictive and hence had to be turned off.  For example, if version control was set at the project package level, only one member can edit the model at a time.  To allow all groups to edit we had to move the version control to the lower package level.  But the impact of this was that all users had to complete numerous version configurations for each package or be annoyed by the messages up front.  Have now decided to use an export/baseline approach when significant milestones are achieved.  The SQL server on which the model is hosted is backed up and so we can recover for any fall overs (which has not occurred to date).

Other details
=========
* No performance issues encountered to date
* Around 2 dozen users and growing
* Number of:
    - packages - 480
    - Diagrams - 548
    - Elements - 6334

...

So you are using NO version control? With that many users and objects I would have assumed that you would have experienced at least some significant problems by now?

I am getting ready to link Subversion to EA, and use that as our control, since I have no experience with this area, and based on your comments, feeling a bit nervous...

ANY one else having problems or annoyance issues with using version control with EA projects?

Suggestions on work-arounds, configuration ideas?

Thanks for you comments Nara!

As always, good forum entries...

[nara_c]

So you are using NO version control? With that many users and objects I would have assumed that you would have experienced at least some significant problems by now?

We have experienced no problems to date and are comfortable with this approach so far because of 2 reasons:

1) Users are clear on which package they are working on and there is never a case when 2 people are working on the same element at the same time.  We manage this by deciding on package structure up front and having a designated sub-team member responsible for each package. for e.g. Lead BA for Use Case model, Technical lead for Component model etc.  Lead BA is requested when new sub-packages are required and BAs are assigned to work on groups of work within a package which is based on logically related stuff.

2) We keep frequent snapshots of our model as XMI Exports named by date, so we can always compare with current model status and highlight the differences.

Our SQL database, on which this model sits is backed up daily.  So that gives us an added level of security, that should the DB go down, we are able to get it restored to a suitable state.

Like I mentioned, we initially turned on the version control but soon found it annoying and requiring constant management and hence decided to adopt the current approach.

My suggestion, try both and see which works for you.  But if you are nervous start with the version control and get rid of it once you are familiar with the product and decide on the ideal working style for your team.

HTH.

[bioform]

Thanks for the reply!

I agree that ease of use is VERY important, and implementing package responsibilities in the business world is a solid approach. Using the XMI exports as snapshots sounds like a good idea too (along with the database backups)

Seems like a solid approach, thanks for the speedy reply...

QUESTION - How would you roll-back to a snapshot? Would that be done by "deleting" all views and their corresponding packages from the project on the database, and then import the XMI snapshot to re-populate the tables?

We are using EA as a replacement for Compuware's Reconcile (IMHO a horrible overpriced tool), implementing change control processes using EA “change object” and base lines, establishing robust traceability and documentation generation.

Later we will be integrating with test and design (high level architecture), then eventually into some development (trace mainly to eclipse work components) and more robust testing integration with the goal of managing test results and effort with EA.

Thanks again...

I will post some more specifics of our approach (e.g. configuration of EA's reference values, classes and instances for tracing acceptance criteria, requirement sources, etc.) in the near future if anyone is interested...

[larsgk]

Excellent write up from David.  Though I have setup EA in this manner in my enterprise there were a few new things I learned from David's post.


Version control
===========
Used Version control for a while but our expereince was that is was restrictive and hence had to be turned off.  For example, if version control was set at the project package level, only one member can edit the model at a time.  To allow all groups to edit we had to move the version control to the lower package level.  But the impact of this was that all users had to complete numerous version configurations for each package or be annoyed by the messages up front.  Have now decided to use an export/baseline approach when significant milestones are achieved.  The SQL server on which the model is hosted is backed up and so we can recover for any fall overs (which has not occurred to date).

I completely agree. We set out our project using version controlled packages as the way to implement a "shared" model. But in practise it turned out to be too cumbersome when multiple users were working in parallel in related branches of the model.
There were a lot of checking in/out, refreshing model views, but we also experieced problems with inconsistent diagrams.
If e.g.  a diagram references an element in a different version-controlled package, and you haven't updated that package, those elements will disappear without notice.

We switched to the SQL server repository model, and that works perfectly for our process!

[mikewhit]

All that's really missing is a way to take a snapshot of the SQL server repository model to allow backup or rollback.

[Dave_Bullet]

All that's really missing is a way to take a snapshot of the SQL server repository model to allow backup or rollback.

I simply do this via SQL Server Enterprise manager.  Doesn't take too long (5 - 10 seconds?)

We haven't gone down the VC path either.  Mainly because it is yet another thing to configure and only 2 of us can edit the "enterprise" root model.  Hence chances of disaster are lessened.  We also do daily SQL server backups.

One thing I forgot to mention - don't set alternate images in your UML profiles.  EA takes much much longer to open the project. Instead use an _image attribute on the stereotype to attach the shapescript to display the image.   load speed won't be affected this way and it is functionally equivalent (even allows you to write some script).

Cheers,
David.