The Architecture Development Method (ADM) of the TOGAF Standard describes a number of techniques a practitioner has at his disposal. Since Risk Management is addressed in several phases (A and E through H), it can be seen as an integral part of architecture development. Applying Risk Management techniques ensures that risks are identified, assessed, and mitigated as part of the architecture development process.

Risk and the ADM

According to the TOGAF Standard, Risk Management is specifically addressed in the following phases of the ADM:

• Phase A: Architecture Vision: An initial risk assessment is performed to identify high-level risks. The risks identified during Phase A are captured in the Statement of Architecture Work document.
• Phase E: Opportunities and Solutions: Gap analysis allows for the discovery of risks related to the implementation of the Target Architecture. Phase E also evaluates risk mitigation strategies and ensures that risk considerations influence the selection of implementation approaches.
• Phase F: Migration Planning: Risks standing in the way of a successful implementation and integration are identified. This phase also ensures that mitigation plans and fallback strategies are in place.
• Phase G: Implementation Governance: Managing risks from this phase ensures compliance with the architecture specification and governance standards. Phase G addresses emerging risks through governance oversight.
• Phase H: Architecture Change Management: Continuous risk monitoring is performed during Phase H with respect to changes to the architecture. Phase H implements risk response mechanisms as part of change management.

There are a few phases of the ADM in which Risk Management is not explicitly addressed:

• Preliminary Phase: Focuses on Architecture Governance and Architecture Capability setup, but does not perform a risk assessment.
• Phases B, C, and D: Do not formally include Risk Management, although risks may be informally identified within the architectures. These risks are recorded during Phase E.

Difference between Techniques

There is a difference between the technique called Risk Management and Enterprise Risk Management. The technique described in this blog is a simplified version of the comprehensive Enterprise Risk Management. The latter is described in great detail in the Series Guide “Integrating Risk and Security within a TOGAF® Enterprise Architecture”.

Risk Management in the TOGAF Standard primarily focuses on architecture project risk. This is only one type of risk. The scope of Enterprise Risk Management, as presented in the “Integrating Risk and Security within a TOGAF® Enterprise Architecture” Series Guide as part of the Enterprise Security Architecture, is much broader. It includes business, system, information, project, privacy, compliance, and organizational change risk, among other categories, too¹.

Types of Risk

When a risk is identified, the first thing to consider is whether it is an initial (preliminary) risk or a residual risk. The former indicates a new, previously unaddressed risk, while the latter concerns a previously encountered – and possibly (partially) mitigated – risk. The approach is different for each type of risk.

For an initial risk – a categorization given to a risk prior to identifying and implementing mitigating actions – the Risk Management technique should be applied. Existing or residual risks have usually already been accepted and mitigating actions implemented. Figure 2 illustrates the difference between initial risk, residual risk, and mitigating factors.

The Technique Explained

The technique of applying Risk Management consists of a number of steps. First, risks are typically classified as time, cost, and scope, but can also include contractual, technology, and complexity risks. In addition, risks can be classified by architecture domains or segments. The Risk Management technique involves identifying the Baseline and Target Architectures, and the work packages required to arrive at the Target Architecture. The consequences of not achieving the Target Architecture can lead to the discovery of risks.

Risks are classified by impact and frequency according to scales used in the organization. When impact and frequency are combined, they create a preliminary risk score which can be visualized in a Risk Heat Map.

After the risks are identified and classified, they need to be mitigated (or at least as much of the risk as possible). This means reducing the risk to an acceptable level. Once the initial risk has been mitigated, the remaining risk is referred to as residual risk. The key consideration is that the mitigation effort actually reduces the impact to the organization and does not simply move the risk to another similarly high quadrant. One final step of the Risk Management technique involves tracking and updating risk assessments over time. Once the residual risks have been accepted, the implementation of mitigating actions must be carefully monitored. This is to ensure that the organization is dealing with residual risks rather than initial risks. Phase G (Implementation Governance) is where risk monitoring takes place.

Risk Classification

Effective Risk Management is critical for organizations seeking to protect their objectives and operations. A structured approach to risk classification enables rapid and appropriate mitigation strategies. A common method is to categorize risks based on their potential impact on the organization. This approach ensures that risks with significant impact are escalated to the appropriate governance levels, facilitating timely and effective responses.

Risks are often neatly categorized. This segmentation helps identify and effectively address potential pitfalls. Primary categories include:

• Time (schedule) risks: These pertain to delays that can derail project timelines.
• Cost (budget) risks: These involve expenditures that exceed the allocated budget.
• Scope risks: These arise when there’s a deviation from the project’s defined objectives.

Organizations may have unique categorizations tailored to their specific contexts. It’s advisable for the Architecture Capability of the organization to adopt or extend these classifications to maintain consistency and relevance.

Risk Identification

During the execution of Phases B, C, and D of the Architecture Development Method, the Baseline and Target Architectures are formed. The gaps between these architecture states will undoubtedly allow one or more risks to surface. Identifying these risks is critical because it allows organizations to develop strategies to address them throughout the transformation process.

In Phase E: Opportunities and Solutions, identified risks are captured and further detailed in a catalog. This catalog is then used during Phase F to proactively address the risks.

Documenting how to approach the identified risks is typically done in a Risk Management Plan. Such a plan contains at least three basic components:

• Document information: For instance, the project name, date, and author of the document, including the version number.
• Approvals: A list of the dates, names, and signatures of the people who approved the approach described in the document.
• Approach: A detailed description of how risks will be managed. It also includes a summary of the tools that will be used and an outline of the information that will be recorded. Perhaps more importantly, it defines the metrics that will be used to classify risks. Risk tolerance is also described in the document.

Project management methodologies such as the Project Management Body of Knowledge (PMBOK) and PRINCE2 typically include procedures for contingency planning, tracking and assessing risk levels, responding to changes in risk factors, and processes for documenting, reporting, and communicating risks to stakeholders.

To Be Continued…

Next month’s blog post will continue the explanation of the Risk Management technique. Then, I will discuss how to perform an initial risk assessment, determine impact and frequency, and monitor and visualize risk.

1. The Open Group, “TOGAF® Series Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture,” G152, 2022. ↩︎