Handling Requirements, Risk, and Decision Management

The following figure outlines the necessity of requirements management, regular risk assessments, and the need to document architectural decisions.

Requirements Management is important to the following steps:

• It relates customer requirements to the solution's building blocks.
  • If the customer already manages requirements, link to this repository in here.
  • If requirements do not exist, use techniques like Design Thinking for requirements analysis and collection.
• Identify the most architecture-relevant scenarios and personas and define a Minimal Valuable Product (which equates to the solution part that brings quick value with minimal effort).

Regular Risk Assessments will be necessary for the following:

Update requirements periodically (for example, prioritization)

Documentation of Architectural Decisions will be required for taking the following:

• Architectural Decisions for Transition and Target Architecture
• Discussion of architecture alternatives
• Documentation of key decisions

The requirement, risk, and decision management activities will lead to a set of outputs which should be kept at a central phase.

The requirement, risk and decision management activities will lead to a set of outputs which should be kept at a central please.​ These will also be key inputs for the stakeholder management activities.​

Requirements Management builds the center of the ADM. We will explicitly focus on requirements management in general as well as architecture decision making and risk analysis in particular.

The core artifacts are outlined in the following image.

Architecture requirements are identified in all phases of the ADM cycle. Requirements Management is a technique used to document and prioritize requirements across the ADM phases. This also includes the capturing of assumptions and constraints.

Manage architecture requirements along all ADM phases by documenting, prioritizing, updating, reviewing and monitoring functional and non-functional requirements. A Requirement Catalog is a structured document that captures and organizes the functional and non-functional requirements for a particular project, system, or product.

A Requirement Catalog is a structured document that captures and organizes the functional and non-functional requirements for a particular project, system, or product:

• By identifying and collecting high-level business needs, the Requirement Catalog helps in clearly defining what the business aims to achieve, leading to a more focused and aligned approach to project development.
• The refining process ensures that the initial high-level requirements are thoroughly analyzed, leading to purified, clear, and actionable requirements that can be effectively implemented.
• The classification of requirements allows for easier review and tracking. This process ensures that each requirement is considered by the appropriate topic owner and that subsequent analysis is well documented, improving overall project management and communication.

1. Document all the identified high level business needs / requirement

2. Classify requirements if they are functional or non-functional. Non-functional requirements can be classified using classes of NFR

3. Categorize requirements based of Business capabilities - strategic business requirements

4. Categorize requirements based of Business process – operational business requirements

5. Maintain additional attributes for business requirements e.g.

• Status
• Priority
• Owner

Example of tools: JIRA, excel…

Requirements are structured by different categories in a clear hierarchy.

Functional Requirements and Transition Requirements are explained in the following way:

• Functional Requirements are the bridge between the business and technical teams and provide the definition of what the system must do for its users that will in turn meet the business goals. Some methodologists believe that functional requirements can be described using only use cases or user stories, but this appears to be a purist view and in practice there seems to be a need for detailed textual requirements that describe what the architect must design and the developer must implement.
• Transition Requirements define what is needed to transform the business and systems from the current state to the future state. They define a transitory situation, and when the system has been fully implemented, the requirements and their implementation will not be visible. They define things such as the training, conversion, and reformatting of data and parallel runs of business and technology systems.

• Availability: "The degree to which a business process needs to be available." Availability is the ratio of time a system or component is functional against the total time it is required or expected to function. This is typically expressed as a percentage (for example, 90%). It can also be expressed in terms of average downtime per week, month or year or as total downtime for a given week, month or year.
• Performance: "The degree to which can perform function in an appropriate time." Performance is the total effectiveness of a computer system, including throughput and individual response time. This is the whole system holistically and is an end-to-end consideration from the end user right through to the service providing application.

• Scalability: "The degree to which can support changes in volume and criticality, up or down." Scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged

• Extensibility (openess): "The degree to which can add or reuse functionality with minimal effort and complexity." Extensibility means the system is designed to include hooks and mechanisms for expanding / enhancing the system with new capabilities without having to make major changes to the system infrastructure.

• Interoperability: "The degree to which can be integrated with other systems with minimal effort and complexity." the ability of two or more systems or components to exchange information and to use the information that has been exchanged

• Access: "The degree to which can protect information from unauthorized access." Ensuring that users access only those resources and services that they are entitled to access and that qualified users are not denied access to services that they legitimately expect to receive

• Locality: "The degree to which can support languages, currencies and other regional formats."
• Learnability: "The degree to which can be readily learned by all users." Measure of a software product that enables the user to learn how to use it and is of major concern in the design of complex software applications.

• Support: "The degree to which can get support when and where needed."

  • Assistance that is available either via a vendor or an internal support team to resolve problems. Support capabilities vary widely, from nothing at all right through to a 24x7x365 capability.
  • Support must be commensurate with a level required to guarantee the SLA and OLA’s of the business function and no greater than that, costs rise steeply the higher level of support you request.

