

# Improving your workload
<a name="improving-your-workload"></a>

 At this point, you've prepared for the WAFR, completed a review, and assessed your workload against AWS best practices. 

 The output from the WAFR will have identified architectural risks based on the answers captured during the review. These risks are categorized as *high risk issues (HRIs)* and *medium risk issues (MRIs)*. 

 During the last phase, you will create an improvement plan that involves creating a list of risks, understanding their impact on your business, identifying solutions, and implementing those solutions according to your organization's priorities. 

 The following sections provide detailed guidance on the workload improvement process: 
+  Identify and understand risks 
+  Determine prescriptive solutions 
+  Prioritize improvements 
+  Implement and track improvements 

 The following cycle shows the main steps included in the *improvement* phase of the WAFR. 

![\[Improvement cycle\]](http://docs.aws.amazon.com/wellarchitected/latest/userguide/images/improvement_cycle.png)


# Identify and understand risks
<a name="identify-and-understand-risks"></a>

 View identified risks as improvement opportunities. 

 There are two categories of risks in the context of a WAFR: *high risk issues (HRIs)* and *medium risk issues (MRIs)*. 
+  **High risk issue (HRI):** Architectural and operational choices that may cause significant negative impact to a business. A high risk best practice is considered a foundational, must-do practice within a pillar. They may impact organizational operations, assets, and individuals. An example of an HRI from the security pillar is not securing your AWS account. 
+  **Medium risk issue (MRI):** Choices that may also impact your business negatively, but to a lesser extent than HRIs. A medium risk best practice represents an enabling practice that can substantially improve a workload. An example of MRI on the security pillar is not auditing and rotating credentials periodically. 

## Generating a report
<a name="generating-a-report"></a>

 The first step to visually identify HRIs and MRIs is to generate a report that shows the risks for each workload you reviewed. 

 The [AWS Well-Architected Tool (AWS WA Tool) dashboard](https://docs.aws.amazon.com/wellarchitected/latest/userguide/dashboard.html) provides access to your workloads and their associated HRIs and MRIs. You also can include workloads that have been shared with you. Using the dashboard, you can filter the issues by workload, pillar, or by severity (high or medium). 

 In the dashboard page, you can see the list of HRI and MRIs filtered by pillar or severity. Once an improvement item is selected, it takes you directly to the best practices associated with it from the Well-Architected Framework. From there, you can read about the recommended action needed to take to remediate the issue along with necessary resources. 

 You can combine all these findings in one report by choosing [Generate report](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-report.html) from the WA Tool Dashboard. 

 We recommend sending a recap email to the WAFR attendees along with the report, and summarize the key findings and the suggested improvement plan to prepare them for the next step. 

## Managing risks
<a name="managing-risks"></a>

 To effectively manage a risk, it's critical to define the risk and its acceptable level. With risk analysis, explore what the potential problems are and how to know if they are problems. 

 There are two primary methods to conduct a risk assessment: 
+  **Quantitative:** Uses weighted objective data to assess the impact of a risk in terms of cost overrun, resource consumption, and schedule delays. 
+  **Qualitative:** Uses subjective data not tied to the actual values of the cost or benefits to measure the probability and the overall impact. 

 In some cases, you may end up using a hybrid approach that merges the best of both approaches to assess the impact of a risk. 

 When evaluating the level of the risk based on HRI and MRI definitions, consider asking the following questions: 
+  What is the likelihood of risk resulting in impact? 
+  What would be the customer impact? 
+  What would be the business impact as a result? 
+  Can the risk be removed entirely or only mitigated? 
+  Who owns the risk? 
+  Who owns the improvement work to remove or mitigate? 
+  What's the probability that this outcome happens again? Is it likely to cause the same impact? 
+  Can you identify a relationship between the likelihood of an outcome and a pattern of recurrence? 

 Having key stakeholders or business owners answer these questions will help you create a list of the most important risks to focus on along with the projected time to address them. 

## Risk magnitude
<a name="risk-magnitude"></a>

 You can use following table to help you determine risk magnitude: 


|  Likehood x impact  |  Negligible (1)  |  Minor (2)  |  Moderate (3)  |  Major (4)  |  Critical (5)  | 
| --- | --- | --- | --- | --- | --- | 
|  Almost certain (5)  |  5  |  10  |  15  |  20  |  25  | 
|  Likely (4)  |  4  |  8  |  12  |  26  |  20  | 
|  Possible (3)  |  3  |  6  |  9  |  12  |  15  | 
|  Unlikely (2)  |  2  |  4  |  6  |  8  |  10  | 
|  Rare (1)  |  1  |  2  |  3  |  4  |  5  | 

 Work as a group on HRIs and MRIs and the risks they bring to business. Create a list of HRIs that need to be addressed. Rank the risks based on business criticality to establish priority. 

# Determine prescriptive solutions
<a name="determine-prescriptive-solutions"></a>

 Once risks and improvement opportunities are understood in your organization's context, work with the teams on the mitigation. At this phase, each team needs to work on the HRIs found in their areas and determine a prescriptive solution to address the HRI. 

 This step may require additional research, discussions, or building proof of concepts. It's important not to spend too much time jumping into the implementation details of a solution in this phase. It will happen later if you decide that the HRI in question is a priority. 

 The purpose of this step is to understand the complexity of the solution and what resources are required so you can factor them in when prioritizing tasks based on time, complexity, and impact. 

 Work as a group to gather a list of possible solutions for the HRIs. Keep things high level and do not get into implementation details. 

# Prioritize improvements
<a name="prioritize-improvements"></a>

 No organization has unlimited time and resources. Addressing all identified HRIs and MRIs at once might not be the right way to get the most out of a WAFR. 

 Start with a selected number of issues that can make the most impact on the business and that are easier to implement. Work on the solution. Track the improvement, and then iterate on that approach. 

## Prioritize for implementation
<a name="prioritize-for-implementation"></a>

 One approach that can help you visualize solutions priority is the [Eisenhower-style plot](https://www.eisenhower.me/eisenhower-matrix/). There are different ways to use the tool. When evaluating, consider both the importance of the improvement (how much value it brings to your business) and the effort to implement the improvement (time required, complexity to implement, or headcount). 

![\[Eisenhower plot\]](http://docs.aws.amazon.com/wellarchitected/latest/userguide/images/eisenhower.png)


 The output of this analysis provides a set of risks that have the most impact on your business but are not too complex to implement. These are good candidates to start implementing in the first iteration. 

## Solution characteristics
<a name="solution-characteristics"></a>

 When selecting a solution for an identified risk, consider the following: 
+  [https://www.forbes.com/advisor/business/smart-goals/](https://www.forbes.com/advisor/business/smart-goals/) Think of specific, measurable, achievable, relevant, and time-bound (SMART) goals. 
+  **Owners:** For every solution, identify an owner. 
+  **Simple over complex:** Complex solutions can work, but they make the improvement more difficult to implement, and they can take longer to create. Choose simplicity over complexity unless the complex solution is a non-negotiable requirement. 
+  [https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/) Solutions should be extensible and designed to improve and evolve over time. When possible, avoid static solutions that cannot adapt as your architecture develops. 
+  **Target pattern-based solutions:** Consider solutions that can be codified, reused, and re-shared. Don't reinvent the wheel. Access the [AWS Architecture Center](https://aws.amazon.com/architecture/) for examples. 
+  **Work continually as a team:** Work as a group to create a list of solutions for the HRIs. Prioritize them in an Eisenhower matrix. 

# Implement and track improvements
<a name="implement-and-track-improvements"></a>

 The ideal outcome of successful implementations is a reduction in HRIs and MRIs, resulting in an improvement to the architectural health of your workload. 

 Implementation of remediations should be done iteratively, using milestones in the WA Tool that record the state of a workload at a particular point in time. Each time you conduct a review session, or when you complete improvement items, save a milestone to measure the progress as you go. 

## WAFR in agile
<a name="wafr-in-agile"></a>

 The output from a WAFR prioritization exercise can be used to prioritize tickets for sprints and backlogs for development teams. Developers should be able to understand the impact of the implementations and own the contribution to an improved architectural health. WAFR improvement and tracking can be integrated in an agile retrospective. 

 Retrospectives are meetings held at the end of an iteration or sprints. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward. It is an ideal mechanism to include WAFR reviews for discussion and empower members in architectural health. 

## Timeline
<a name="timeline"></a>

 The timeline for these steps varies per organization, as every organization is different and has unique challenges. However, following successful WAFRs performed with many customers at AWS, we recommend this phase to take between 90 and 180 days. 

 If your list of HRIs and MRIs takes longer, re-prioritize them and come up with a shorter list so that you can start practicing the process to get some improvement. Then, repeat with your remaining items. 

## Timeline after the WAFR
<a name="timeline-after-the-wafr"></a>

 **One day after the WAFR:**

1. Create a recap email with the improvement plan, and summarize: 
   + Who was in the review
   + Key findings
   + Timeline for next steps

1. Attach the improvement plan

1. Orient the teams to plan

 **Two to three days after the WAFR:**

1. Create an HRI prioritization meeting, and prioritize HRIs: 
   + By effort
   + By impact
   + With the teams responsible for the workloads

1. Collaborate on what really matters most to the business

 **One week after the WAFR:**

1. Begin the improvement plan

1. Consider the following recommendations: 
   + **Duration:** 90 or 180 days
   + Identify priority HRIs
   + Develop mitigations for each
   + Try to maximize initiatives to solve multiple HRIs

 **Routine tasks:**

1. Build a cadence for follow-up meetings regarding the improvement plan

1. Review actions to take to improve the workload

1. Consider the following recommendations: 
   + Set attendee expectations
   + Send them WA question links
   + Conduct follow up reviews