How to get hired as a software architect in 2026-27

What a software architect actually does, and the five shapes of the title

A software architect is accountable for the technical decisions that are expensive to reverse, and for the system still working when those decisions meet reality. That is the whole job description. It covers where the boundaries sit between services, modules and teams; who owns each piece of data and who may read it; what the contracts between parts of the system are and how they change without a coordinated release; what the system does when a dependency is slow rather than down; the non-functional requirements written as numbers rather than adjectives; the order in which change can safely be applied to a live estate; and what the organisation buys instead of building. A useful test of whether something is architecture: if a single team can reverse it inside a sprint, it is not.

The difference from a senior engineer is time horizon and blast radius, not seniority of tone. A senior engineer makes the right call inside a system; an architect decides what the systems are, and lives with that for years. The difference from an engineering manager is that an architect normally has no headcount, no budget and no formal authority over anybody, so the currency is written argument, credibility earned by having been right before, and the ability to make other people's independent work compose into something coherent. The difference from a product manager is direction of pressure: a product manager brings what the business wants, an architect brings what is actually possible at what cost and in what order.

Five shapes of the title exist and they interview differently, so establish which one a posting means before you prepare. The application or software architect is embedded with two to four teams, close to the code, and owns a bounded set of systems. The solution architect is attached to a programme or a customer, often in a systems integrator or a vendor, frequently customer-facing and sometimes in pre-sales, and is measured on whether the proposed solution can be delivered for the price quoted. The enterprise architect works at portfolio level on standards, roadmaps, vendor selection and capability maps, is furthest from code, and is the role where TOGAF vocabulary is genuinely expected. Specialist architects (data, security, integration, cloud, platform) own one dimension across many systems. And the de facto architect carries the title staff or principal engineer at a product company and does all of the above without the word appearing anywhere.

How much you are expected to code is the question candidates get wrong most often. In 2026-27 an architect who has not touched production code for years is a routine rejection in product engineering, and increasingly a hard sell in enterprise too. Expect to be asked directly when you last wrote code that ran in production. Strong answers are specific and modest about scope: you build the spike that de-risks the decision, you write the reference implementation that other teams copy, you take the ugliest part of a migration yourself, you review pull requests on the boundaries you care about, and you write the automated checks that enforce the architecture. Weak answers describe reviewing diagrams.

The literature for this role is unusually good and interviewers notice when a candidate has read it. Fundamentals of Software Architecture (Richards and Ford) and Software Architecture: The Hard Parts (Ford, Richards and co-authors) give you the vocabulary of trade-off analysis that interviews reward. Designing Data-Intensive Applications (Kleppmann) is still the reference for the data questions that decide most design rounds. Building Evolutionary Architectures is where fitness functions come from, which matter more now than when the book was written. Team Topologies explains why your boundary proposal keeps failing for organisational reasons. Monolith to Microservices (Newman) is the practical migration text. None of these is a credential, but a candidate who can name the trade-off they are making sounds different from one who improvises.

• Before preparing, ask the recruiter: how many teams, is there an architecture review board, is hands-on work expected, and what decision is currently blocked that this hire is meant to unblock.
• If a posting says 'architect' but describes feature delivery for one team, it is a senior or staff engineering role with a flattering title. That is fine if the pay matches, but prepare for an individual contributor loop.
• If a posting lists TOGAF, capability maps, vendor rationalisation and no technologies, it is an enterprise architect role and your hands-on depth will barely be tested. Decide whether you want that before you invest in the process.
• Expect 'when did you last write production code' in any product company loop. Have a specific, recent, verifiable answer.
• The role has no formal authority in most companies. If you need it to be effective, target enterprise architecture with governance sign-off, and know that you are trading code proximity for it.

Where the title exists, and why you should search for two different jobs

The single most useful piece of job search advice for this role is that the work is advertised under two incompatible vocabularies. In the enterprise world (banks, insurers, telcos, health systems, retailers, manufacturers, utilities, government, and the consultancies and systems integrators that serve them) 'architect' is a real job grade with bands, a governance forum, and sometimes sign-off authority over what other teams are allowed to build. In the product and technology world, architecture is a responsibility carried by staff, senior staff, principal and distinguished engineers, and some companies actively avoid the title on the grounds that it implies decisions made by someone who does not have to live with them.

