Enterprises are complex organisms, The reality of managing and changing an enterprise is often characterized by volatility, uncertainty, complexity, and ambiguity. This can make enterprises difficult to understand and reason about. To make this task easier we use models. Architecture models identify the significant aspects of the reality of an enterprise and simplify them so they can be more easily understood and analyzed. We create models using data taken directly from the enterprise (for example the configuration management database (CMDB)) alongside data resulting from deeper analysis (for example the results of process mapping). We often expand these models with abstract structures such as capabilities or value streams. The resulting models help uncover the structure and behavior of the enterprise to aid understanding and reveal insights into how the outcomes of the enterprise are achieved.

When it comes to thinking about future states we need to begin our reasoning from the other end, and think first about the outcomes we want to achieve. From that starting point we can begin to design, and analyze or experiment with the structures and behaviors needed to achieve those outcomes. In this way the future state model differs significantly from the model we use to understand our current reality, and it is put to different uses.

The initial conception of a future state is typically in response to seeking an identified outcome. Such outcomes can range from removing an end-of-life technology from the estate, to the complete digital transformation of an enterprise. Future state models can be used to help design and analyze the changes needed to achieve the outcome as well as acting as an important baseline for tracking progress.

Figure.1. The future state modeling value stages and key questions

Future state models can take a number of forms. These include:

Each of these future states comes with its own requirements for design, analysis, and management.

A well managed future state environment can help to provide clarity for delivery, insight for better decisions, and a sound basis for assurance and governance. However, future state models are often ephemeral artifacts captured using informal mechanisms such as whiteboards or diagramming packages. These artifacts can offer a basic level of value as a communication tool but do not provide the additional value that can be achieved through deeper connections to strategy and delivery.

One of the key challenges with adopting a more formal approach to future state modeling is the need to balance varying levels of uncertainty. The further we look forward in time the more uncertainty there is and the less useful highly detailed approaches become. We must therefore balance the needs of short-term detail (with required assurance), medium-term planning (with an open approach to change, both big and small), and long-term vision (providing consistent direction and guardrails).

This article outlines an approach to future state modeling in Ardoq that seeks to address the range of needs presented by different types of future states as well as balancing the requirements for differing levels of detail over time. The article is aimed at supporting answers to the following questions:

The guidance in this article builds on existing Ardoq Solutions, in particular the Strategy to Execution Solution, the Architecture Records Solution, and Solution Healthcheck Solution. It also makes use of the Scenarios module within Ardoq.

Note: This guidance represents the recommended approach to future state and transition architecture within Ardoq based on currently available platform features. Future state and transition architecture functionality will continue to evolve within Ardoq and this guidance will evolve alongside it. For more information on the roadmap for this please see Ardoq Product Portal.

To support this approach to future state modeling there are two new component types with associated reference types. The metamodel incorporating these new component types is shown below:

Figure.2. The future state metamodel

The Objective and Initiative component types are available within the Strategy to Execution Solution. The Decision Record component type is available within the Architecture Records Solution, and the Solution Health Check component type within the Solution Healthcheck Solution.

Organizational Unit and Person form part of the Ardoq Foundation or are also available within the Organizational Modeling Solution.

2 new component types are proposed within the metamodel. These are:

Future State
- A Future State represents the existence of a potential state for a defined, modeled portion of the enterprise architecture. Multiple Future States may exist as target states, target-state options, or transition states between a current and target-state.

Design Object
- A Design Object is a flexible component type that can be used to represent any element within an architectural design. It may act as a placeholder to defer the necessity of using a modeled component type, or can represent elements that are used solely for visualization clarity and/or lie outside of the formal metamodel. It can be specialized using the Object Type field.

Is Parent Of - A Future State component may be a parent of other Future State components if they represent differing levels of granularity for the same overall scope. A Future State will be the parent of any Design Object components created as part of designing and communicating the Future State. For more information see Use of Design Objects in Scenarios.

Has Subject - A Future State component may be created to articulate the future architecture for another component type, for example a Business Capability or Organizational Unit. The Has Subject reference type enables the association of the Future State with the component for which it describes the target state.

Impacts - The Impacts reference helps to identify what components are impacted by the scope of the Future State. This will commonly be component types such as Application, Process, Technology Service etc. The Impact Type field enables differentiation between those components actively changed by a Future State and those that are impacted by the changes to other components.

Note: Impacts references may also exist between an owning Initiative and impacted components. The impact of a Future State will often represent a more detailed subset of the delivering Initiative, especially if multiple Future States are created. Therefore a degree of overlap between these references is expected.

