Organizing my projects in Sparx EA

      No Comments on Organizing my projects in Sparx EA

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.

Sandboxes

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.

Projects

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.

Leave a Reply

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