This matters because the two worlds screen on different keywords and reward different resumes. An enterprise screen looks for domain familiarity (payments, claims, core banking, OSS and BSS, electronic health records, SAP, mainframe integration), governance vocabulary, named cloud certifications, vendor experience, and in defence or government a clearance. A product company screen looks for scale units, systems you can name and describe, migrations completed, and evidence of hands-on judgement. The same candidate often needs two versions of the same resume, not because either is dishonest but because each audience cannot read the other's shorthand.

The second consequence is about what you are actually buying with each path. Enterprise architecture gives you formal leverage, broad visibility, access to executives, and work that is often about untangling rather than building. It tends to pay less than a product company staff or principal role in the same city, and it erodes hands-on depth, which narrows your options later. Product company architecture gives you higher total compensation, much closer contact with the code, and influence that has to be earned repeatedly because nobody has to listen to you. Pick deliberately and say your reason out loud in interviews, because 'I want the broadest system I can get my hands on' and 'I want to stop coding' land very differently.

There is also a search mechanics problem worth knowing. 'Architect' is a legally protected title for building design in many jurisdictions, so job boards, salary aggregators and search engines mix software architects with the people who design buildings. Salary pages for 'architect' are frequently useless for that reason. When researching pay, use occupation codes and level bands rather than title searches, and when writing your own profile include both 'software architect' and the staff or principal phrasing so that both kinds of recruiter find you.

• Run two searches, always: 'software architect', 'solution architect', 'application architect', 'enterprise architect', 'technical architect' on one side, and 'staff engineer', 'senior staff engineer', 'principal engineer' on the other.
• Keep two resume variants. The enterprise one leads with domain, governance and certifications; the product one leads with systems, scale and migrations.
• Put both vocabularies in your LinkedIn headline and summary so both recruiter populations match you.
• Ignore salary pages that search on the word 'architect'. Use BLS occupation codes, levels.fyi level bands, and posted ranges in pay transparency jurisdictions.
• If you want to keep both doors open, do not spend more than a few years in a role with no code in it. Hands-on credibility decays faster than anything else on your resume.

Making the jump from hands-on engineering: the work that earns the title

Very few people are hired into a first architect role on a pure feature-delivery record, for the same reason very few are hired into a first management role on one: it is a bet that takes two years to settle and costs a lot if it fails. Enterprises do hire architects externally all the time, but they hire people who already have architecture scope on paper. So the reliable path is that you do architecture work first, under your existing title, and the title follows the evidence. The good news is that most organisations have a surplus of decisions nobody is taking, and taking one in writing is the single highest-leverage career move available to a senior engineer.

There is a recognisable sequence. First, write the design document that settles a running argument. Not a diagram: a document with the constraints, two or three options, what each costs, what you are choosing and what you are deliberately deferring. Second, own a contract that crosses a team boundary: a public API, an event schema, a shared data model, the thing where two teams keep breaking each other. Third, run one migration end to end, including the part everybody avoids, which is turning the old thing off. Fourth, build the cost model for something you own, because almost nobody does this and it instantly makes you the person leadership asks. Fifth, be the one who writes the architectural change that comes out of a post-incident review, and then make sure it actually ships.

Visibility is a separate task from the work and people under-do it. Say explicitly to your manager that you want to move towards architecture, using the word, in a one to one, because headcount and grade decisions happen in rooms you are not in, months ahead. Get yourself into whatever review forum exists, even as a note-taker. Present at the architecture review board if there is one. Publish internally: a short written review of a system, a one-page note on a trade-off, a comparison with numbers. What converts a senior engineer into an architect candidate is a named decision with that person's name attached, visible to someone two levels up.

Three failure modes are worth naming because they are common and avoidable. The first is becoming the person with opinions and no artefacts: influential in meetings, invisible on paper, and unable to produce anything for an interview. The second is depth without breadth: ten years in one stack and one domain, which collapses the moment a design round moves to data, networking, security or cost. Fix it deliberately by taking one project outside your comfort area, reading widely, and learning enough about the dimensions you avoid to know when to pull in a specialist. The third is going enterprise architect too early, where you spend three years in capability maps, lose the hands-on credibility that got you there, and find that product companies will no longer interview you.

