The short version: the architect job is mostly refusing things and writing down why. The certifications, up to and including the CTA review board, prove you know the platform’s capabilities and can defend a design under pressure. They do not prove you can tell a sponsor that their preferred answer will cost them three years, which is the actual work. The route is roughly five to eight years of building, then two to four of designing things other people build, with the exams somewhere in the middle as a forcing function.
What the role is
An architect owns the decisions that are expensive to reverse. Object model, sharing model, integration pattern, where the system of record sits, whether this is one org or three. Everything else is implementation, and implementation mistakes are cheap by comparison.
The output of the role is not diagrams. It is a small number of decisions, each with the alternatives that were considered, the reason one won, and the conditions under which you would revisit it. A team that knows why the object model is shaped the way it is will keep it that shape. A team handed a diagram with no reasoning will erode it inside a year.
Day to day it is meetings you did not schedule, reviewing other people’s designs, refusing a fourth custom object that duplicates an existing one, and going quiet for two days now and then to actually think. If you dislike meetings, this role will make you unhappy however good your technical judgement is.
What the certifications do prove
The Application Architect and System Architect tracks, and the domain exams underneath them, prove coverage. You know that Shield encryption breaks certain filters. You know what Big Objects are for and what they cost you. That breadth is genuinely useful, because the most common architectural failure is not choosing badly among options you knew about, it is not knowing an option existed.
The Certified Technical Architect review board proves something narrower and harder: that you can absorb a complicated scenario, design a coherent answer in a few hours, then defend it while experienced people attack it. That skill is real and it maps onto the job.
What they do not prove
- That you will be listened to. Influence is earned in the organisation, not in the exam hall, and it is the binding constraint on most architects.
- That you can size a decision. The exams reward thoroughness. Real projects punish it. Knowing which decisions deserve two weeks and which deserve ten minutes is judgement no exam tests.
- That you can live with a compromise. Most real designs are the second-best option chosen for a budget reason. Architects who cannot make peace with that burn out or become obstacles.
The judgement that matters
Reversibility. Sort decisions by how hard they are to undo. A field you can delete is not an architecture decision. A relationship type, a record ownership model, an external ID strategy: those are. Spend your attention proportionally.
The cost of standard. The advice to stay standard is usually right and occasionally lazy. Functionality that forces the business to work in a way it does not work is a cost too, paid by users instead of developers.
Data volume early. Most architectural regret in Salesforce is about data. Skew, archival, sharing recalculation, reporting at scale. Ask how many rows in year three, then design for that and not for the demo.
Saying no with an alternative. No on its own gets routed around. No, and here is what I would do instead, and here is what it buys you, gets accepted.
A workable route
- Build for several years until you have shipped things that later broke, and you know why.
- Take one domain exam a quarter at most, choosing the ones covering your gaps rather than your strengths. Sharing and Visibility and Data Architecture pay back the most in daily work.
- Start writing decision records on your current project before anyone gives you the title.
- Only attempt the review board if the presentation and defence part appeals to you. The preparation is several hundred hours and it does not suit everybody.
Frequently asked
Do I need CTA to be an architect? No. Most working architects do not hold it. It opens specific doors, mainly in large partners and at Salesforce itself, and it is a poor use of a year if those are not doors you want.
Can an admin become an architect without coding? Yes, but you need enough to judge code decisions honestly. Not writing Apex is fine. Not knowing when Apex is the right answer is not.
How do I get the experience before the title? Take the design decisions nobody claimed, document them properly, and be right often enough that people start asking you first.
