As part of the release of the standardized best practice module for Strategic Planning and Execution, we have included a pre-configured meta model with a scope designed to give you a quick time to value. 

While the meta-model is all you need to start answering key business questions, you still have the full flexibility to expand, contract, and change the model in any way you see fit to better suit your business needs. 

With that in mind let's look at the key concepts of the meta-model:

The Metamodel is broken down into 4 workspaces with references connecting them:

Within these workspaces, we have smaller meta-models consisting of Components, References, and Fields. We will go through these per workspaces.

Note: The projects are meant to be connected eventually to the architecture that they are impacting. For the example above we have taken Applications and Capabilities as a starting point. These are not included in this module but are their own modules in themselves which you can also configure in-app from the Best Practice Menu.

The Strategy workspace is a flexible model with just one Component type:

This enables you to create nested strategy models as deep as you see fit.

The workspace also has only one Reference Type:

This reference can be used to connect the strategies to their one or many objectives.

The Objective workspace is a flexible model with just one Component type:

This enables you to create nested models as deep as you see fit.

The workspace also has only one Reference Type:

This reference can be used to connect the objectives to the project or projects realizing them.

The Project workspace is a flexible model with just one Component type:

This enables you to create nested models as deep as you see fit.

The workspace also has only one Reference Type:

This reference can be used to connect the projects to the architecture objects that they impact. This is often used in combination with the other best practices for APM or BCM.

The People workspace is used to generate a repository of people (employees, consultants, etc.) who have a responsibility, ownership, or expertise which is necessary to capture. People are also used in the APM best practice and can be built upon for better impact analysis and incident resolution. 

The People workspace includes only one Component type and is also a flexible model: 

The workspace also comes pre-configured with two Reference types: 

By using these reference types you can identify domain expert networks and run impact analysis to understand who might be impacted by a change or issue and also who to talk to if expertise is needed for issue resolution.  

There are few predefined fields included in the best practice module for Strategic Planning and Execution. Not all are necessary to use to answer key business questions and you can choose to expand, simplify or update at a later time.

For the sake of better explaining the purpose of these fields, we have grouped them into categories. This grouping has no impact on where they can be applied, how they are defined, or their importance. 

Within this module, we have only used fields on Components, but they can be added to references if that is valuable.

This field is used to capture costs wholly attributable to a given component. An example of this would be the license cost of an application. With all cost fields, we recommend that you standardize the currencies across your organization.

This list field can be applied to anything which you would like to create roadmaps and manage lifecycles. The list of phases (in order of time) includes: Evaluating, Development, Live, Mainstream, Phasing Out, Retired

Use this date field to plan an Evaluation phase and visualize it in the Timeline View. This includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers. 

Use this date field to plan the Development phase and visualize it in the Timeline View. This includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers. 

Use this date field to plan the Live phase and visualize it in the Timeline View. This includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers. 

Use this date field to plan the Mainstream phase and visualize it in the Timeline View. Mainstream is a sub-phase of Live and relates to the period for which the component is in a 'steady-state'. For example, before an application is Mainstream it may be ramping up its use, and after it is Mainstream it may be ramping down.  This phase includes a start and end date. Ideally, the end date of one phase should match the start date of another, but this is not a requirement as you may have gaps in handovers. 

Delivery Complexity is a generic measure to capture some qualitative value to evaluate projects and their ability to be realized. This can follow any range you prefer but we recommend a usable range like 0-10 so that you can re-use this value easily in analytical views like the bubble chart.

Strategic Impact is a generic measure to capture some qualitative value to evaluate projects and their ability to be realized. This can follow any range you prefer but we recommend a usable range like 0-10 so that you can re-use this value easily in analytical views like the bubble chart.

The email address of the person in question.