Ardoq’s approach to Strategy to Execution gives you the ability to define, monitor, and adjust your strategic objectives and how they are being delivered in response to changing business conditions.

Contents

More than half of Enterprises are failing in achieving their strategic objectives according to a survey by Gartner, Inc [Gartner 2022]. Similar statistics have been reported for the last few decades. For instance: [Kaplan 2005]:

In addition, an IBM survey of Fortune 1000 CIOs found that, on average, CIOs believe that 40 percent of all IT spending brought no return to their organizations* [Enterprise Value 2008]

Ardoq’s approach to Strategy to Execution allows everybody to understand the prioritized enterprise objectives, how they are being delivered, who is involved, and enables reprioritization as changes occur.

The first version of Strategy to Execution provides insight across objectives, initiatives, capability changes and impacts to applications and organization units. Subsequent iterations will deepen support for prioritization and benefit realization.

The primary stakeholders for Ardoq Strategy to Execution are the company roles who are responsible for execution:

CEOs and CFOs are also relevant stakeholders because the company as a whole is receiving the value from the Strategy to Execution outcomes. But they are usually not active in the S2E process execution.

A guiding principle for Ardoq is to monitor and measure metrics to show that you are delivering value to the business. The following is a list of possible metrics that can be measured to show the benefit of Strategy to Execution. A subset of these is implemented in the Ardoq use case and is detailed later in this document. You can extend the use case with your own metrics that will measure the value of the benefit you are delivering with S2E.

These metrics are derived from industry sources on Strategy to Execution, Value Realization and Benefits Management. That research shows a significant correlation between successful companies and those that:

Ardoq’s strength is to provide up-to-date insights from complex, interconnected and dynamic information that is updated across the entire company.

This document describes the purpose, scope, and rationale for the Strategy to Execution Series. It will be updated as new versions of the Use Case are released.

The scope of the Strategy to Execution Series is defined by the following sets of questions for enterprise stakeholders. They can be summarized as: what are we doing, why are we doing it, and what benefit will it bring to the organization?

Each of these questions is used to create a slide in an Ardoq presentation, report, dashboard and/or a Discover viewpoint that is provided together with the use case sample data.

Ardoq’s Strategy to Execution implementation starts with Objectives & Key Results (OKRs). This section explains the concepts and rationale. The complete details are provided in the Strategy to Execution Metamodel document.

There are many approaches to representing strategy and objectives in enterprise architecture frameworks. For example, BizBOK describes multiple approaches to modeling this area and provides a definition for the Strategy Domain of The Business Architecture Metamodel. Similarly, Archimate provides a detailed set of Motivation elements that cover this area, while BTABoK from IASA, provides its own description about how to model Strategy. And there are many more approaches in the industry.

One of Ardoq’s principles for EA modeling is to focus on usefulness over precision detail. Our analysis of the industry, and our customer base, shows that there is no common or even primary approach that enterprises use. It is one of multiple strategy definition frameworks that are available, for instance, balanced scorecards, a more informal approach such as OKRs, or their own ad-hoc approach to strategy definition. That research also shows that successful EAs use an approach that captures Strategy & Objectives as they are utilized in their company rather than specified in an EA framework. Discussions with our customers and partners showed that EAs that used formal strategy and objective metamodels from EA frameworks were less successful in getting them adopted as a common tool between Business and IT.

OKRs provide an approach that is used successfully by many organizations and is simple enough to also be adapted to ad-hoc usage. The purpose of the Strategy to Execution Use Case Guide(s) is to help organizations answer the questions posed earlier in this document. That requires a simple way to connect the strategic objectives of the enterprise to the initiatives that are ongoing, where the impact will be, and the benefits they will provide. And, from a bottom-up perspective, what is the company working on, why are they doing it, and how do they know if they’re being successful. This requires less precision in modeling the goals, visions, strategies, and motivations of the enterprise and more about the interconnections between objectives and execution.

Ardoq’s metamodel flexibility allows users to extend the initial set of concepts provided in the Use Case Guide to use a more detailed strategy and objectives model from one of the previously mentioned frameworks. The configuration needed to aggregate information from execution concepts to objectives would then need to be modified to suit.

The Objectives workspace provides concepts for Objectives and Key Results. Key Results are part of an Objective (parent-child relationship) and there can be relationships between Objectives.

