A project template for Sparx EA

      1 Comment on A project template for Sparx EA

A few years ago I created a standard package structure to use for projects, this let me do a few things:

  1. More quickly ramp up new projects
  2. Make it easier to reuse projects (copy / edit)
  3. Make it easier for other people to find information in projects
  4. Have a standard set of virtual documents for reports included in the template that are per-configured to point to the correct packages for each section of the report.

The package structure is loosely based on ToGAF and Archimate layers:

  • Project Package
    • Introductory Diagram
    • i: Project Management Reports and Dashboards
    • ii: Requirements, Constraints and Preferences
    • B: Business Layer
    • C.1: Information Layer
    • C.2: Application Layer
    • D: Technology Layer

Introductory Diagram

Introductory Diagram

The introductory diagram makes use of Sparx EA’s new (as of EA 13.5) navigation cells (icons) to make it easier for people viewing the project in Sparx EA and WebEA to navigate the project.

The navigation diagram links to sub-diagrams under each package, and provides summary information about the project: name, description, contacts.

Project Management Reports and Dashboards

  • 01: Project Reports
  • 02: Project Dashboards
  • 03: Project Phases and Backlog
  • 04: Project Stakeholders
  • 05: Project Issues
  • 06: Project Meetings

The Project Reports package holds the standard virtual documents that are used for most projects.   They are pre-connected to the appropriate packages.  The dashboards use model views and series charts to track changes to information in the projects.  The Project Meetings contain document elements with the minute meetings available as the linked document for the element.  This allows me to link text in the meeting minutes to action item / requirement / constraint elements etc. in the project.

Requirements, Constraints and Preferences

  • 01: Source Documents
  • 02: Business Requirements
  • 03: Stakeholder Requirements
  • 04: Solution Requirements
  • 05: Solution Constraints
  • 06: Solution Preferences

I wrote a separate blog entry on why I categorize and organize requirements in to Business, Stakeholder, Solution, Constraint and Preference.   The notes of the packages in the template also provide these explanations.

Business Layer

  • Business Layer Introductory Diagram
  • Catalogue of Elements
  • Diagrams (viewpoints)
  • Business Scenarios

The Business Layer is where I do the majority of my work.  The catalogue contains packages for the Business Layer and Motivation Elements defined by Archimate, the Motivational Elements defined by the OMG Business Motivational Model, and the Process Elements defined by BPMN.

Child diagrams are created under each element to show increasing level of detail about each service.   Typically layering: Business Product -> diagram -> Business Services -> diagram -> Business Process (Archimate) -> diagram -> Business Process (BPMN) -> diagram -> Business Activity -> diagram -> Task -> diagram -> sub-task….

You may have noticed that I use both the Business Process Element for Archimate and the Business Process element for BPMN.  The Business Process (Archimate) describes the process in a generic way, the Business Process (BPMN) describes a specific version of a process, and allows me to model as-is, transitional and to-be processes side by side but show from an architectural perspective they achieve the same result.  E.g. as-is = paper process, transitional = both paper and electronic being used, to-be only the electronic solution is being used.  If you only have one version of a process feel free to directly model the process under the Archimate Element, you can always add the BPMN element at a later date if you need to show changes.

If a Business Activity, task, or sub-task is going to be making use of an IT solution, the notes of that element are written as a user story, with the diagram under that element showing the relevant System Use Cases and Mockups.  Both System Use Cases and Mock-ups are stored in the Application Layer, and are provided by the development team.

Business Scenarios are used to describe key events that are important to the business and the businesses response to the event.  The diagrams under these scenarios typically describe a path taken through a process or set of processes in response to the event.  They are modelled as Archimate Business Events.

Information Layer

  • Introductory Diagram
  • Catalogue of Elements
  • Diagrams (viewpoints)

Because the organization I work for is very information-centric I decided to separate the catalogue and models for information from the application layer.  This let’s me discuss the information being manipulated by services and processes without assuming that the information will be processed by an IT solution.   There are several valid scenarios where electronic solutions are not practical or cost-effective.

The key package in the Information Layer is the Domain Model.   The domain model uses a custom profile I created for domain modelling, and is used to describe:

  • The different people, places and things that the organization will be gathering information about (e.g. regulatee, facility, engine)
  • The relationships between them, e.g. a regulatee can be the owner or operator of a engine, and engine must be located at a facility.
  • The properties that need to be know, e.g. name, address, serial number

I plan to write a blog entry on domain modelling and will update this entry when I do.

Application and Infrastructure Layers

  • Introductory Diagram
  • Catalogue of Elements
  • Diagrams (viewpoints)

These layers contain packages for holding the related Archimate elements.

What’s missing

The remaining steps recommended by ToGAF ADM were originally in the template but have been removed, I found we were not tracking that information in Sparx EA and therefore those packages were typically empty.

One thought on “A project template for Sparx EA

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.