Ask most developers how to become a Salesforce architect, and you’ll get the same answer three times: get more experience, pass the next certification, wait for the right opportunity to open up. None of that is bad advice. But it quietly assumes that this skill comes along with the title itself—that is, as soon as someone calls you an architect, you start thinking like one.
It is actually the other way around. Architectural thinking is a skill, and skills get built through practice, not permission. Salesforce’s own Architect Relations team makes this point directly: architectural thinking “is not limited to certifications or job titles” and can be practiced at any stage of your career. The gap in most career advice isn’t the goal. It’s that nobody shows you the reps.
So here are the reps. Four concrete habits you can run on work already sitting in your backlog — no promotion required.
Table of Contents
Worth knowing why this matters now, beyond career pride: demand is shifting under your feet. Per Salesforce’s own analysis, demand for Salesforce Technical Architects has risen 27% globally, while Solution Architect roles are up 21% (Salesforce, “The Architect Mindset“). Developer demand hasn’t grown at the same pace. The thinking that separates the two roles is the thing worth building now.
Key takeaways
- Architectural thinking is a practiceable skill, not something that switches on with a job title.
- Auditing unfamiliar orgs trains you to read systems instead of only building them.
- Writing decision records makes your judgment deliberate and visible to the people who promote.
- Reviewing old build-versus-configure calls sharpens your sense of when code earns its complexity.
- Pre-mortems build the forward-looking failure thinking that defines architectural design.
What “Thinking like an Architect” Actually Means.
Before the habits, it helps to be precise about what changes in your head, because “architect mindset” gets thrown around like it’s a personality type. It isn’t. It’s a set of shifts in how you engage with a problem.
A developer asks: Does this work? An architect asks: How does this hold up three releases from now, when the data volume doubles, or when five new integrations get bolted on?
Three shifts do most of the work. First, you start thinking about failure at scale instead of correctness today. Second, you question requirements instead of just executing them; “why do we need this field?” becomes a normal thing to say out loud. Third, you start owning the coherence of the whole system, not just the quality of the component you were handed.
Salesforce packages a lot of this into its Well-Architected framework, built around three pillars: Trusted, Easy, and Adaptable. I’ll point back to it as we go, because it gives you shared vocabulary for instincts you probably already have but can’t yet name. And naming things is half of what architects get paid for.
The shifts sound abstract until you attach them to a repeatable action. Let’s do that.
Practice 1: Audit an Org you didn’t Build
Developers build. Architects read. The single fastest way to develop the reading habit is to open an org someone else built and try to understand why it looks the way it does.
Pick a sandbox you didn’t create. A client’s, a colleague’s, a practice org from a Trailhead project — doesn’t matter, as long as your fingerprints aren’t on it. Then run two free tools most people ignore. Health Check (Setup → Security → Health Check) scores the org’s security posture against a Salesforce baseline. Optimizer (Setup → Optimizer) reports on unused fields, storage, layouts, and custom code across dozens of metrics.
Those give you data. The architectural part is what you do next: you write down the anti-patterns and guess at the reasoning behind them. Four flows firing on the Account object was that one person solving four problems in isolation, or did nobody know the others existed? A sharing model wide open where it probably shouldn’t be. Twelve record types, half of them unused.
The person who built the org is rarely the right person to audit it because they read intent into the metadata that it doesn’t actually contain. That’s exactly why auditing someone else’s work trains the muscle. You only have the artifacts. Reading a system from its artifacts and inferring where it will crack is a huge part of what Salesforce’s Well-Architected framework aims to teach.
Practice 2: Write the Decision, not just the Code
Developers constantly make the right decisions but leave no trace of the reasoning behind them. You chose a subflow instead of Apex, or a roll-up instead of a trigger, and moved on. Your decision was correct, but no one coming after you would know about it.
Architects make the reasoning the deliverable. So start writing short decision narratives in your pull requests and design docs. This has a name in the wider software world: the Architecture Decision Record, or ADR, a practice popularized by Michael Nygard back in 2011 and now used everywhere from Spotify to government engineering teams. Salesforce’s own “Think Like an Architect” guidance leans on the same idea: capture the thinking, not just the outcome.
A lightweight ADR template
You don’t need a heavyweight process. One page, five fields:
| Field | What goes here |
|---|---|
| Context | The situation and constraints forcing a decision |
| Decision | What you chose, stated plainly. |
| Alternatives | The options you seriously considered and rejected |
| Consequences | What this makes easier, and what it makes harder |
| Status | Proposed / Accepted / Superseded |
Treat this strictly as an append-only log. When a decision is subsequently changed, you write a new record that supersedes the old one – you do not silently edit the history, because the history itself is the point.
A real example reads like this: “Chose a subflow over invocable Apex here because this logic changes roughly every quarter and admins own the maintenance. Rejected Apex to keep the change surface declarative, accepting reduced headroom for complex, high-volume processing if this logic ever needs to run in bulk.”
That’s it. Notice what it does — it makes a judgment you’d otherwise make silently both deliberate and clearly understandable. And a clearly understandable decision is precisely what the people handing out architect roles are looking for. You’ve done this right when someone can read the record six months later and understand not just your choice, but the ones you rejected and why.
Practice 3: Run Build-versus-Configure retros on Past Projects
The clicks-versus-code decision is one of the most consequential architectural calls on the platform, and most of us make it on gut feel in the moment. So sharpen the gut. Take a feature you have already shipped and look back to reconsider that decision: knowing what you know now, would you build it the same way?
One important thing to take is a ‘declarative-first’ approach — that is, use Apex only when the configuration no longer meets the needs, not before. Some teams may talk about a rough balance of mostly Flow, some Apex, a little Agentforce. The exact ratio matters far less than the reasoning behind each call.
The questions that sharpen the call
When you review an old decision, ask:
- Does this custom code duplicate something the platform now does natively? Salesforce ships features fast. Apex that was justified two releases ago can be technical debt today.
- What does this do to order of execution and governor limits at scale? The synchronous CPU time limit is an easy one to overlook – it gets hit more often than people expect, especially once automation stacks up.
- Who will manage this a year from now—the admin or the developer? Optimize for whoever actually inherits it.
This aligns with the Easy and Adaptable behaviors in Well-Architected, and it’s not a minor concern. Technical debt is a genuine, recurring pain point in the ecosystem, and much of it traces back to build-versus-configure decisions made without anyone documenting the rationale.
You’ve got the habit of being able to defend and critique your own past decisions in the same breath, without getting defensive about it.
Practice 4: Pre-Mortem your finished Features
Developers ask “does it work?” Architects ask “how does this die, and when?” The difference is forward-looking failure thinking, and there’s a specific technique for building it.
It’s called a pre-mortem, developed by psychologist Gary Klein and laid out in Harvard Business Review in 2007. The move is simple and slightly uncomfortable: assume the thing has already failed, then work backward to explain why. Klein points to research on “prospective hindsight” — imagining an event has already happened — which was found to improve people’s ability to correctly identify reasons for a future outcome by around 30%. Assuming failure surfaces risks that “will this work?” never does.
Take a feature you shipped. Now imagine it’s six months later and it has failed badly — at ten times the data volume, or after three more releases, or once five new integrations start hitting the same objects.
How to run one solo in 20 minutes
- Write down every reason the feature failed. Don’t filter, don’t rank yet — just get them out.
- Group them into failure modes: scale, integration, data quality, adoption, maintainability.
- For each one, note the design change that would have prevented it. That note is your architectural insight.
This is the Reliable behavior from Well-Architected in practice — availability, performance, scalability, considered before they bite. The real benefit comes later, when you realize you are incorporating lessons learned from analysis directly into the design before shipping, rather than addressing them after the fact.
Where Certs and Titles actually fit
None of this is an argument against certification, so let me be clear about where it fits. The architect track is real: the domain credentials are Application Architect and System Architect, each earned through a set of component exams, and both are prerequisites for the top-tier Certified Technical Architect (CTA), one of the hardest and rarest credentials in the entire ecosystem.
One important point to note, given that Salesforce frequently makes changes: in mid-2025, the company renamed several certifications and shifted certification management to Trailhead Academy; furthermore, additional changes are scheduled. While names may change, the associated skills remain the same.
Certs validate architectural thinking. They don’t create it. The four habits above build the exact thing those exams measure — which means if you do them first, the credential turns into a formality instead of a leap.
Final Thoughts
Pick one org you didn’t build and audit it this week. That’s the whole assignment. It’s the fastest of the four habits to start and the one that most quickly rewires how you see a system.
Then give yourself a month. By the end of it, aim to have one org audit, three decision records, one build-versus-configure retro, and one pre-mortem written down. If you get there, the habit has taken — and you’ll notice the shift in how you talk about your own work long before anyone updates your title.
You don’t need a different job to start thinking like an architect. You need a different frame for the job you already have.
Frequently Asked Questions (FAQ)
Start by changing how you engage with your existing work. Audit orgs you didn’t build to learn to read systems, write down the reasoning behind your technical decisions, review past clicks-versus-code calls, and run pre-mortems on features you’ve already shipped. These habits build architect-level judgment without needing a new role.
No. Admins and consultants move into architecture too — the common thread is systems thinking, not writing code. That said, the technical architect path leans heavily on development experience, while solution and functional architecture routes lean more on process and design.
A developer owns component quality and answers “does it work?” An architect owns how the whole system holds together and answers “how does this behave at scale, and how does it fail?” The architect is accountable for coherence across many components, not the correctness of any single one.
It depends heavily on your starting point and how varied your org exposure is. There’s no fixed timeline. The useful reframe is that you can start building the skill immediately, well before you’re eligible for the title, so the clock on your thinking starts whenever you decide it does.
For many, yes — it’s a rare, respected credential that tends to command a meaningful salary premium. But it validates architectural thinking rather than creating it. It’s most worth pursuing once you’ve already built the underlying judgment, which makes the review board far less of a cliff.
It’s Salesforce’s official framework for making and evaluating architectural decisions, built on three pillars: Trusted, Easy, and Adaptable. It’s a free, structured way to learn how to reason about a solution the way an architect does, and a good companion to the four habits in this article.
Priya Rastogi
Priya is a 3x Salesforce Certified who believes in the power of continuous learning and collaboration. She’s passionate about exploring how Salesforce can simplify work, boost productivity, and create better user experiences. When she’s not experimenting with new features or automating processes, Priya enjoys connecting with fellow Trailblazers and sharing insights to help others grow in their Salesforce journey.
- Priya Rastogi
- Priya Rastogi
- Priya Rastogi
- Priya Rastogi
