Article
Why Do Salesforce Data Cloud Implementations Fail?
What’s trending
UPCOMING EVENTS
Designing on Salesforce: An Architect’s Guide to Making Good Decisions
March 10, 2025
Architects are mainly responsible for the technical integrity of the systems they deliver. However, they also execute business analysis tasks, play a leadership role within your internal team, lead client interactions, and inform the change management process to ensure smooth adoption. The role of the solutions architect is that of a designer, and one of the hidden key responsibilities of any intentional designer is making good decisions that balance technical and business needs within various parameters.
Working under time and budget constraints while making decisions methodically and deliberately is challenging. This article explains how to make well-informed architectural decisions and presents a method for improving the decision-making process.
Anatomy of a Good Architectural Decision
Let’s start by defining what we mean by a good decision. A sound architectural design decision:
- Abides by the Well-Architected framework.
- Demonstrates viability, feasibility, and desirability.
- Is documented and defensible.
A design decision that passes all of the above criteria should constitute a well-made decision. Of course, technologies and business contexts change, meaning that a good decision to make today may not be a good decision a year from now. That’s ok! Part of developing a relationship of trust with clients is educating them about change and being clear about the potential limitations of any design.
The Decision-Making Process
Having a structured framework in place will help you build a reliable process that you can use consistently to guide your team toward better architectural decisions.
Start by clarifying the requirement. Once you’ve got a high-quality requirement, you can start brainstorming potential solutions. The initial brainstorm should be divergent; your team should have the liberty to ideate all manner of creative solutions without judgment.
This broad-spectrum brainstorming process can promote innovation and help to surface new and creative ways to solve business problems.
Once you’ve got several potential solutions on the table, you can evaluate potential solutions – think of this as your design quality control, where you’ll interrogate each design against the anatomy of a good decision to see if it could be viable for implementation.
This convergent process of trimming the available solutions to only “good” potential solutions should produce a set of strong options that you can present to the client, end-users, or business decision-makers. A clear breakdown of the pros and cons of each design should be presented.
Equipped with the appropriate information and the technical team’s recommendations, the client should ultimately be responsible for validating the surviving designs and selecting a chosen design to implement. This chosen design decision should be documented before moving on to implementation.
Evaluating Design Decisions
Once you’ve developed a set of potential solutions, they can be interrogated against our anatomy of a good design decision, confirming that it abides by the Well-Architected Framework and is viable, feasible, and desirable.
Compare Against the Salesforce Well-Architected Framework
The Well-Architected Framework is an industry-standard concept developed by Salesforce Architects. It outlines a set of principles for quality solution designs on the platform:
Your first round of solution design evaluation can compare designs against this framework by asking:
| Dimension | Key Questions |
|---|---|
| Trusted | 1. Does the solution present security issues that could compromise the safety of user or customer data? 2. Does it comply with the necessary internal (company policy) and external (governmental policy) rules (i.e. GDPR)? |
| Easy | 1. Does the solution solve a demonstrable pain point for users? 2. Does it enhance the user experience by reducing the time spent by users executing tasks or by making users more effective at their work? 3. Does it uphold or enhance the user experience and/or user interface? |
| Adaptable | 1. Is this solution relatively resilient to platform or business changes? 2. Is this solution composable (can it be used elsewhere)? |
If the proposed solution presents major issues against the above questions, it may require revision or be discardable. Likely, there will be trade-offs – for example, a very “easy” solution may not be the most “adaptable”. It will be up to you as the architect to establish a reasonable threshold against which to progress designs to the second round of evaluation.
Evaluate Desirability, Viability, and Feasibility
The Desirability-Viability-Feasibility (DVF) Framework is credited to the design-thinking house, IDEO in the early 2000s. This framework articulates a “sweet spot for innovation” in design-driven product design:
- Desirability refers to how attractive the solution is for end users. Under this category, you may assess user experience, time saved, efficiencies gained, improvements to processes, etc.
- Viability refers to how appropriate the solution is for the business. Here you may consider if the business is ready to adopt this solution.
- Feasibility refers to the practicality of the solution from a technical standpoint. Can and should the solution actually be implemented technologically speaking?
*Architects may also evaluate an ethical dimension to the design here, particularly when including AI-supported solutions.
Review some key questions you may ask during the evaluation process for desirability, viability, and feasibility:
| Dimension | Key Questions |
|---|---|
| Desirable | 1. Has the user had a positive experience? 2. Does the user experience/user interface align with design standards? 3. Is the user interface accessible to all users? 4. Is there significant time saving? 5. Is there significant value-adding? |
| Viable | 1. Does the client have the budget for this solution? 2. Are the business processes that this solution supports changeable? 3. Does the business have the capacity to effectively roll out and adopt this solution? 4. Does the solution build upon existing strengths in the organization? |
| Feasible | 1. Does the client have the correct licenses to operate this solution? 2. Are there platform changes that are likely to change or make this solution redundant in the near future (i.e. via Major Releases)? 3. Does this solution risk hitting governor limits? 4. Will intensive custom development or third-party tools be required? 5. Can the client maintain the solution? 6. Can the solution be re-used, or can this solution be supported by other functionality that can be re-used? 7. Are there other notable technical limitations? |
A design option that demonstrates desirability, viability, and feasibility should provide adequate value to the business within real-world constraints.
By convergently evaluating designs against the Well-Architected framework and DVF framework, architects should be able to produce a focused set of surviving design decisions that can be presented to the client or end-users for validation and final selection.
Validating Surviving Designs
The final set of design decisions is likely to present a set of trade-offs that will require negotiation with the client. Validating surviving designs and coming to a final, defensible decision will require the client to thoroughly understand the full functional and technical context and limitations of each decision.
Some ways to help shepherd your team toward a final design decision include:
- Ensuring that the solutions speak to the vision of the system and the client’s key priorities.
- Considering the Level of Effort to build and maintain each solution, critically examining if the client and technical teams have the skills, time, and budget to implement each solution.
- Examining the solution in the context of the roadmap – does this solution make sense to implement now?
Moving systematically through the above process should produce a well-architected and defensible solution design decision that provides demonstrable value to the business.
Keeping a clear record of key design decisions is crucial. Once the final decision is made, ensure the solution and its underlying rationale are documented, including reference to why a decision was made, what the parameters and limitations of the design were, who was ultimately responsible for making it, and when it was made.
This record of architectural decisions will help future architects understand the rationale for past decisions and help them more effectively build into brownfield orgs.
Final Thoughts
Architecture isn’t easy. However, applying a reliable conceptual framework to your design process can help minimize inconsistencies in your design approach and ultimately improve the rigor of your process.
Consider having a peer, mentor, or technical architect stress-test your decisions. A second set of eyes can uncover blind spots you may have missed and help you develop more robust and reliable design decisions for implementation.
