A Reference Architecture is a pre-defined, validated architectural pattern that solves a common problem. Rather than re-architecting every project, teams reuse the reference.
Examples:
- Lead-to-Cash Reference Architecture — Marketing Cloud + Sales Cloud + CPQ + ERP.
- Customer 360 Reference Architecture — Sales + Service + Experience Cloud + Data Cloud.
- Field Service Reference Architecture — Service Cloud + Field Service + IoT + Mobile.
- Multi-Org Federation — central org + spoke orgs + Mulesoft + SSO.
Components of a reference architecture:
- Diagram — visual showing systems, data flow, technologies.
- Component descriptions — what each part does.
- Trade-offs — why this design vs alternatives.
- Variations — how to adapt for specific contexts.
- Implementation guides — how to instantiate.
Why use them:
- Faster start — don't reinvent.
- Proven patterns — already validated.
- Consistent architecture across projects.
- Risk reduction — known patterns have known failure modes.
Salesforce publishes reference architectures via:
- Architect.salesforce.com — public reference architectures.
- Industry-specific — for verticals.
- Customer 360 Truth documentation.
- Trailhead modules for architects.
Senior architects collect reference architectures, learn from them, and contribute to them. Most consultancies maintain internal reference architectures based on accumulated experience.
When stuck: search for an existing reference architecture for the problem. Often saves weeks of design work.