Is Delivered By - A Future State is not an Initiative and it might not be realized without a change process to deliver it. This reference type associates the Future State with the change delivery mechanism.

Note: Whilst a single Initiative may be linked to a number of Future States (as options, transitions, and targets) it is recommended that the scope of the Future State match that of a single Initiative. It is good practice to model multiple Future States with appropriately scoped Initiatives rather than to create a very large Future State to be delivered across multiple Initiatives. High-level Future States may still be created but these should be linked at a programme or portfolio level and kept to an appropriate level of detail.

Is Dependency For - This reference type enables Future States to be linked in a dependency chain to represent transition states and the pathway to a target state.

Realizes - As mentioned in the introduction, Future States are modeled in order to achieve an outcome. The Realizes reference type provides a link to the Objective underpinning the creation of the Future State.

Note: If you are using Initiatives for all of your future states and have already linked your Initiative to an Objective then this reference may not be needed.

References - Matching the flexibility of the Design Object component type the References reference type is able to represent any relationship between a Design Object and any other component type. It can be specialized using the Reference Type field.

Owns - A Future State should have an owner. This should always be a named individual but could also optionally be an organizational unit.

Has Subject - A Future State may be the subject of a Solution Health Check or a Decision Record. Decision Records become particularly important when selecting target states from multiple options or agreeing changes to the Future State scope or Objective.

Future State Status - a list field containing the status of the future state. One of: 'Draft'; 'Proposed'; 'Approved'; 'Rejected'; 'Completed'; or 'Closed'.

Active Period - a date range identifying the time period covered by the Future State

Review Date - the date when the Future State was reviewed and acknowledged as being accurate and complete

Scenario URL - a link to the Ardoq Scenario for the Future State

Document URL - a link to external documentation of the Future State

Object Type - a text field to enable the specialization of the generic component.

Reference Type (References) - a text field to enable the specialization of the generic reference.

For further information on how to implement this metamodel please see the Implementation Steps section.

In this section we will look at the different value producing stages of modeling future states and the techniques and approaches that can be used.

Figure.3. The future state modeling value stages

The first step is to fully understand the purpose of the Future State and the outcome that is anticipated. This might be a relatively small change, such as a reduction in risk from retiring an out of support application, or a much bigger change like digital transformation-driven step-changes in effectiveness. Whatever the scope it is important to ensure there is a link to the Objective (and Key Results) to be achieved as this will be crucial when communicating the rationale for the Future State and when analyzing it in the context of its intended outcome.

It is recommended to follow the Strategy to Execution Solution and use the provided surveys to capture your Objectives and Key Results.

Optionally at this stage, you may also wish to identify an Initiative, or number of Initiatives, that will be responsible for realizing the Objective(s). This can also be achieved using assets from the Strategy to Execution Solution.

Examples:

Figure.4. An Objective with related Key Results

Figure.5. An Objective with related Key Results and related Initiative

Once you have identified the outcome(s) that a Future State is intended to achieve you can begin creating the Future State components that represent the pathway to achieving the outcome(s). Future State components can be used in different ways along the delivery pathway. They may represent options for how an outcome could be achieved, a transitional state on the way to achieving the outcome, or a target state in which the outcome has been achieved. The Future State components can be linked and referenced across all of these uses to build the pathway to outcome delivery.

Note: For longer term objectives and larger initiatives there is no need to build all of the Future States in advance. These can be created and elaborated on a 'just in time' basis to plot a more exploratory route toward an outcome.

The first approach is that of evaluating multiple options for a future state, as is common when generating a business case or approaching a decision gate.

Multiple Future State components can be created to represent the different options. These will typically have a status of 'Proposed' and will have overlapping Active Period dates indicating that they represent independent choices for the same delivery period.

Figure.6. An Initiative with multiple 'Proposed' Future State options

At the point a decision is made, the options not selected can be moved to a status of 'Rejected', whilst the selected option can become 'Approved'. You can also make use of the Architecture Records Solution in order to capture the decision that was taken.

Figure.7. An Initiative with one 'Approved' and two 'Rejected' Future States with an accompanying Decision Record

For information on how these options might be visualized and analyzed please see the sections below on Designing Future States and Analyzing Future States.

The second approach is the definition of a target state. As seen above an option may become a target state once it is approved and competing options are rejected. You may also bypass the creation of options and define a target future state directly. This may be because the target state is self-evident based on the outcome and scope of the initiative, or because it represents a vision-led approach to describing a particular part of the enterprise.

Examples:

Figure.8. An Initiative with a 'Draft' target Future State

Figure.9. Target Future States at the level of parent Programme Initiative and child Project Initiative