Risk analysis and mitigation is an important enterprise architecture skill set.

There will always be risk associated to your architecture. Therefore, it is important that you identity, classify, and mitigate risks. You distinguish between an initial level of risk, which is the risk prior to implementing mitigation actions, and a residual level of risk, which possibly remains, even after your mitigating actions.

Practitioners are encouraged to use their corporate risk management methodology or extend it using the guidance in this chapter. In the absence of a formal corporate methodology, architects can use the guidance in this chapter as a best practice.

This image shows a spreadsheet designed to help you manage and reduce risks within architectural projects following the Risk Analysis Process. This figure illustrates the following four aspects of this process:

1. Risk Identification: We classify risks across different architectural domains like Business, Data, Application, and Technology to understand where they might impact our architecture.
2. Initial Assessment: Each risk is evaluated based on its probability and impact, helping us prioritize which risks need immediate attention.
3. Mitigation Strategy: We outline actions to reduce the identified risks, ensuring we address potential issues before they escalate.
4. Residual Risk Evaluation: After applying mitigation strategies, we reassess the risks to ensure they’re effectively managed and pose minimal impact.

The risk analysis process involves identifying potential risks that could impact architectural domains like Business, Data, Application, and Technology. When risks are identified, they are assessed based on their likelihood (probability) and potential impact. Mitigation strategies are then developed to reduce these risks, either by lowering their probability or impact. After mitigation, the remaining (residual) risks are reassessed to ensure they are within acceptable levels. Continuous monitoring is essential to update the risk management approach as the project evolves, ensuring ongoing protection against potential threats.

Field Descriptions

• Risk ID:

  Description: A unique identifier assigned to each risk for easy tracking and reference.

• Risk:

  Description: A detailed description of the potential risk or issue that could affect the architecture or its implementation. This should include the nature of the risk, such as what might cause it, and the potential outcomes if the risk materializes.

• Architectural Domain:

  Description: The specific area of the architecture that is affected by the risk. This could be categorized into different domains such as Business, Data, Application, or Technology, depending on where the risk lies.

Initial Risk

• Effect:

  Description: The severity of the risk's impact on the architecture if it occurs, before any mitigation actions are taken. This can be categorized as Catastrophic, Critical, Marginal, or Negligible.

• Frequency:

  Description: The likelihood of the risk occurring. It should be categorized as Frequent, Likely, Occasional, Seldom, or Unlikely.

• Impact:

  Description: The overall potential impact on the project or architecture should the risk occur, assessed in terms of High, Medium, or Low.

Mitigation Strategy

Description: Actions planned or taken to reduce the likelihood of the risk occurring, or to minimize its impact if it does occur. The strategy should address the identified risks and outline the steps to manage them effectively.

Residual Risk

• Effect

  Description: The expected severity of the risk's impact after mitigation strategies have been applied. This is reassessed based on the effectiveness of the mitigation measures.

• Frequency

  Description: The likelihood of the risk occurring after mitigation strategies have been implemented. This is reassessed to see if the frequency has been reduced.

• Impact:

  Description: The reassessed impact on the project or architecture after mitigation, categorized as High, Medium, or Low, reflecting the residual risk remaining after the mitigation.

This image is an example of a completed Risk Assessment using the Assessment template.

Architecture decision taking is an important enterprise architecture skill.

Architecture decisions are design decisions that address architecturally significant requirements in a given context and with known consequences. Architecture decisions are documented, communicated, and governed.

Architecture decision making requires strong stakeholder management to derive a common conclusion that will last for a longer period and will have an impact on the overall architecture.

Architecture decisions are design decisions that address architecturally significant requirements in a given context and with known consequences. Architecture decisions are documented, communicated, and governed.

Architecture produced after decisions is not only late but may cause conflict. At best, the architecture will validate the decision. Given the decision has already been made by leaders with the authority to make the decision, validation is pointless. At worst, the architecture will demonstrate the leaders made the wrong decision. It is technically useful to gain this knowledge and perform a course correction. The damage to the EA team and wasted time and effort executing the next steps following the decision are unlikely to be compensated by a better decision.

Architecture produced after decisions is not only late but may cause conflict. At best, the architecture will validate the decision. Given the decision has already been made by leaders with the authority to make the decision, validation is pointless. At worst, the architecture will demonstrate the leaders made the wrong decision. It is technically useful to gain this knowledge and perform a course correction. The damage to the EA team and wasted time and effort executing the next steps following the decision are unlikely to be compensated by a better decision.​

The given example outlines multiple documented architecture decisions. These need to be made available and accessible to a broader audience.​

This is another example of how architecture decisions can be documented.

This is another example of how architecture decisions can be documented.

This is an example of how SAP LeanIX can be leveraged for documenting architecture decisions.​