What do I aim to explain and explore?
- What is fragile architecture and how does it happen?
- What are fragile Salesforce architecture decisions?
- What are common solutions in Salesforce with fragile architecture?
- How do fragile systems architecture decisions happen?
- Why is it so important to avoid solutions built on fragile architecture?
- What are the business impacts of fragile architecture?
- How do you avoid fragile architecture decisions?
- How do you design processes that eliminate fragile architecture?
What is fragile architecture and how does it happen?
Fragile architecture is someone making a seemingly innocuous change that breaks some business-critical process. Fragile architecture is a solution that creates a constant annoyance for a user or creates confusion from leveraging a user in a way that is not normal. Fragile architecture is a workaround that makes an end user noticeably less productive or creates additional pain points.
Fragile Salesforce architecture is building a flow that searches for a user with a specific first name. Fragile Salesforce architecture is building a flow that searches for non-indexed fields in a process that has fast increasing data volume, or even moderate retained data volume increase over the medium-to-long term. Fragile Salesforce architecture is creating a picklist field for a large value set that will inherently have frequent value additions or deactivations.
Sometimes it happens because the client or product owner is so high maintenance that time is running tight, or keeps changing their mind on what’s needed, or won’t get you the answers you need. Sometimes it happens because you don’t have the experience to design a better solution for that process need. Sometimes it happens because we designed a solution based on stakeholder-confirmed requirements that didn’t align with end users’ requirements.
Hopefully it doesn’t happen because you’ve misunderstood the requirements. Hopefully it doesn’t happen because you followed an end user or business stakeholder’s proposed solution without thorough vetting (they propose problems and visions, we propose solutions). Hopefully it doesn’t happen because your plate is so full with other projects or tasks that you let this one slip and didn’t properly vet your solution.
What are the business implications of fragile systems architecture?
Fragile architecture makes it harder for other administrators to make changes to the org, because they have to unravel your solution before they can confidently or scalably implement their changes. Fragile architecture makes the day to day of end users terrible when they have to use workarounds to the built processes to accommodate their real job needs. Fragile architecture makes your system’s return on investment unnecessarily impeded or highlights system deficiencies rather than process efficiencies.
Hopefully it’s not because the solution wasn’t designed with the business’s larger goals and KPIs in mind. Hopefully it’s not because the right stakeholders weren’t tapped during discovery due to their lack of availability. Hopefully it’s not because too junior resources were trusted with developing the solution without enough oversight.
How can you avoid fragile Salesforce architecture?
The boring answer to avoiding fragile architecture is building proper documentation of the right solutioning processes to take, dedicating time to teaching people those solutioning processes, and having mechanisms for ensuring those processes are being followed. The boring answer to avoiding fragile architecture is to ensure an experienced enough resource has at least an effective Quality Assurance role in the discovery and solutioning phase, if not designs the solution for a more junior resource to build and test. The boring answer to avoiding fragile architecture is to dedicate the necessary time to “tear down” your solution before you build it–flushing out all the costs and benefits it creates.
Hopefully it’s not happening because you’re rushing. Hopefully it’s not happening because you’re afraid to ask a follow up question during discovery or during UAT feedback. Hopefully it’s not happening because you don’t understand the business value of the requirements.
How do you design processes that eliminate fragile architecture?
Create a process that has clear checkpoints for discovery, design, build, testing, deployment, and documentation. Create a process that clearly documents out the discovery requirements, key solution decisions, and mid development adjustments so that they will aid future decisions and system maintenance. Create a process that specifies who’s accountable for or in charge of every single checkbox and deliverable.
Let’s build more scalable, maintainable, and understandable configuration solutions that deliver business process benefits–the right processes and the right benefits. Let’s build changes that make us end users’ favorite people because they solve pain points and don’t create them. Let’s build changes that allow key stakeholders and executives to easily see the benefits of the system investment so we can continue to do great work and design great solutions for the enterprise platforms of businesses out there doing great things.
The Declarative Architect 