Inside Portfolio Manager
Portfolio Manager uses lots of EA features, which means it looks nothing like the code-based version control you are used to. Here is how PM works.
Design approach
All the existing approaches for “version control” for EA use the same techniques as code- or text-based version control. They create text files – in the case of EA, these are the horrible XMI files – and do code-style branch and merge on these.
Portfolio Manager starts from a different place.
Requirement #1 for PM is for everyone to be in the same EA model. So there’s no need to export, import, branch, diff or merge XMI files – everything is in the model. So all we need to do is create the right elements and connectors to allow multiple versions in multiple states. And allow many project to co-exist in the same model repository.
Below we’ll take you behind the scenes, to show you what Portfolio Manager is doing when it creates branches, promotes and implements elements, and keeps track of projects and portfolios.
Starting point
These are some elements from the baseline. We will create some branches from Business Function 1, and see what PM creates inside EA.
For the rest of the examples here, we will show both the branched/planned elements, and their corresponding baseline (implemented) elements. We don’t expect modelers to do this, as it makes diagrams much more complicated. They would just show the branched or planned items which they have created.
Creating a branch
PM creates the branched element as a new element, and copies all the fields, tagged values and connectors to the new element.
It gives that element a status of ‘Branched’. It also adds a tagged-value to all the connectors called ‘Status’ value ‘Proposed’. It also writes another tagged value to the connector, which is the ID of the connector from which it came. This is for internal use only. These connectors are also colored blue, to differentiate them clearly from the baseline connectors, which keep their original color.
Finally, PM creates a link from the baseline element to the new copy.
A second branch
If we now create a second branch, the same process is followed.
Note that this is perfectly OK in Portfolio Manager: two branches from the same element at the same time. It just means that two (or more) projects are thinking about changing this element, which is where we start to get insights about what’s happening across the model, and start to build a ‘big picture’.
Emergent Behaviour
So the internals of Portfolio Manager are quite simple.
It’s adding together all of these small, simple connections and status values which delivers the really interesting insights: which elements are changing most, and by whom, what will be the impact of one project on another, and, by adding all these project-to-project impacts together, what are the dependencies between projects. Adding all these together create a really big picture of how all projects are dependent on each other.
More Insights
Why did we write Portfolio Manager?
22 June 2023
To give modelers visibility of dependencies and impacts between projects.
Learn MoreWhat AND why
8 November 2022
Making maximum use of our EA information, to show not just what the world looks like now, but why as well.
Learn MoreSolution Architecture using Enterprise Architect
6 October 2022
Ian's presentation to the EA Global Summit on September 15th 2022
Learn MoreProject Lifecycles and Portfolio Manager
23 June 2022
How to integrate the Portfolio Manager lifecycle with waterfall and agile development methodologies
Learn MoreBranching and Impact Analysis
15 June 2022
How to start your project in EA by copying from the as-is model - with Portfolio Manager
Learn MoreIntroduction to Portfolio Manager
14 June 2022
A new approach to delivering a single version of the truth across many projects all working in the same Sparx EA model repository.
Learn MoreStructure, Locking and the Portfolio Manager State Model
9 June 2022
Portfolio Manager basics: Package structures, model locking and element state model
Learn More