• Say it out loud to your manager and name the word architecture. Hinting does not get you considered for a grade that is decided in planning cycles.
• Write one real design document per quarter, even if nobody asked. The artefact is the credential.
• Volunteer for the migration nobody wants, and insist on owning the decommission. Finishing a migration is rarer than starting one and it is the single most convincing line on an architect resume.
• Build a unit cost model for a system you own. Cost fluency is scarce and it gets you into leadership conversations faster than anything technical.
• Deliberately take one project outside your strongest area so breadth questions in a design round do not expose a single-stack career.
• Keep a private running log of decisions, numbers and outcomes from day one. You will not remember the p99 figures or the money saved two years later, and the interview needs them.

The artefact portfolio: designs, migrations and cost outcomes that prove the level

This is the part most candidates skip and it is the part that decides offers. An architect interview is substantially a portfolio review, even when nobody calls it that. Assemble three to five artefacts, redacted enough to discuss openly, that you can talk about for 45 minutes each without notes. For each one you need the constraint you were under, the options you rejected, the numbers that drove the decision, what went wrong afterwards, and what you would do differently. The last two items are what separate somebody who did the job from somebody who was nearby when it happened.

The design document is the core artefact. A good one states the problem in business terms, lists the constraints including the political and skills constraints, writes the non-functional requirements as numbers (p99 latency target, availability target, recovery point and recovery time objectives, peak throughput, data volume growth, cost ceiling), presents two or three genuine options with the trade-offs made explicit, names the decision, names what is deliberately deferred, and says how you would know in six months that you were wrong. Use arc42 or your employer's template for structure, C4 for diagrams at consistent zoom levels, and architecture decision records for the running decision log. The quality test is simple: a reader who disagrees with you can point at the exact sentence they disagree with.

The migration artefact is the one that most reliably convinces a hiring panel, because migrations are where architecture meets an organisation that cannot stop shipping. Show the sequencing: what moved first and why, how you used parallel change (expand then contract) so that nothing needed a coordinated release, how you handled dual writes and the backfill, whether you ran shadow traffic to compare old and new behaviour before cutover, what the rollback actually was at each stage, and how feature delivery continued alongside. Then show the end: the date the legacy system was switched off, the licence that stopped being renewed, the on-call rotation that got deleted. Plenty of migrations in the real world leave both systems running indefinitely. Having finished one is a differentiator and you should lead with it.

The cost artefact is the fastest way to be memorable in 2026-27, because cloud and inference spend are under genuine scrutiny and architects who speak cost fluently are scarce. Express it as a unit: cost per thousand requests, per tenant per month, per order processed, per terabyte retained, per model call. Then show the before, the after, and the lever: a storage tiering change, egress eliminated by moving a workload, right-sizing after measuring rather than guessing, committed-use discounts against a capacity model you built, caching that cut a paid dependency, a managed service you replaced or deliberately kept because the labour cost of running it yourself was higher. Include at least one case where you argued for spending more and why.

Round the set out with reliability and governance evidence. Reliability: an SLO you defined with the business rather than invented, an error budget policy that actually changed a release decision, one failure mode you designed out and how you proved it (a game day, a load test with real numbers, a failover exercise with a measured recovery time). Governance, for enterprise roles: a reference architecture that other teams adopted and the adoption count, a standard you chose plus the exception process you wrote so it did not become a bottleneck, and a build versus buy memo with the five-year numbers and the assumptions listed. If any of this is confidential, write a sanitised version now rather than improvising one in a room.

• Non-functional requirements belong in numbers. Something in the shape of 'p99 under 400ms at 3,000 requests per second, 99.95 percent monthly availability, RPO 5 minutes, RTO 30 minutes' beats 'highly available and performant' in every interview.
• For every artefact, prepare the rejected option. Panels probe the alternative you did not take, because that is where the thinking shows.
• Name the decommission and what it ended. 'We cut over in March and switched off the legacy platform, ending its annual licence' is the shape of the strongest sentence available to you, with your real month and your real figure in it.
• Use parallel change rather than big-bang cutover, and be able to describe the rollback at each phase. Panels are listening for whether you can move a live system without a freeze.
• Express cost as a unit, not a total. Totals are trivia; a cost per request that halved is an engineering outcome.
• Prepare one case where you argued against a popular technology choice and won, and one where you lost. The second one is often the more informative answer.
• Write sanitised versions of confidential artefacts in advance. 'I cannot talk about that' twice in a loop reads as having nothing to show.

