Organizing my projects in Sparx EA

      2 Comments on Organizing my projects in Sparx EA

Updated (2019/03/27): I’ve made some changes, and posted a new blog entry

About a year ago I posted about how I started using Sparx EA, and stated that because of the tools flexibility it can be challenging to determine how to organize your work.

So I thought I’d share how I’ve currently organized projects in Sparx EA where I work.

First, a bit of background.  I work for a fairly large organization, with a lot of different business lines, and a lot of different users of Sparx EA, each with different levels of experience and training, so I had the following requirements:

  1. I needed a way to provide links to training material for users
  2. I wanted to organize common models and elements in a central location so they could be easily found and used across multiple projects
  3. I wanted to make it easy for the different users to start new projects, find existing ones, and control who had access.
  4. I wanted to create “templates” for common business services that would be created or modified by our projects, e.g. one of the primary roles of my employer is the creation, and oversight of regulations.   So many of our projects exist to create new regulations, and implement the Business Services and IM/IT Solutions required for regulates to report under the regulations, and for my employer to evaluated the reported information.   There is a common pattern to the activities, scenarios, and domain relationships that have to be modeled.   So having templates for this, and other common patterns as a starting point for new projects could save a significant amount of time.

I ended up the with the following Model Nodes:

  1. Training Guides and Getting Started
  2. Sandboxes
  3. Enterprise Models and Catalog
  4. {Branch Name} Projects (repeated for all 8 branches in the organization)
  5. Project Templates

I had originally planned to use Model Nodes for the projects, but found that approach to quickly become awkward (the list became to long), so instead created a Model Node for each branch within the organization, and created packages underneath for each project.  This actually worked out fairly well when I realized having the projects under packages would allow me to create an introductory diagram as the first diagram in each project package.

Training Guides and Getting Started

Under this first section I added a introductory diagram that I set as the default diagram for the repository.   The diagram contains:

  • A contact section showing the names and email addresses of who to contact with questions about Sparx EA.
  • An announcement section showing any scheduled outages for server maintenance (the database or cloud server),
  • An updates section, indicating the current version of Sparx EA available for use, with a link to a batch file that automatically installs the latest version of the AutoHotKey scripts, custom MDG files, and the default Workspace layouts from a network share.
  • A mind map, showing different categories of guides, the guides are in the child diagrams.

Additionally there are packages that contain:

  • The meta models for the different modeling notations such as Archimate and ToGAF
  • The Elements template package, that I use to set the default text and headings in the notes for Activities, Business Scenarios, and User Stories, and Use Cases.
  • The custom MDG profiles created internally for creating Domain Models, and project Packages
  • The class diagrams and sequence diagrams documenting the EAF facade that sits on top of Sparx EA’s automation API, that I created to simplify common or awkward tasks.


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.

Enterprise Models and Catalog

The Enterprise Catalog is grouped based on ToGAF with a couple of additions:

  1. Reports, containing predefined Virtual Documents for generating reports using the content in the Catalog.
  2. Organizational Units and their Viewpoints, contain Elements representing the different Organizational Units of my employer, their partners, and their clients, and when needed diagrams showing their specific viewpoints.
  3. Catalog of Requirements and Source Documents, such a legislation, regulations, directives, policies, contracts, standards etc.
  4. Catalog of Influencers, Assessments, Strategies, Goals etc, basically the Enterprise Motivational Model.
  5. Catalog of Shared Business Architecture Components
  6. Catalog of Shared Information Architecture Components
  7. Catalog of Shared Application Architecture Components
  8. Catalog of Shared Infrastructure Architecture Components
  9. Catalog of Locations
  10. ToGAF Technical Reference Model
  11. ToGAF Standards Information Base

Content is either directly added to the Catalog, or migrated from a project during project close out.


As I mentioned earlier each Branch has it’s own Model Node, and projects underway for that branch are located in packages underneath.  Each of these project packages have the stereotype Project defined by the custom MDG profile I mentioned earlier, the profile defines some additional tagged values used for things like the counters for project scoped traceability IDs.