Key Results are optional. Users can choose if they want to use these components for a full OKR implementation or if they only want to use Objective components in a more informal approach.

We use the Objective component type to represent both strategies and objectives. Our research shows that it's more important to deliver insight into the relationship between strategy and execution than it is to have high-fidelity differentiation of concepts about business motivation.

We recognize that a strategy is conceptually different to an objective. A strategy is a broad approach taken to achieve an organizational goal or vision, whereas an objective is a measurable step taken to achieve that strategy. However, from a structural perspective, strategy and objectives can be implemented using the same component type - the Objective component. A strategic objective may apply over a longer time span and may not have specific key results. Using one component to represent both strategy and objective allows the Use Case to more easily aggregate progress and investment information between these concepts.

Another reason to use the Objective component type for both strategies and objectives is that it makes it easier to analyze relationships from a single component type to allow information about cost, progress, and status to be aggregated from connected components, such as Capabilities and Initiatives, up to the Objectives.

Ardoq recommends having Objectives that are aligned throughout the organization. There is significant discussion in the industry about cascading versus aligned OKRs. We provide the ‘Is Supported By’ reference type to define relationships between Objectives. Users can choose whether this reference should represent aligned or cascading relationships.

The ‘Is Supported By’ reference is used by the use case to aggregate progress and cost/budget information between Objectives. The Strategy to Execution metamodel document explains the algorithm in more detail and how users can configure it to their specific context.

All active Objectives should be realized by at least one Initiative, as described in the next section. The cost, budget, and progress fields on an objective are calculated values from those connected Initiatives. Users that want to use OKRs without connected initiatives need to extend the component definition with manual fields to capture those attributes.

Objectives have an additional field for completeness. This field is manually set and captures the final percentage completeness achieved for an objective. OKR Objectives are recommended to be set so that teams achieve approximately 70% completeness. We use this manual field in addition to the progress field which is automatically calculated based on the progress of Initiatives that realize the Objective. Users can adjust how they use these fields based on how they define objective progress and their adherence to OKR techniques.

Objectives, and Initiatives which will be detailed later, contain a field for categorizing the strategic investment type. One of the goals of this use case is to improve investment in initiatives according to strategy. This field classifies objective and initiative investments so you can measure the ratio of investment that focuses on improving the business compared to simply running the business. The categories follow the Gartner recommendations for investment classification:

Note: Grow and Transform can be grouped into a single category for Change.

Finally, if your organization is successful at using a more sophisticated approach to business motivation, such as the metamodels defined in BizBOK or Archimate Business Motivation Model, then you can easily extend the concepts in this workspace to implement those concepts or use Ardoq’s existing Archimate workspace template directly.

The Key Result component type can be confused with the existing Metric component type. It is correct that both these types capture a quantifiable benefit and that the Metric component type could be used in place of a Key Result. However, we provide the Key Result component type for the following reasons:

An Initiative represents work to be done to deliver on Objectives. As a rule of thumb, an Initiative is something that has its own prioritization and investment decision. Initiative descriptions can be at multiple levels of detail and Initiatives can be hierarchic - Initiatives with sub-Initiatives - so it is possible to have a detailed hierarchy of Initiatives that are maintained within Ardoq. Additionally, Initiatives can be linked to project management issues that are imported from external tools, such as JIRA.

Initiative components can have two types of relationships to other Initiatives:

Aggregation of progress and cost information occurs from Initiatives to Objectives. These follow the ‘is Realized By’ reference and only happen from the Initiative component directly connected to the Objective. There is no aggregation within an Initiative hierarchy. Aggregation roll-ups do not follow dependency relationships.

Figure: model of an Initiative hierarchy with multiple child Initiatives as part of a larger Programme

An important part of Strategy to Execution in Ardoq is to connect strategy to actual execution tasks. In addition to the hierarchy of Initiative components defined in Ardoq, it is possible to import tasks from external issue- and project-tracking solutions. Ardoq is working on an improved JIRA integration that will allow import of projects, epics and tasks. Organizations that use other tools can use Ardoq’s Excel import or custom integration capabilities. The Strategy to Execution use case provides a JIRA Excel import configuration that can be used until the integration is ready. This can also be used as an example to create an excel import from other tools. Import from tools other than JIRA should create a workspace with a similar structure to JIRA Import workspaces and not as a replacement for Change Initiative components.