The resume: scale units, decisions and decommissions

An architect resume is read for two things: what you were responsible for, measured in units, and what you decided, with the consequence attached. Most are instead written as a technology inventory with the word 'architected' sprinkled through it, which reads as somebody describing a job rather than somebody who did one. Lead each role with the shape of the estate: how many services or applications, how many engineers were affected by your decisions, requests per second or transactions per day, data volume, number of regions or data centres, monthly cloud or licence spend, number of teams whose work had to compose. Those numbers set the level before anybody reads a bullet, and they are what a screener uses to decide whether you operate at the altitude of the role.

Then write bullets as decisions, one per bullet, each with a constraint and an outcome. Something in the shape of 'replaced a synchronous fan-out with an event-driven pipeline, cutting checkout p99 from 1.8s to 320ms and removing the holiday-peak failure mode behind two outages' is a bullet. 'Architected scalable cloud-native microservices platform leveraging best practices' is nothing at all: no decision, no constraint, no outcome, and it could have been written by someone who read about the project. Include at least one bullet about a constraint you respected rather than engineered around, because architects are hired to work inside limits: a skills gap in the team, a compliance requirement, a hard budget, a vendor contract with two years left on it.

What gets ignored or actively counted against you: long technology lists, especially ones that include everything you have ever read about; 'architected' used with no object attached; a stack of certification logos at the top of page one, where the reader wants scope; UML and modelling tool inventories; Agile and SAFe ceremony vocabulary presented as achievement; 'thought leader', 'visionary', 'strategic enabler'; '15+ years of experience in enterprise solutions' as an opening line; and responsibilities phrased as duties ('responsible for architectural governance across the portfolio') with nothing attached. Keep certifications to a single line near the end unless you are applying to an enterprise or an integrator whose screen is literally looking for the acronym, in which case put the acronym in the summary line too.

Format and mechanics. Two pages. A summary of three or four lines naming your domain, the scale you operate at, and the two decisions you most want read. One honest line per recent role about current hands-on work, because the first silent question in every product company screen is whether you still code. Where you can, link one public artefact: a conference talk, a published RFC or architecture post, an open source design contribution, a redacted design document in a portfolio repository. One real artefact does more than a page of adjectives. If you hold a government clearance or vetting status, put it in the top third, because for defence and public sector roles it is a harder gate than anything else on the page and recruiters filter on it first.

• Open each role with scope in units: services, teams affected, throughput, data volume, regions, monthly spend.
• One decision per bullet, with the constraint and the measured outcome. If you cannot attach a number, attach a specific consequence ('removed the coordinated release that had blocked every deploy on a Thursday').
• Include the decommissions. Systems turned off, licences stopped, rotations deleted, duplicate platforms consolidated after an acquisition.
• Include one cost bullet with a unit, and one reliability bullet with a measured recovery or error-rate change.
• Cut the technology list to one honest line per role. The design round tests depth; the resume only has to earn you the round.
• Keep certifications to one line at the end, except in enterprise and systems integrator applications where the acronym belongs in the summary too.
• Name the domain explicitly if you have one. 'Payments', 'claims', 'clinical systems', 'telco billing' and 'industrial control' are strong filters that work in your favour.
• Link one public artefact. A talk, an RFC, a written architecture post, or a sanitised design document.

How hiring actually runs, round by round, and who decides

Two processes exist and they feel nothing alike. At a product or technology company the process is owned by an engineering director or a principal engineer, runs three to six conversations over three to six weeks, and is decided in a debrief where the loudest voice is usually the principal engineer who ran the design round. At an enterprise, consultancy or public sector body the process is owned by a head of architecture or chief architect with HR running logistics, takes four to ten weeks, and is decided by a panel, sometimes formally by an architecture review board. The enterprise version takes references seriously, and in defence or government adds vetting that can run for months after the offer. A large share of enterprise and government architecture work is day-rate contract rather than permanent, in which case the process compresses to two conversations and the only real question is whether you have done this exact programme before.

