Organizing my projects in Sparx EA (revised)

A few years ago I posted how I’ve been organizing projects in Sparx EA.  Since then I’ve made some refinements that I thought I’d share.

The number of main nodes have been reduced to 4:


This hasn’t changed since the last version, each user of Sparx EA get’s their own sandbox, these are typically used when the person’s work needs to be reviewed before it can be integrated into a project or moved to the Enterprise Catalogue.

The organization is fairly simple.  There is a Package for each Branch, and a sub package for each team, and then a sub-package for each user.  Each user locks the package to themselves to prevent others from accidentally editing their work.

Common Area

This is a combination of the Training Guides, Enterprise Models and Project Templates sections described in my previous blog entry.

In the root of the welcome package under this node is a “welcome” diagram that loads as the default diagram for the repository (and our WebEA server).   The diagram makes use of Sparx EA’s new (as of 13.5) navigational cells (icons) to simplify accessing the different packages in Sparx EA.  Each referenced package has as similar diagram providing information about each section.   In Sparx EA 14 you can set the model default diagram by navigating to a diagram, then on the layout ribbon select: diagram -> manage -> set as model default

The project templates have also been updated, in addition to a new version of the blank template, I will be creating new pre-started templates containing common service patterns.   See comments in the inactive project section below for how we are analyzing completed projects to identify these patterns.

Active Projects

Previously the repository had a node for each branch in my organization, and a package under each node for each project .   These have been re-arranged to:

  • Active Projects (model / root node)
    • Branch
      • Project Package

Inactive Projects

To make it easier to track and lock projects from editing the project packages are now moved to the inactive project’s node:

  • Inactive Projects
    • Completed
    • Parked / Deferred
    • Planned (but not started)
    • Backup

All projects in the inactive project’s node are locked against editing and are only unlocked when moved out of the inactive node.

The completed projects are kept in the common repository as they often contain information or models that can be copied and re-used.   Over time as we identify more and more similarities in process models for projects that are implementing / changing similar types of services, those similarities are being captured in project templates containing those process models so they can be used as a starting point.   A good example of this are the projects that implement some form of regulatory reporting, the details of the information being reported may change, but a lot of the processes for handling the basic flow (submission), exception (correction) and alternate flows (late submission) are information agnostic.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.