These two workspaces - Initiatives and tasks imported from external issue trackers - provide two options for representing execution tasks. Users can choose if execution tasks should be represented as Initiative components directly in Ardoq or as components imported from external solutions or as a combination of the two. However, it is necessary to have at least one Initiative component that connects Objectives to items imported from issue- and project-tracking solutions. That is, Objectives are only connected to Initiatives, not to imported tasks from issue tracking tools. Companies use issue-tracking tools in different ways that depend on their approach to project development. Some create separate projects with a full hierarchy of epics and tasks. Others use projects as an agile team backlog that may consist of individual tasks related to separate company Initiatives.

Companies use issue-tracking tools in different ways. Therefore it is necessary to have at least one Initiative component that acts as a connection point between these imported tasks and the Objectives and Capability Delta components. This is to allow our analysis scripts to aggregate progress, dates, and cost information from executing tasks to the relevant Objectives and Capability Deltas in Ardoq. Additionally, because companies use issue-tracking solutions in different ways we have not implemented aggregation of information, such as status, from imported tasks to the Initiative components defined in Ardoq. Contact your CSM for help on how to do this based on your context.

Users can utilize the following alternatives:

The choice of alternative impacts how you will aggregate and connect information. The Use Case Guide provides pre-built support to aggregate budget, cost, and progress information from the Initiative components to the Objectives that they realize. The full details are provided below. Aggregation of information from execution tasks to Objectives is limited to the reference from the first Initiative component referenced from an Objective component. That is, it does not traverse the hierarchy of Initiatives - though the algorithm can be extended to do that if it matches your context. This is explained in more detail later in this document.

Objectives have an ‘Is Realized By’ relationship to Initiatives. An Objective can be realized by multiple Initiatives and Initiatives can realize multiple Objectives. This reference is used to aggregate progress, budget, and cost information to Objectives. It is the responsibility of each user to understand how that information is aggregated when there are many-to-many relationships. This is especially important when aggregating cost information.

Figure: Visualization showing OKRs where the Objective name includes the [current progress percentage] that is aggregated from the Initiatives which realize the Objectives. Also shows color heat-map based on the objective priority.

The Folder component type in the above figure is used to group Objectives and Key Results within a workspace. Each Objective should be owned by an Organization Unit and by an individual Person (see Reference Types below), and these relationships can be used to create visualizations that group Objectives using those relationships. However, Organization Unit and Person exist in separate workspaces from Objectives, and because there is no parent-child relationship between Objectives within the workspace, this can result in many Objectives existing at the top-level of a workspace view.

Opening a workspace with a view that shows the entire workspace, for instance, Dependency Map, will result in many Objectives being visualized. The Folder component can group this large number of Objectives to help manage the visualization. Ardoq recommends using a folder structure that replicates the Organizational Unit ownership relationships. Folder components have no additional fields and are used only for cosmetic purposes.

References should be made from Initiatives to the Capability Deltas they realize. The reference between Capability Delta and Initiatives use the date range of the initiative to calculate the effective date range of the Capability Delta. If you connect from an imported task to the Capability Delta then that imported task will need the same field type so the effective date range can be calculated on the Capability Delta. More detail is provided in the metamodel description. See the section on Capability Delta for more information.

Knowing where Initiatives will impact the organization - both the Business and IT aspects - is important for answering the scope questions mentioned at the beginning of this document. The impact on the Business is captured with Impacts references between Initiatives and both Business Capabilities and the Organization Units that realize those capabilities.

Business and Technical Capabilities should already have Is Realized By references to the Applications and Organization Units as a result of performing the Business Capability Realization Use Case. It is necessary to create Impacts references in addition because there could be multiple applications and teams that realize a capability. The impacts reference identifies which ones are impacted to deliver a specific capability delta for a particular change initiative.

Scenarios are an important way to depict the impact of Initiatives. The Impacts references are a supplement to scenarios and are not meant as an alternative. Using these references in addition to scenarios provides the following advantages:

The Impacts references can also be easily archived when the Initiative has been completed. See the following section on the temporal nature of Strategy to Execution information.

Figure showing impacts of the “Implement New Enterprise Architecture Tool”

Figure showing a scenario of the “Implement New Enterprise Architecture Tool”