The recruiter screen is a levelling call, not a formality. It fixes the grade you will be interviewed at, and an architect interviewed at the wrong level is usually rejected rather than re-slotted. Be precise about the breadth of what you owned, whether you had any sign-off authority or only influence, how hands-on you are now, and which of the five shapes of the role you are looking for. Ask what decision the hire is meant to unblock. There is almost always one specific stuck decision behind an architect opening (a platform choice, a monolith nobody will touch, a cloud bill, an AI programme stalled in privacy review), and knowing which one it is turns the rest of the process into a targeted conversation.

The hiring manager conversation is where most loops are really decided, and it works the same way for architects as it does for managers: the interviewer has one gap in mind and is listening for whether you have been in that exact situation. Ask directly why the role is open, what the hardest thing about the estate is, what has already been tried, and who will disagree with you once you arrive. Then spend your time on the closest analogue from your own history, in detail, including what went wrong. Candidates who recite a general philosophy of architecture lose this round to candidates who diagnose the specific problem.

The take-home design brief is standard in consultancies and common in enterprises: four to eight hours of work, a document plus a short deck, then a 60 minute defence against questions designed to find the soft part. Treat the brief as the test it is. Start with constraints and assumptions, written explicitly, because the brief will be deliberately under-specified and listing what you assumed is half the grade. Put a one-page summary at the front that a finance or compliance reader could follow. Include cost, at least to an order of magnitude, with your working shown. Include a phased plan rather than a single end state, and name the risks with mitigations. In the defence, change your mind in public when the interviewer brings new information and say why; defending a position after the ground has moved is the most common way candidates fail this round.

Then the rounds candidates underprepare. A stakeholder round where you explain a technical trade-off to a product leader, a finance lead or a compliance officer, graded entirely on whether you can describe the consequence without the mechanism. A conflict round: tell me about disagreeing with a VP, or with a vendor, or with a team that would not adopt your standard. An influence round that is really about operating with no authority, where the only answers that land are concrete ones involving a pilot, a reference implementation, a champion team and a measured result. In some product companies, a round with engineers from affected teams who can effectively veto an architect they expect to make work harder. And references, which for architecture roles routinely include someone who had to implement your design.

• Ask in the recruiter screen what decision the hire is meant to unblock, then aim the whole process at it.
• Nail your level in the first call: breadth owned, authority held or not, how hands-on you are, which shape of the role you want.
• Ask whether there is a coding or code-reading round. Product companies often have one for architects and enterprises rarely do; assume nothing.
• For a take-home brief, write assumptions and constraints first, add a one-page non-technical summary, include costed options, and phase the plan.
• In the defence session, update your position openly when given new facts, and say what changed your mind. Rigidity reads worse than being wrong.
• Prepare the no-authority story with specifics: pilot team, reference implementation, measured result, how you handled the team that refused.
• Line up a reference who implemented one of your designs. For architect roles that is the reference that counts.
• If the role is contract, prepare to be interviewed on exact programme experience rather than general capability, and have your day rate and notice period ready.

Inside the technical rounds: what is actually graded

The system design deep dive runs 60 to 90 minutes and the rubric is consistent across companies even when the prompt varies. Did you elicit requirements before drawing anything, and did you convert them into numbers? Did you do capacity arithmetic out loud (requests per second, storage growth, fan-out, connection counts) rather than asserting that something would scale? Did you offer options and state the trade-off, or did you present one design as obvious? Did you address failure explicitly: what happens when each dependency is slow, what degrades gracefully, what the blast radius of a bad deploy is, how you roll back? Did you handle data seriously, which is where most candidates thin out: ownership, consistency model, retention, access control, and how you would migrate it? Did you cost it, even roughly? Did you say what you were deliberately leaving out of version one? The most common failure is designing a maximal system for a load nobody has, which tells the interviewer you will over-engineer their estate.

The design critique round is now as common as the greenfield round, because it is closer to the actual job. You are given a document or a diagram and asked what is wrong with it. What good looks like: you prioritise, rather than listing twenty observations of equal weight. You separate what is irreversible from what is merely imperfect. You find the implicit coupling, the data with no owner, the single point of failure the author did not notice, the missing non-functional requirement, and the operational burden nobody has costed. You name the one question you would ask the author before deciding anything. Practise this by reading public post-incident reports from large providers and by reviewing real design documents at work with the explicit question: which of these choices cannot be undone?

