One of the distinguishing characteristics of Strategy to Execution, when compared to other Use Cases, is the large amount of information that remains relevant for a comparatively short time compared to other EA information. As execution delivers on strategy concepts change, need to be updated, or can disappear completely.
If this transitory data is not correctly managed or understood a large amount of information will be retained that is no longer relevant. This adds unnecessary complexity to visual models and reports and will require the data to either be cleaned or filtered to enable clarity to those visualizations and reports. The following document explains how to do this.
For more information about the purpose, scope, and rationale for a Strategy to Execution process see the document Strategy to Execution: Purpose, Scope, and Rationale.
For more information about Ardoqs implementation of Strategy to Execution see Strategy to Execution Metamodel.
The Lifecycle of Information
All types of information defined in our Use Case Guides have an inherent lifecycle. Applications, IT Infrastructure, and Business Capabilities will continuously change and eventually be replaced. But this information will exist in EA models for long periods of time, usually measured in years.
The concepts for Strategy to Execution, such as Objectives, Initiatives, Impact References, and Capability Deltas, typically have a much shorter relevancy life span, usually measured in months.
Additionally, the volume and frequency of change for these concepts are much higher than for Applications, Capabilities, etc. Consequently, there is a need to make Strategy to Execution concepts prominent in EA models when they are relevant for decision-making and then remove or minimize their visibility when they are no longer relevant.
For example, Change Initiatives are usually relevant during ideation, planning, execution, and business realization acceptance measurement. But after that time they are usually only of interest for historical analysis.
Addressing the changing nature of concepts
There are two approaches for filtering out components and references in Ardoq:
Create and use a status field on a component. That field can then be used to filter those components from Viewpoints and Visualization perspectives.
Move those components to a replicated workspace and then filter that entire workspace from Viewpoints and Visualizations. This requires copying them from the original workspace and then deleting the original component. Copying components will maintain all field values and references. This new workspace can easily be excluded from Viewpoints and Visualizations.
There is currently no feature to archive components in Ardoq so these alternatives require some manual work.
There is a tradeoff between the manual effort to maintain data, the performance of workspaces with large numbers of components, and ensuring that Viewpoints and Visualizations remain relevant and provide business value as data changes in importance.
Therefore, we recommend two options:
Option 1
If you do not need the components for historical analytics then simply delete them.
Option 2
If you do want to maintain the data then we recommend the following approaches to ‘archiving’ components to make them less prominent:
A new Objectives workspace is created each year. There is no technical limitation on the number of Objectives workspaces you can create. If you make a new workspace each year then strategic objectives that span multiple years should be moved to the newly created workspace.
Components in a parent-child hierarchy need to be carefully considered when moving between workspaces. Objectives should not be in a hierarchy so there should be no limitation on moving relevant strategic Objectives to the newly created workspace.
Graph, perspective, and viewpoint filters should then be created to hide Objective and Key Result components that have a particular status field or a time-period field that has expired. Examples of these filters are provided in the Use Case assets and users can adjust them to their context.
Initiative and imported Issue-tracking components do not follow the same calendar cycles as Objectives and therefore it is harder to separate these by moving to a different workspace at regular time intervals. However, there is still a need to archive these components when they are no longer relevant. If the volume of components impacts performance, then partition those workspaces as needed rather than each year as suggested for Objectives. That is, create replicated workspaces for Initiatives and import issue-tracking components. These partitions should be based on a logic that allows you to archive an entire workspace when its content is no longer relevant.
The technique to do this follows the same pattern as for Objective workspace archiving. Create a new workspace of the same type and all new components are populated there.
Note that the entire hierarchy must be set to done before moving. That is, Initiatives that are still executing should not be moved to a workspace that will be filtered from views.
Capability Deltas also have a relatively short lifespan and can grow in number until they impact helpful visualizations. Archiving these components follows the same pattern as Initiatives.
Create a new workspace for capabilities that includes a folder for Capability Delta components. It can be named ‘Capability Delta archive’ for example. This new workspace should not have a copy of the business or technical capabilities. It should only have the folder for capability deltas.
Move (copy + delete original) the Capability Delta components from the original Capability workspace. This will maintain references between deltas and the capabilities they have impacted, allowing the workspace to be easily filtered from relevant Viewpoints and Visualizations.