It is important to define both where the impact of a change initiative will be and what the business benefit of those impacts will be. This is needed in Strategy to Execution to both highlight needs and benefit realization as well as to collect information needed for prioritization of proposed Initiatives. A business capability model is mostly stable over time. Capability components contain fields to define, for example, their maturity level but they don’t capture small improvement information that comes from specific change initiatives that exist for a relatively short period of time. As a result, we have created the Capability Delta component type to capture that information.

A Capability Delta represents a change to a Capability. Usually, that is a gap or improvement for an existing capability. That change may be an identified required change, i.e., a capability gap found during capability-based planning, or it could be an improvement that will be delivered as part of an Initiative. Sometimes a business objective requires the creation of whole new capabilities or the removal of capabilities as part of a business divestiture. A Capability Delta component can also represent the initial creation or removal of a capability. The concept of a Capability Delta is similar to the concept of a capability increment found in TOGAF.

Capability Deltas represent the business change needed for an objective and/or the benefit delivered from one or more Initiatives. A Capability component has ‘Is Impacted By’ references to one or more Capability Delta components. A Capability Delta is also the target of Realizes references from one or more Initiatives.

A loop of references will exist between Objective, Initiative and Capability Delta components, which may seem like duplicate information. However, this is necessary because of the processes that connect them together. Sometimes companies start with Objectives, then define Initiatives, and finally specify Capability Deltas as part of the business case development for the Initiative. Alternatively, a company may start with an Objective, then perform capability-based planning to identify Capability Deltas (gaps), which will later be realized by planning Initiatives. Users may end up with a loop of references but the process to get there will happen over a period of time and it may be necessary to create Capability Delta components from either the Objective or Initiative first.

Figure: Timeline showing projects and capability deltas as a roadmap. The visualization can be filtered to only show capability delta components for a business-only roadmap

Capability Delta components aggregate the datetime information from the Initiatives that realize them. As a consequence, they can be used to visualize the business roadmap for the organization. For instance as a timeline of business improvements to be delivered.

A Capability Delta will be created when a gap is identified to realize an Objective or when defining the business benefit of a proposed Initiative. The component will be relevant during the lifespan of the Initiative, or while the Objective remains relevant. But when the Initiative is finalized and the Objective is met then the maturity level of the Capability itself is adjusted and the Capability Delta component is archived. See the discussion below on the temporary nature of particular Strategy to Execution components. The current use case does not automatically update the maturity level when the referenced Initiatives are completed. But that could be included in a future iteration.

All concepts defined in our Use Case Guides have an inherent lifecycle. Applications, IT Infrastructure, and Business Capabilities will continuously change and eventually be replaced. But those concepts will exist in EA models for long periods of time that are usually measured in years.

The concepts for Strategy to Execution, such as Objectives, Initiatives, impact references, and Capability Deltas, usually have much shorter life-cycles that are measured in months. Additionally, the volume and frequency of change for these concepts are much higher than 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.

Techniques for achieving this are discussed in Navigating the Transient Nature of Strategy to Execution.

The goal of Ardoq is to provide data-driven business insights and benefits by automating many aspects of your execution processes. This entails:

The Strategy and Objectives execution process is depicted as a simplified state-machine with defined states in the process and the trigger events between those states.

The following section describes the stakeholders, information requirements, and trigger events in more detail.

Each process state has the triggers (events) to enter the state, the stakeholder who is triggered and the information that stakeholder needs to provide or consume. This is then used to execute the process through Ardoq. Using this process definition allows you to identify:

The Initiative Execution process is also described as a simple value chain. Organizations use many different initiative or project management processes. We have provided a simple process that can fit into your own organization - whether they are using a centralized PMO execution process or a fully distributed agile business approach.

Each process state has the triggers (events) to enter the state, the stakeholder who is triggered and the information that stakeholder needs to provide or consume. This can be used to execute the process through Ardoq. Using this process definition allows you to identify:

References

Gartner, Tomas Nielsen. “Turning Strategy Into Reality — How to Successfully Execute on Your Strategic Goals.” Presented at the Gartner IT Symposium / Xpo, Barcelona, Spain, November 2022.

Enterprise Value: Governance of IT Investments : Getting Started with Value Management. Rolling Meadows, Ill.: IT Governance Institute, 2008.

Robert S. Kaplan and David P. Norton. “The Office of Strategy Management.” Harvard Business Review, 2005.

Change Log