Architect Fundamentals and the CTA Journey
Architect Fundamentals and the CTA Journey
This domain tests whether you reason like a Salesforce technical architect rather than a senior developer. The awareness exam probes role boundaries, the architecture lifecycle, and how decisions are framed and justified before a single piece of metadata is created. The CTA journey itself is a progression: awareness of the domain space, demonstrable design judgment, and the ability to defend trade-offs under challenge.
What the architect actually owns
- Non-functional requirements: performance, scalability, security, availability, maintainability, cost.
- Cross-cloud and cross-system decisions, not feature configuration.
- The "why" trail - every significant decision recorded with context, options, and consequences in an architecture decision record.
- Risk: identified, quantified, owned, mitigated.
A developer builds it, an admin configures it, the architect decides what should exist and defends why - including what is deliberately excluded.
The decision frame
Situation → requirements (functional and non-functional) → constraints → options → weighted criteria → decision → consequences → validation. Options must include "do nothing" and "buy versus build". Criteria are weighted before scoring, otherwise the scoring rationalizes a preferred answer.
Worked example
A service organization with 40 million cases and 3,000 agents wants screen-pop and call recording. Options: (a) Service Cloud Voice with Amazon Connect, (b) a custom CTI with a middleware vendor, (c) keep existing telephony and build a console with a softphone component. Criteria weights: time to value 0.3, telephony ownership 0.2, recording compliance 0.2, three-year cost 0.2, team skills 0.1. Option (a) leads on compliance and time to value, but fails the team-skill criterion and conflicts with a mandated telephony contract - so the constraint eliminates it. Option (c) wins on cost but pushes recording into an unsupported integration. Option (b) wins overall. The lesson: applying constraints changed the answer, and the answer is only defensible because the criteria were declared first.
Traps that cost marks
Proposing a solution in the first meeting. Equating "architect" with "most senior developer". Treating non-functional requirements as an afterthought. Using "best practice" as a justification without context. Designing for scale nobody quantified. Ignoring licensing and total three-year cost. Presenting one option as if no alternative existed.
Key points
- Architects own decisions and their consequences, not just designs.
- Weight criteria before scoring options so the reasoning survives scrutiny.
- Constraints eliminate options faster than scoring does.
- Record decisions and rejected alternatives in ADRs.
- Non-functional requirements drive architecture more than features do.