Future States may not always be associated with Initiatives and can be directly associated with any component type. It is good practice to relate the Future State to an Objective to clarify its purpose even if this is purely for the aim of providing clarity over direction.

Figure.10. A Future State defining the intended Future State for the Service Delivery Business Capability for the period up to the end of 2027

For information on how these options might be visualized and analyzed please see the sections below on Designing Future States and Analyzing Future States.

Many target states may be of sufficient complexity to require breaking down into increments or phases. This breakdown may be desirable for a number of reasons, for example:

Each transition state will become a dependency for the next, until the target state is achieved.

Figure.11. An initiative with multiple transition Future States toward an ultimate Target State

Figure.12. Initiatives with multiple transition Future States as a timeline

A journey toward a target state may combine all of the future state options above to build a pathway to the achievement of an outcome, or simply map the evolution of the architecture over time.

Examples:

Figure.13. A set of high-level Future State options of which the 'Approved' option is then broken down into lower-level transitions.

Figure.14. A set of Future State options which, on approval, incrementally generate a new set of Future State options

When designing future states a wide range of approaches and techniques may be used depending on the level of detail required, the level of uncertainty and ambiguity present, and the scope of elements included within the future state. This article distinguishes between two key approaches and offers guidance on when these are best applied.

Modeling is an architecture superpower helping to define and understand complex environments. However, models have a 'sweet spot' that dictates where they may be more or less useful.

Models are abstractions of the real world which aim to simplify the environment whilst retaining the elements critical to our understanding of that environment. There is an overhead associated with creating and maintaining these models. It can therefore be unhelpful to use models where the level of precision required is very high as a simplified model cannot be created without losing the required precision. Similarly, smaller or rapid changes may not benefit from the overhead of creating a model to describe them because the overhead of creation and maintenance is greater than the benefit derived from the model.

At the other end of the spectrum are changes that are very loosely defined or ambiguous which will resist a formal modeling approach as the concepts involved may not align well with the more strictly defined concepts in the model. Similarly, very large-scale changes over lengthy time periods may require models to be subject to the overhead of continual revision, may involve concepts that are not within the model, or be modeled at such a high level that they do not provide any meaningful insight.

For those future states that do not fall within the 'sweet spot' alternative techniques may be more appropriate. These will generally result in a number of unstructured outputs such as pictures, documents or presentations. For smaller or more detailed changes this may simply be represented in the technical implementation of the solution (e.g. code) or the description of a change request. For larger changes a range of tools and techniques may be employed from white-boarding to strategy documents.

The key trade-off between approaches is the value that can be delivered from the description of the future state versus the investment in creating and maintaining it.

Figure.15. The utility of future state models

Future States in Ardoq are modeled using the Scenarios feature. For more information about Scenarios see Getting Started With Scenarios | Ardoq Help and Solution Design Using Scenarios | Ardoq Help.

A Scenario supports the creation of a 'to-be' model that captures the additions, deletions, and changes required to deliver the target outcome.

Examples:

Figure.16. A scenario showing the 'As-Is' hosting of the Sales Applications

Figure.17. The same scenario showing the 'To-Be' hosting of the Sales Applications

It is helpful to add the Future State component for the Scenario to the scope of the Scenario. You should also copy the URL of the Scenario and add it to the Scenario URL field on the Future State component to provide a bi-directional link.

Figure.18. The link to the Scenario from the Future State component

If desired the main components impacted or changed within the Scenario can be linked to from the Future State component using the Impacts reference type. The Impact Type field can be used to indicate if this impact is 'Direct' (changes are being made to the component) or 'Indirect' (the component is connected to a directly impacted component with a knock-on impact expected).

In order to provide greater flexibility with the modeled future state approach the Design Object component type can be used to express future concepts and components that might not be fully defined or might be useful for communicating the future state model. For more information see Use of Design Objects in Scenarios.

For future states not captured by a formal modeling approach the Document URL field can be used to provide links to where the future state is described e.g. LucidChart or SharePoint.

Figure.19. The link to the external documentation from the Future State component

In this way future states can be modeled using the most appropriate approach for each future state. For example a multi-transition target state may include detailed modeling for the first future state, high-level modeling for the next transition, and the target state may link to more descriptive documentation. Each future state can then be elaborated in more detail as uncertainty over scope and content reduces.

Figure.20. An example of loosely structured Future State information which can be linked from the relevant Future State component

Once you have designed your future state(s) you can begin to analyze the impact of the changes. In Ardoq there are a number of ways this can be achieved.

The Scenarios functionality provides the ability to visualize changes as a 'diff' between the current state and the 'to-be' state. This enables a straightforward visual analysis of changes that can be included in presentations and used to produce roadmaps. For further information see the Build Application Roadmaps Using Ardoq Scenarios article and the Application Roadmap Scenarios presentation.