The migration and constraint rounds are where real seniority shows. Expect a scenario: a monolith that cannot be frozen, a database that must move with minutes of downtime at most, an on-premises estate with a data centre lease expiring, two overlapping platforms after an acquisition. The expected vocabulary is concrete: strangler fig at the edge, expand and contract on schemas and APIs, dual writes with a reconciliation job, change data capture for backfill, shadow traffic to compare behaviour before cutover, idempotency keys so retries are safe, a per-phase rollback. Then expect the constraint variants, which are the real test: do it with half the budget; do it with a team that has never run Kubernetes; do it without taking the system offline; do it when the regulator must be notified of material changes. A design that does not visibly change when the constraint changes is a sign the candidate is reciting a reference architecture.

Two more rounds appear often enough to prepare for. The coding or code-reading round at product companies is usually pragmatic rather than algorithmic: read this module and tell me what is wrong, or extend this small service, or review this pull request. The bar is credibility rather than speed. And the cost round, increasingly its own conversation in 2026-27: what does your design cost per unit of work, which component dominates, what would you do if asked to halve it, and when would you choose a more expensive option on purpose. Finally, use your own questions as a signal: asking what is on the architecture review board's agenda this quarter, or what the last big technical decision was and how it was made, tells a panel more about your level than most of your answers do.

• Spend the first several minutes of a design round on requirements and numbers. Candidates who draw immediately almost always lose.
• Do arithmetic out loud. Rough numbers with stated assumptions beat confident adjectives every time.
• Always cover failure and degradation explicitly, including the behaviour when a dependency is slow rather than down.
• Treat data as the hard part: ownership, consistency, retention, access, and migration. This is where most candidates thin out.
• In a critique round, prioritise and separate reversible from irreversible. A flat list of twenty issues reads as inexperience.
• Know the migration toolkit by name: strangler fig, expand and contract, dual write with reconciliation, change data capture backfill, shadow traffic, idempotency keys, per-phase rollback.
• Let your design visibly change when the interviewer changes the constraint. That responsiveness is the thing being tested.
• Have a cost answer for your own design: dominant component, cost per unit of work, and how you would halve it.
• Ask what the last significant technical decision was and how it was made. The answer tells you whether the role has any real influence.

Certifications, credentials and clearance: what actually moves a decision

Start with the clear part: nothing legally gates this role. There is no licence, no registration, no board exam, no mandated continuing education, and no professional body whose membership an employer must check. Anybody can hold the job tomorrow if an employer agrees. That means every certification is a commercial or screening instrument rather than a competence gate, and the question is only whether a specific certificate gets you past a specific filter.

Certificates genuinely matter in four situations. First, enterprise and public sector keyword screens, where a human resources filter is matching on literal strings and a missing acronym removes you before an architect ever reads your file. Second, systems integrators and consultancies, which need certified staff to maintain cloud partner tiers, so your certificate has direct commercial value to them and they will often pay for it. Third, government frameworks and tenders that specify qualifications for named roles. Fourth, markets with established national schemes, most clearly iSAQB CPSA in German-speaking Europe, where the Foundation and Advanced levels are read as a real signal.

Ranked honestly for 2026-27: the professional-tier cloud certifications (AWS Certified Solutions Architect Professional, Microsoft Certified Azure Solutions Architect Expert via AZ-305, Google Professional Cloud Architect) earn their keep for any cloud-heavy role and are the ones most likely to be a hard filter. TOGAF, in its 10th edition, is close to mandatory as a keyword for enterprise architect postings in finance, telco, insurance and government in several markets, and close to meaningless at a product company; get it if you are targeting that path, and do not expect it to teach you much. The Open Group Open CA is peer-reviewed against real experience rather than a multiple-choice exam, which makes it the most credible of the vendor-neutral credentials where it is recognised, and it takes real work to assemble. Carnegie Mellon Software Engineering Institute architecture certificates are respected and rare, and the trade-off analysis method they teach (ATAM) is directly useful in design critique rounds. Kubernetes certifications are platform engineering credentials, not architecture ones. Scrum and SAFe certifications are neutral at best here and can actively signal a process-first candidate if they sit where decisions should be.

Two things outrank every certificate. The first is a public artefact: a recorded conference talk, a published architecture write-up with real numbers, an RFC or design document you can share, a substantive open source design contribution. One of these does more in a screen than three acronyms, because it is evidence rather than attendance. The second, in defence, intelligence, and much of government contracting, is clearance or national security vetting. It is a harder gate than any qualification, it takes months and must usually be sponsored, and holding a current one makes you dramatically easier to hire for those roles. If you have it, put it in the top third of page one. If you do not and you want that market, target sponsoring employers and expect the timeline.