The sub-packages for the project are similar to those for the Enterprise Models and Catalogs, with a few additions and changes:

  1. Project Reports, containing predefined virtual documents for the Projects:
    • Preliminary Business Case (internally we call this the Summary of Needs),
    • Business Requirements Document (BRD) that identifies the Business Requirements, Stakeholder Roles, Stakeholder Requirements (for each Role), Business Objects and the Information Requirements for the contents of the Business Objects.
    • Business Process Model (BPM) that identifies the Business Products, Services, Processes, Activities, Functions, Scenarios, User-Stories and Mock-ups.
    • Domain Model and Data Dictionary (DMD)
  2. Project Tracking and Management, originally used for documenting product breakdowns, and identifying project stakeholders (not the same as product stakeholders), but with the addition of Kanban support, it’s taking on a much more active role in our project management activities.
  3. Requirements Analysis and Source Documents, with sub-packages for source documents with extracted source statements, business requirements, stakeholder requirements and solution requirements
  4. Vision and Mission (ToGAF Phase A), containing the influencers, strategies, goals and other motivational elements for the project.
  5. The Business Layer (ToGAF Phase B)
  6. The Information Layer, we intentionally split out information from the application layer to support the small number of business processes that still use paper records for legal or logistical reasons.
  7. The Application Layer (ToGAF Phase C)
  8. The Infrastructure Layer (ToGAF Phase D)
  9. Opportunities and Solutions (ToGAF Phase E)
  10. Migration Planning (ToGAF Phase F)
  11. Implementation (ToGAF Phase G)
  12. Change Management (ToGAF Phase H)

Project Templates

Project templates serve three purposes:

  1. To define a common structure for new projects
  2. If the project is in support of a common service pattern, there are templates that include the typical services, roles, process, activities, scenarios and user stories for that pattern. (work in progress)
  3. To define the default locations for element types so users can run a script I created that will auto sort elements to the proper packages within the template.

Overtime I plan to add more blog entries that detail the different points I mention in this post.  If you are interested in a specific topic, let me know in the comments.

2 thoughts on “Organizing my projects in Sparx EA

  1. Angus Wall

    We’ve just started trialling Sparx EA v14. I’d be interested to know how you get on when two or more projects are changing the same shared component. How do you control the change management around that and give visibility to each project team of the potential changes that another project is creating?

  2. Steve Savage Post author

    A couple of assumptions for my answer:
    You have formal change management and release management processes for any components you are changing, e.g. it’s not a free for all, there is oversight for how shared components are designed, evolved and released.
    What I found worked the best is not “modifying” an element to reflect the latest “released” version, but instead to keep all previous “released” versions, and create a new copy representing the latest “released” version. This allows you to track the implementation of different versions of the same component at the same time.
    This is particularly useful to let you model branching in your code. (if the component hasn’t been released it’s up to you if you want to create and keep copies to show the evolution of a design, and your rational for design changes)
    Component 1.0 has been released and is being used by several applications.
    Project A begins with the purpose of releasing Component 2.0, they set the status of Component 1.0 as deprecated.
    Project B can’t wait for Component 2.0, so is using component 1.0, but discovers some bugs, so they fix them, and creates a new copy Component 1.1, and release their application. They set the status of Component 1.1 to deprecated to indicate it will soon be replaced.
    Project A releases Component 2.0, and sets the status of Component 1.0 and 1.0 to replaced.

    Tracking all these “copies”
    I use Archimate to create an element that represents the component from an architectural perspective, as long as the component is still providing the same or more functionality you can keep using the same Archimate Element (basically all the connections to it from other components in your architecture still hold true)
    I’d then use UML component elements to model the different versions of the component that have been released and are therefore being used by other projects/systems etc (I use UML for detailed work).

    I currently use the generalized by relationship from UML components to the Archimate component.
    This lets me select the Archimate element to see all the various copies of UML component that represent the different versions. (I use a similar approach for Business Processes to track changes to process models over time)
    You don’t have to switch to UML, you could just use Archimate for all the components, it’s up to you the keys is proper use of the version field, status field, and grouping using the generalized relationship.
    I’ll try to put this in a blog entry in more detail in the next week or so.


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.