Figure.21. A 'Diff' visualization identifying components added, removed, and changed by the Future State

If you have modeled the impacts of the Future State using the Impacts reference as described in Designing Future States you can also create visualizations to present the impacts of change for either individual future states or as part of a roadmap.

Figure.22. The impact of the Future State on existing components

Figure.23. The impact of the Future State timeline on existing components

Once a Future State is defined you may choose to undertake an assessment of it using either a standard or custom quality model. This can be used to identify any risks or technical debt associated with the creation of the Future State as well as ensuring that it meets the identified need and identifying any areas of concern.

This can be achieved through the extension of the Has Subject reference type from the Solution Health Check component type to the Future State component type. The relevant assets (surveys, broadcasts, viewpoints, reports and dashboards) from the Solution Health Check Solution can be copied and updated to include this new reference. For further information see Implementation Steps and the Solution Health Check Metamodel.

Figure.24. A Solution Health Check for the HR SaaS Solution with preliminary results for identified requirements

Figure.25. A Solution Health Check for the HR SaaS Solution with associated comments and recommendations

A further form of analysis is the capture of key architectural decisions related to the design of the Future State and the reasoning behind those design choices. As Future State options are considered and either 'Approved' or 'Rejected', Decision Records can be created and linked to relevant Future States to provide the rationale for the selection. Decision Records may also be created to capture constraints on the target or transition Future States.

This can be achieved through the extension of the Has Subject reference type from the Decision Record component type to the Future State component type. The relevant assets (surveys, broadcasts, viewpoints, reports and dashboards) from the Architecture Records Solution can be copied and updated to include this new reference. For further information see Implementation Steps and the Architecture Records Metamodel.

Figure.26. A Future State with multiple associated Decision Records

Similarly the Technical Debt Management Solution can be extended to indicate the impact of existing or future technical debt on defined Future States. Reference architecture patterns may also be linked to Future States as potential points of communication and governance. These examples are not described further here.

In addition to those examples provided above further custom analysis can be conducted through the addition of custom fields to the Future State component type. This supports the creation, capture, and visualization of any custom analysis as part of the decision-making or roadmapping process.

Figure.27. Future State options with custom analysis fields

Once you have a defined target Future State you can undertake the work to deliver the changes needed to realize it. Depending on the scope of the Future State this could range from small scale 'business as usual' work items to large scale transformation programmes. This can be supported by following the Strategy to Execution Solution to manage your related Initiatives.

The delivery mechanisms and data sources used to enact changes may drive different approaches for the realization of your Future State within your current state model.

For changes that are not automatically reflected in your current state model you can simply update the current state model using the data held within the Future State scenario. This will be the case when the required changes to the model are not provided by automated data updates through either managed integrations or regular data collection mechanisms such as surveys.

These changes may all be realized simultaneously, or may be reflected in your current state incrementally. In the case of a 'big bang' release then all of the data from the scenario can be merged. If changes are released incrementally then only those changes which reflect the current state should be merged, with outstanding changes remaining within the scenario.

Figure.28. Future State achieved and merged into the current state in a single release

Figure.29. Future State achieved and merged into the current state as a series of incremental releases

Ardoq provides a mechanism for merging the data held within the Future State scenario into your current state model. For more information please see How To Merge Your Scenarios And Mainline Data.

Once the Future State is fully reflected within the current state then the status of the Future State can be set to 'Completed'.

For changes that are automatically reflected in your current state model, either through managed integrations or regular data collection mechanisms such as surveys, no merge from the Future State scenario to the current state is required as the data is already updated.

Components and references created in Ardoq that appear in a Future State can then be added to the related scenario to reflect the fact that they have been realized. These components can be merged within the scenario to enable an updated 'diff' visualization which reflects the new current state. For more information please see Merge Components and References.

Similarly components updated in Ardoq can be merged into the scenario to reflect these changes. Ardoq provides a mechanism for merging the current state model into a Future State scenario. For more information please see How To Merge Your Scenarios And Mainline Data.

Note: In order for the merge process to operate the metamodels of the current state and the scenario must be aligned. For further information please see How to Update Your Scenarios Metamodel With Your Mainline Metamodel.

During the course of delivery changes to the scope or content of a Future State may be required. If the Status of the Future State is 'Approved' it may be beneficial to track the decisions driving these changes using related Decision Records. For more information on this please see the Architecture Records, Patterns, and Technical Debt section above.

Once the Future State is fully reflected within the current state then the status of the Future State can be set to 'Completed'.

