Portfolio Manager has lots of settings which you can customize to your local requirements. Any of these settings which you can changed will be show like this – “Implemented“.

Decide on your scope

Portfolio Manager (PM) has been designed to allow for lots of projects – up to 100 – to co-exist in the same model.

But that doesn’t mean that you need to roll-out PM to every project at the same time. We suggest that a lower-risk, lower-effort (but longer time) way to introduce PM is to let new projects use as they start up. That way, over a period of a few months, as old projects stop and new ones start, you will gradually increase the number of projects which are using PM. This means you can also refine your approach, and develop your own roll-out plans using experiences from the first few projects.

If you decide to introduce PM to projects which are already in-progress, you will probably need to make quite a few changes, depending on how those projects hove dome their modeling:

For new elements which a project has created, you don’t need to do anything
For elements they want to modify, what you need to change will depend on how they have use your existing elements:
- If they have done a ‘copy as new’ or used instances of the baseline elements, then you will have to replace these duplicate elements with elements that you branch from the baseline
- If the project exists in a separate EA model repository, you’ll need to find where they have modified any baseline elements (using the EA DIFF tool) and again re-create them as branches from the baseline.
For elements they want to delete, you’ll need to find how they have modeled that, and create ‘branched-to-retire’ versions of those elements

As you can see, changing an in-progress project might be a lots of work, depending on how many changes to baseline elements they have made – hence our advice to just use PM on new projects.

Preparing your baseline

PM assumes that all elements which are in your baseline have a status of ‘Implemented’. The exact word used for this status can be changed in your local settings, but this guide assumes that your are using the defaults, in this case “Implemented“. See settings for more details.

So you need to change all the status value of anything that you want to allow projects to branch, and potentially change, to be ‘Implemented’. Note that elements which keep any other status, for example, ‘Proposed‘ (the EA default) will not be available for projects to branch, which may be what you want.

A quick way to change what may be 100s or 1000s of elements is either to create a script or some SQL to run against your repository, or export them to a spreadsheet and change the status there. This is really easy if you use eaDocX/Excel.

Installing Portfolio Manager

Portfolio Manager (PM) runs as an add-in (extension) to Sparx EA.

Each modeler who is part of your PM rollout will therefore need to have a copy of PM installed on their machine. This means running the PM installer for each person.

Repository Setup

For more details on specific changes to your EA model repository, see Portfolio Manager repository setup

Portfolios and Projects

PM assumes that each project will have a single EA package which contains all the elements for that package. PM will give that package a stereotype of ‘project‘ (see Settings to change the value of this stereotype)
Under each <<project>>package, PM will create a single element with a default type of ‘ArchiMate_WorkPackage’. This represents the project from the point of view of understanding dependencies, and is used where we need to remember which projects are delivering which changes. You cannot change this mechanism, but you can change the type of element which represents the project, using the settings.
The design point of PM is where you have a lot of projects, and PM allows you to organize projects into groups called portfolios. These packages are given a stereotype of ‘portfolio’, and again, you can change this name to something else in the settings.
Project teams are free to create sub-packages under their <<project>>Package, as required, and store their new or branched elements in the appropriate location. All are considered by PM as belonging to the project.
For more details, see Create a Project

Initial Settings

To see the initial setup settings for PM, see PM Settings. Only a small number of these need to be changed each time you setup a new repository to use PM

Training your modelers

PM is designed so that existing EA modelers can use it with minimal training.

The most important thing they need to know is that, if they think their project needs to change something in the baseline, they need to take a branch of that element(s). To do this, they need to:

Create a new diagram in their project
Find the element(s) in the baseline, and drop them onto the diagram using Paste as Link. This is really important. If they use ‘Paste as new‘ then PM will not work: they have just created a copy of the baseline element, which is not related to the original ,and which PM will treat like a whole new element.
Then use the PM ‘Create Branch’ function, on one or more elements in the diagram.
PM will then:
- Create a deep copy of the original element, and give it a status of ‘branched‘
- Put that new element in the same package as the diagram. The modeler can then move it elsewhere in the project, if required
- PM also links the new ‘branched’ element back to it’s ‘source’ element in the baseline using a <<branch>>Dependency connector
- and finally, replaces the baseline element in the diagram with the new branched one.
- If the diagram contains the Status Legend, the user will see a change in the outline color of each branched element.

