Make Solutions Adaptable
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the importance of building an adaptable solution.
- Follow Salesforce Well-Architected best practices for building an adaptable solution.
Future-Proof Your Solution
In the dynamic business world of today, change is a constant. Adaptable solutions evolve with the business. That's why adaptability is so important for architects. A solution well-architected to be adaptable is resilient and composable.
Resilient Solutions Handle Change Well
To design a resilient solution, prioritize three dimensions: application lifecycle management, incident response, and continuity planning. Whether it's customer demands, market shifts, or digital transformation, an adaptable solution enables businesses to not only survive, but thrive in times of change.
Composable Solutions Adjust Quickly and with Greater Stability
To design a composable solution, prioritize three dimensions: functional units, interoperability, and packageability. It's important to have a clear understanding of the business’s current and future trajectory to design a solution that can adapt to different scenarios and different business units. You must consider the impacts of changes on multiple dimensions, including people, processes, and technology.
Change is inevitable. Without an adaptable solution, businesses may struggle to keep up with these changes and can even fail in the long run. On the other hand, an adaptable solution enables businesses to innovate and seize new opportunities that arise from changes.
You might be wondering how you know if you’re thinking about the dimensions highlighted above in the right way. Never fear, Salesforce Well-Architected has you covered here. There are a series of key concepts architects need to consider when designing adaptable solutions. In the next section we’ll cover the patterns you can follow to ensure you’re considering all the right things!
Follow Well-Architected Best Practices for Building an Adaptable Solution
The following is a list of best practices for building an adaptable solution. This isn’t an exhaustive list, but something to help get you started. Always refer to the adaptable patterns and anti-patterns as you roadmap and design your solution.
Resilient Patterns
This table shows you a few examples of what good looks like when designing a solution that handles change well. It also shows you the location where you can look for the presence (or absence) of the pattern, and how this pattern maps to the dimensions, linked first, and considerations, linked second, in the Well-Architected white papers where you can learn more.
Patterns: What Does a Good Pattern Look Like? |
Location: Where to Look? |
Resources: Learn More About Dimensions | Considerations |
|---|---|---|
A recovery-first mindset is adopted with a focus on bringing the highest priority business functions and capabilities out of impact as soon as possible. |
In your business |
|
The areas of your BCP (business continuity plan) related to processes and people are accounted for. |
In your test plans |
Continuity Planning | Building Backup and Restore Capabilities |
Test plans and test logs show data restores are tested in a full or partial copy sandbox at least two times each year. |
In your company |
Continuity Planning | Building Backup and Restore Capabilities |
Features are tied clearly to a specific, named release. |
In your roadmap |
|
Release paths for a change depend on the type of the change (high risk, medium risk, low risk). |
In your org |
|
You include scale testing as part of your QA process when you have B2C-scale apps, large volumes of users, or large volumes of data. |
In your business |
|
Teams know what services in production they are responsible for owning. |
In your business |
|
SMEs or stakeholders who should be alerted to support complex issues are identified before an incident occurs. |
In your business |
|
Alerts are only used to inform users of scenarios that require human intervention; other failures are logged and reportable. |
In your org |
This table shows you a few examples of what good looks like when designing a solution that adjusts quickly with stability. It also shows you the location where you can look for the presence (or absence) of the pattern, and how this pattern maps to the dimensions, linked first, and considerations, linked second, in the Well-Architected white papers where you can learn more.
Patterns: What Does a Good Pattern Look Like? |
Location: Where to Look? |
Resources: Learn More About Dimensions |Considerations |
|---|---|---|
A list of all currently defined functional units and related naming conventions exists. |
In your design standards |
|
Fault paths and the Roll Back Records element is used. |
In your flow |
|
Systemwide messaging or eventing services in Apex are annotated in ways that make them available in Salesforce Flow tools. |
In your Apex |
|
API message formats and variables for internal communication are defined with platform events. |
In your org |
|
package.xml files only appear in early stage or proof-of-concept project manifests. |
In your source control |
|
No metadata is duplicated across packages. |
In your Packages |
Know Your Resources
In this unit, you learned about the importance of making an adaptable solution and reviewed best practices. In this module overall, you were acquainted with Salesforce Well-Architected, a resource that helps architects build healthy solutions.
Keep this framework as a go-to guide and tool when you’re making architectural decisions. With insights and guidance from experts, Salesforce Well-Architected helps you validate your processes, gives your insight into patterns and anti-patterns, while also providing information on cutting-edge technologies.