Once the Future State has been realized it is important to validate that the intended outcomes from the Future State have been achieved, or are on track to be achieved. This can be the result of a simple check or, if a more thorough review is required, a final Solution Health Check may be undertaken to assess the fitness for purpose of the realized Future State. For more information on this see the Solution Health Checks section above.

Once the outcomes of the Future State have been validated then the status of the Future State can be set to 'Closed'.

Figure.30. Future State transitions with 'Closed', 'Completed', and 'Approved' statuses

A Design Object is a flexible component type that can be used to represent any element within an architectural design. It may act as a placeholder to defer the necessity of using a modeled component type, or can represent elements that are used solely for visualization clarity and/or lie outside of the formal metamodel.

The Design Object is a weakly-typed* component type creating flexibility as to how it is used.. The intended purpose of the component can be defined using the Object Type text field. Alongside the Design Object is a corresponding weakly-typed* reference type called 'References'. This can similarly be used to represent any relationship within a reference architecture, being flexibly defined by the associated Reference Type text field.

*weakly-typed: where 'type' information is flexible and held using a field value, rather than fixed in the identity of the component type.

The Design Object was first introduced in the Ardoq guidance on the creation of reference architecture.

Any Design Objects for the Future State should be created as children of the parent Future State. Typically these are created within a scenario.

The main uses of the Design Object are described below:

When communicating Future States it can sometimes be helpful to annotate the visualization with comments or notes to help recipients understand what is intended. Design Objects can be used to hold comments and notes within a scenario and applied to visualizations as needed. This can also be helpful if you are importing a future state from a diagramming tool such as LucidChart. In this context comments and notes within the diagram can be imported as Design Objects rather than being lost.

For more information please see Lucidchart Visual Importer | Ardoq Help.

Examples:

Figure.31. Future State scenario containing Design Objects as 'Notes'

Figure.32. Future State diagram imported into Ardoq via the Visual Importer capturing notes as Design Objects

Figure.33. Future State scenario created by the Visual Importer

Design Objects can also aid the visualization of Future States by representing things not currently within the enterprise metamodel. These might be loosely defined concepts that hold meaning within the business but do not currently conform to a modeled type.

Figure.34. A Future State scenario where a Design Object has been used to group new Applications into the 'Future Product Platform'

As with notes and comments these can be created within the scenario as children of the Future State component.

As described in the section on Models vs Unstructured Approaches, there are levels of ambiguity at which models may become less useful. However it can still be useful to use models which contain 'unknowns' and the Design Object can be used to help model things with a level of ambiguity around if, or how, they might be modeled. This can unlock the value of the model whilst supporting some ambiguous information.

Figure.35. A Future State scenario where Design Objects have been used to represent related concepts that are not yet modeled

These can be created within the scenario as children of the Future State component.

Currently components created within a scenario are not visible outside of that scenario until they are merged back into the current state environment (mainline). However it may sometimes be advantageous to expose new components to the current state in order to improve visibility, create opportunities for synergy across initiatives, and prevent potential duplication. Whilst it would be problematic to merge modeled components that did not yet exist into the current state, Design Objects, as children of the Future State, can be merged back safely without corrupting current state information. In this way more information about the future state can be safely exposed.

Figure.36. A Future State with Design Objects used to indicate new Applications or Technology Services that will be required

Figure.37. Design Objects from Multiple Future States that expose the presence of a 'New Logging Solution' in 2 different scenarios

A new blank workspace called 'Future States' should be created at an appropriate place within your Asset Library. It is recommended to place this either in a new 'Future State Models' folder or to re-use the 'Innovation and Change' folder if you are using the Strategy to Execution Solution. For further information please see How to Create a Workspace.

Figure.38. The Asset Library containing a Future States workspace

Within the Future States workspace two component types should be created. These are:

Fields:

Fields:

Within the Future States workspace six reference types should be created. These are:

Impacts

Fields:

Is Delivered By

Is Dependency For

Realizes

References

Fields:

Results:

Figure.39. Component Types for the Future States workspace

Figure.40. Reference Types for the Future States workspace

Figure.41. Fields for the Future States workspace

To make use of the Solution Health Checks for Future States you will need to copy the 'Review health details…' and 'Select health check criteria..' Surveys that you want to use and update question 2 within the survey to set Future States as the target component type instead of Applications. You can also update any of the associated viewpoints to include the reference to Future States.

Figure.42. Asset Library with Solution Health Check assets to be copied and/or updated.

Figure.43. Question 2 within the Solution Health Check surveys that should be updated to point at Future States

Figure.44. Solution Health Check viewpoints which can be updated to include Future States