Portfolio Manager assumes that it is the modelers in a project who create branched elements, and that they have only read-access to the baseline.

Integrating EA and PM with your Project Delivery Process

Portfolio Manager assumes that you have some kind of project delivery process. That may be waterfall, agile, or some blend of the two. But there need to be a defined point in the life of a change where the change moves from a ‘thinking’ to a ‘delivering’ stage.

It is vital that if you use Portfolio Manager, those project milestones trigger actions in EA.

So when a project moves from ‘thinking’ to ‘delivering’, project teams must promote their changes to be ‘planned’. If not, then the EA model repository will fill-up with branches, nothing will be made planned, and projects cannot build on each others work.

In this case almost all of the benefits of EA and Portfolio Manager will be lost.

You will no longer have a single version of the truth, and you won’t know which projects are planned to be implemented, or have finally implemented. You won’t be able to do proper impact analysis, create element road maps or work-out project dependencies.

Changes to a project delivery process are not simple to do, but even if the ‘official’ process is unchanged, if you has responsibility for some part of the model, you should be able to make sure that project managers understand that promotion, or implementation are projects which modelers need to know about.

Promoting

Portfolio Manager (PM) allows for two ways to promote elements:

Promoting the whole project together – recommended. Promotes all the ‘branched‘ and ‘proposed‘ (new) elements under the project.
Promoting individual or groups of elements.

In either case, the elements to be promoted will each be:

Given a status of ‘Planned‘ (or your local equivalent)
Connected to your project element with a <<delivers>>Association
Moved to the location defined in the settings for Staging package

This means that modelers who do this need to have write access to the staging package. See

Protecting Planned elements

Projects which promote elements to become planned are telling the rest of the modeling community that these changes are very likely to happen – they are is part of an approved project. The changes might possibly NOT happen, but this would be because of a late change to the project, and PM will help you to understand the impact of such a change.

Because these ‘planned’ elements now have a special state, we think you should give them additional protection against accidental change, by putting them into a part of the model to which the project team to not have write access. This might perhaps be in to a staging area which is reserved just for that project.

We assume that if a project needs to change any of these elements after they have been made planned, then there will be a strict change process to do this, and that the change will be done by someone who does have write access to them.
Whoever does the change should first use the PM Impact Analysis tool, and regular EA Traceability, to see where the element(s) are used, and what the impact of this late change will be.
This will not be simple, but if all projects are in the same EA model repository, then understanding that impact is perfectly possible. Without EA and PM, it would be hard, if not impossible.

Implementing

When you Implement some elements – because a project has gone live or delivered the required change – we assume that someone with write authority to the staging are will make the change.

This is because:

The package where they are saved should not be accessible to project modelers, as the elements in it are under change control (see above)
The modelers have probably moved on to other projects, so won’t be around to make the changes anyway.

Making some elements ‘implemented‘ has implications for the wider model:

If you choose to replace the source elements of branches, then those source elements will have all their connectors deleted, and will be moved to an archive folder.
(future releases of PM will allow you to keep the old versions as well as implemented the new)
All the fields, tagged values and connectors are already setup in the ‘planned’ elements, so they don’t change when they are implemented.
What will change are the GUIDs
- Source elements will have their GUIDs changed. This shouldn’t matter, as they are no longer to be used
- The newly implemented elements, if they were previously branched, will take on the GUID of their source. This means that external references to the original source element will now point to the new one.

Managing a Portfolio Manager Model

PM contains lots of tools and reports to help you understand what’s happening in your model. This gets more important as the number of projects which are using PM grows

Impact analysis can be run at an element, diagram or project level. Portfolio-level Impact Analysis would probably bee too slow to be useful
The baseline map give a picture of all the elements of a specific type and stereotype, and shows which ones have been branched, or have planned versions
Portfolio and project dependency diagrams show the dependencies between projects which occur because they have branched or planned versions in common
Portfolio and project maps show all the elements in a portfolio or project, and their status

Portfolio Manager walkthrough

Portfolio Manager repository setup

Table of contents

Getting started with Portfolio Manager