• No licence or registration exists for software architects anywhere. Treat every certificate as a filter-passing tool, not a qualification.
• Get a professional-tier cloud certification if your target roles are cloud-heavy. It is the most common hard filter in this market.
• Get TOGAF only if you are targeting enterprise architect roles in sectors that screen for it, and expect a keyword benefit rather than an education.
• In German-speaking Europe, iSAQB CPSA carries weight that it does not carry elsewhere. Match the credential to the market.
• Prefer one public artefact over three certificates. A talk or a written architecture post with real numbers is stronger evidence.
• If you hold government clearance or vetting, lead with it for defence and public sector roles. If you want that market and do not, target employers who sponsor.
• Ask an employer to pay for certification as part of an offer package. Integrators in particular have a direct commercial reason to say yes.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• software architect
• solution architect
• application architect
• technical architect
• enterprise architect
• domain architect
• chief architect
• cloud architect
• integration architect
• data architect
• security architect
• staff engineer
• senior staff engineer
• principal engineer
• distinguished engineer
• architecture decision record
• ADR
• design document
• RFC
• C4 model
• arc42
• Structurizr
• reference architecture
• architecture review board
• ARB
• design review
• architecture governance
• fitness functions
• evolutionary architecture
• non-functional requirements
• quality attributes
• ATAM
• trade-off analysis
• system design
• distributed systems
• domain-driven design
• bounded context
• event-driven architecture
• microservices
• modular monolith
• service boundaries
• API design
• OpenAPI
• gRPC
• event schema
• schema evolution
• data contracts
• CQRS
• saga pattern
• outbox pattern
• idempotency
• eventual consistency
• CAP trade-offs
• caching strategy
• message queue
• Kafka
• stream processing
• data mesh
• data platform
• lakehouse
• legacy modernisation
• monolith decomposition
• strangler fig
• expand and contract
• parallel change
• dual write
• change data capture
• backfill
• shadow traffic
• cutover plan
• rollback plan
• decommission
• mainframe migration
• cloud migration
• multi-region
• disaster recovery
• RPO
• RTO
• high availability
• failure modes
• blast radius
• graceful degradation
• capacity planning
• load testing
• performance budget
• p99 latency
• SLO
• SLI
• error budget
• observability
• OpenTelemetry
• post-incident review
• blameless postmortem
• chaos engineering
• game day
• DORA metrics
• deployment frequency
• change failure rate
• time to restore
• cost optimisation
• FinOps
• unit economics
• cost per request
• cloud spend
• committed use discounts
• right-sizing
• egress cost
• build versus buy
• vendor selection
• total cost of ownership
• AWS
• Azure
• GCP
• Kubernetes
• Terraform
• infrastructure as code
• CI/CD
• progressive delivery
• feature flags
• canary release
• zero downtime deployment
• threat modelling
• zero trust
• secrets management
• SBOM
• supply chain security
• PCI DSS
• HIPAA
• FedRAMP
• data residency
• security clearance
• TOGAF
• TOGAF 10
• Open CA
• iSAQB CPSA
• AWS Certified Solutions Architect Professional
• AZ-305
• Google Professional Cloud Architect
• SEI software architecture
• AI architecture
• LLM integration
• retrieval augmented generation
• RAG
• vector database
• embeddings
• semantic caching
• prompt injection
• OWASP Top 10 for LLM Applications
• model evaluation
• eval harness
• golden dataset
• guardrails
• human in the loop
• agentic workflows
• durable orchestration
• Temporal
• Step Functions
• Model Context Protocol
• MCP
• inference cost
• model routing
• token budget
• model versioning
• AI governance
• NIST AI Risk Management Framework
• ISO/IEC 42001
• EU AI Act
• operational resilience
• third-party concentration risk
• Team Topologies
• Conway's law
• cognitive load
• platform engineering
• developer experience
• technical debt
• migration programme
• stakeholder management
• influence without authority
• technical strategy
• technology radar
• BLS SOC 15-1252
• BLS SOC 15-1241
• levels.fyi
• pay transparency

Mistakes that cost people this job

Questions people ask