Solve Problems with Salesforce Well-Architected

The initial release of Well-Architected was focused on using the framework to help you design healthy solutions. It’s also difficult to assess the health of existing implementations and effectively solve architectural issues. This post will dive into the framework’s structure and how it can serve as a map for diagnosing and resolving problems. By familiarizing yourself with the framework’s structure, you will be able to map symptoms to root causes using anti-patterns and leverage the tools and resources provided to implement a healthy, well-architected solution.

Key Takeaways

• Salesforce Well-Architected can help diagnose and solve architectural issues by mapping symptoms to root causes and leveraging relevant resources.
• The framework is organized around Capabilities, Behaviors, and Dimensions, and is a series of white papers with prescriptive guidance, patterns to follow, and anti-patterns to avoid.
• Anti-patterns are the entry point into the framework for most use cases where you’re trying to solve a problem and are already listening for symptoms that indicate architectural issues.

The structure of the framework is meaningful

The framework is organized and prioritized around Capabilities, Behaviors, and Dimensions. You can catch up here if you’re unfamiliar with the framework. In the image above, we zoom into the Trusted capability. The Trusted behaviors are Secure, Compliant, and Reliable, each with its own set of Dimensions. You can read the structure of the framework like a sentence, for example:

A Trusted solution should behave in ways that are Reliable and is represented by Performance.

This post is less about teaching you the taxonomy of the framework and more about how to familiarize yourself with structure so you can find what you’re looking for faster.

The anatomy of a white paper

The framework is a series of white papers for each Behavior. Each white paper details the Behavior’s considerations, prescriptive guidance, patterns to follow, anti-patterns to avoid, and relevant tools & resources from Salesforce. Understanding this structure down to the Dimension can help you navigate the framework effectively, making it a compass for decision-making. These white papers are long, dense resources, so let’s break them down a bit more.

Continuing with the Trusted example, the image below details the anatomy of the Reliable white paper. This structure is consistent across all the white papers.

Each white paper has the following sections:

• Behavior introduction: what is Reliable, and why does it matter?
• Dimensions: what is Performance, and why does it matter?
• Considerations: Throughput Optimization is a consideration of Performance. What is it, and why does it matter?
• Patterns & Anti-Patterns: Tables are organized by Consideration and the Area of the implementation. For example, “Bulkification is not used” is an ant-pattern that is a bad example of throughput optimization (consideration) in your org (area).
• Tools & Resources: Links to help you implement your solutions.
• Feedback: Every white paper has a link because we want more of it!

Now that we feel comfortable with the structure let’s see how we can use the framework and white papers to help you identify and fix the root cause.

Use the framework to fix the problem

Anti-Patterns are things you should avoid in your solution. We see Anti-Patterns as the entry point into the framework for most use cases where you’re trying to solve a problem. If you can identify anti-patterns in your implementation, they might be the root cause of your issues. You’re already listening for symptoms that indicate architectural issues so let’s use the framework to identify the anti-pattern that might be causing it.

Leverage the framework as a tool to help you focus on fixing the issue by following these steps:

1. Listen for symptoms — Symptoms can manifest as negative user feedback, slow performance, org throttling, governor limits, Apex errors, row lock errors, and much more. You can initiate the problem-solving process by actively monitoring and recognizing these symptoms.
2. Identify the root cause — Anti-patterns are the root cause of most architectural issues and likely producing the symptoms you’re seeing. Now that you’re comfortable with the framework structure, you can easily identify the relevant Capability, Behavior, and likely the Dimension that aligns with your symptom. For example, users complaining the system is slow means you should start in Performance. Next, check the white paper to confirm you have the right Dimension. Review its Considerations and the list of anti-patterns to help pinpoint the area of your implementation to investigate.
3. Correct the problem — Finally, use the tools and resources section of the white papers to refactor your solution. Remember to update your documentation based on your solution and create user stories to remove any other occurrences of the anti-pattern before they become a problem.

The table above details some common use cases we’ve used the framework to solve. Here is one example:

• Symptom: Groups of users are saying a report is slow and showing data they don’t need.
• Well-Architected: Trusted → Reliable → Performance → Latency Optimization
• Anti-Pattern: Reports serve multiple purposes or contain extra rows and columns that aren’t needed to make decisions.
• Tools & Resources: Create separate reports so each report serves a single purpose and use Query Optimizer to produce effective queries.

Communicate the value of your work

Effectively communicating the value of your architectural work is crucial. Highlight the impact of the resolved issue with relevant metrics and business context. By presenting a value story, you can demonstrate how your efforts positively impact your company’s goals and how the framework is helping reduce your cost to serve. Check out my Promoting Your Work with a Project Value Story blog post for more info.

I’ll cover this approach in an upcoming Apex Hours session on June 10, 2023. Join me if you have questions about this approach or where Well-Architected is headed.

Additionally, we are continuously improving the framework based on your feedback. We are working on ways to make the problem-solving process even more streamlined. Please keep your feedback coming with the link at the bottom of each white paper. Thank you!