vi
new
0
Avatar
Truong Phung @truong396
591 28 98
Đã đăng vào Thứ Bảy, 6:58 SA 23 phút đọc
21

🏛️ The Solution Architect Playbook 📚: From Best Designer to Best Bridge - Part 3 🌉

MayFest2026

A deep, opinionated, practical guide for the engineer-architect who designs end-to-end solutions across systems, teams, and business units. The mental models, decision frameworks, discovery tactics, design methods, communication patterns, and anti-patterns that separate the SA whose solutions actually ship and run for years from the one whose 80-page Visio decks gather dust on Confluence. Grounded in current reality — multi-cloud by default, AI woven into every solution, smaller delivery teams per dollar of revenue, regulated by frameworks that didn't exist five years ago, and customers who can read a SOC 2 report.

If you read only one section first, read §2 Mindset, §6 Discovery, §9 NFRs, and §13 Build vs Buy. Everything else is the implementation of those four.

Companion to 🧑‍💻 The Tech Lead Playbook: From Best IC to Multiplier 🚀 (the team-level role), 👨‍💻 The CTO Playbook 📘: From Best Builder to Best Bet ♟️ (the org-level role), 🏛️ The System Design Playbook 📖 (the design vocabulary), 🛠️ The Senior Software Engineer Playbook 📖: From Good Coder to High-Impact Engineer 🚀 (deep IC craft), [🤖 The AI SaaS Playbook (Practical Edition)📘](🤖 The AI SaaS Playbook (Practical Edition)📘 https://dev.to/truongpx396/the-ai-saas-playbook-practical-edition-33lb) (AI overlay), and 🚀 The SaaS Template Playbook 📖 (delivery foundations). This one is for the technical professional who is accountable for a solution end-to-end across systems, teams, and stakeholders — whether at a consulting firm, cloud vendor, ISV, or in-house enterprise team.

📋 Table of Contents

  1. ⚡ Read This First
  2. 🧠 The Solution Architect Mindset
  3. 🎭 The SA Landscape: Five Archetypes
  4. 🪜 SA vs TL vs Software Architect vs EA vs CTO
  5. 🚪 The First 90 Days
  6. 🔍 Discovery: The Real Job Begins Here
  7. 📐 Solution Design Methodology
  8. 🗂️ Documenting a Solution: C4, ADRs, arc42
  9. 🎯 Non-Functional Requirements: The Real Job
  10. ☁️ Cloud Architecture (AWS, Azure, GCP, Multi)
  11. 🔌 Integration Architecture
  12. 🗄️ Data & AI Architecture
  13. ⚖️ Build vs Buy vs Customize
  14. 🛒 Vendor Evaluation & Selection
  15. 💰 Cost & TCO Modeling
  16. 🛡️ Security, Compliance & Risk
  17. 🚚 Migration Architecture: 6Rs and Beyond
  18. 💬 Communication: Diagrams, Documents, Presentations
  19. 🤝 Stakeholder Management
  20. 🤵 Pre-Sales SA: The Consultative Sale
  21. 🛠️ Post-Sales SA: Delivery Architecture
  22. 🚀 Working with Delivery Teams
  23. ⏱️ The Operating Cadence
  24. 🤖 AI in the SA Role
  25. 🧰 Tools of the Trade
  26. ⚠️ The SA Anti-Pattern Catalog
  27. 🗺️ The Phased Roadmap (Day 1 → Year 5)
  28. 📋 Cheat Sheet & Resources

Section 1 -> 9: Read Part 1 here https://viblo.asia/p/the-solution-architect-playbook-from-best-designer-to-best-bridge-part-1-13VM9D2QVY7

Section 10 -> 20: Read Part 2 here https://viblo.asia/p/the-solution-architect-playbook-from-best-designer-to-best-bridge-part-2-PoL7e0Xa4vk

21. 🛠️ Post-Sales SA: Delivery Architecture

You won the deal, or you're an in-house SA on a greenfield. Now the work is delivery — design that ships, runs, and renews.

21.1 Phase 0: foundations

Before any feature work:

  • Landing zone (cloud accounts, network, identity, observability, baseline IAM).
  • CI/CD pipeline (test, scan, deploy to dev/staging/prod).
  • Observability stack (logs, metrics, traces, dashboards, alerts).
  • Secrets management (Vault, KMS, AWS Secrets Manager).
  • Compliance baseline (audit logging, encryption defaults, change management).
  • Reference architecture & ADR baseline.

Phase 0 typically takes 4–8 weeks. SAs new to delivery underestimate this and start feature work on shaky ground. Defer feature work; build foundations.

21.2 The delivery rhythm

Your operating cadence after Phase 0:

  • Daily: in standups occasionally (not every day — that's the TL's job). Available on Slack for unblocks.
  • Weekly: design reviews on the week's hard topics. ADR updates. Cost dashboard review.
  • Bi-weekly: stakeholder update. Risk register review.
  • Monthly: steering committee. Deep architecture review.
  • Quarterly: WAR (Well-Architected Review) or equivalent technical health check.

Keep the engineering team's calendar light and your political-comm calendar heavy. They need flow; you need alignment.

21.3 Design reviews — running them

Most teams' design reviews are bad — too long, too vague, no decisions. A working format:

  1. Pre-read (10 min before). Author posts a 3-page brief with: problem, options, recommendation, NFR impact, open questions.
  2. Reviewer prep: each reviewer reads silently, leaves comments in the doc, comes with at most 3 "must-discuss" points.
  3. Meeting (45 min max): walk the must-discuss list, decide each. Decisions captured live.
  4. Output: an updated doc + decision-log entries, sent within 24h.

Patterns that ruin reviews:

  • "Cold" review where reviewers read the doc live. Wastes the room.
  • Architect monologue. Reviewers should be reacting, not listening.
  • No decisions captured. Six weeks later, no one remembers.

21.4 Architecture governance — light, not heavy

Goal: enforce the important architectural principles (security, NFRs, integration contracts) without blocking velocity on minor decisions.

A working model:

  • Tier 1 — automated: linters, IaC policy (OPA/Sentinel), dependency scanners. The team self-services.
  • Tier 2 — peer review: PR with the right reviewer. No central architect needed.
  • Tier 3 — ADR + design review: the SA or an architecture board reviews. For the load-bearing decisions only.
  • Tier 4 — exception process: documented, time-boxed, expirable.

Anti-pattern: every change must go to the architecture board. Velocity collapses, the team goes around you, the architecture decays. Reserve the board for irreversible decisions.

21.5 The drift problem

Architectures drift. Teams adopt a new library, a new pattern, a new approach without updating the docs. Six months in, the running system doesn't match the design. Counter-measures:

  • Architecture validation in CI: probes that fail when the production topology diverges from the documented one.
  • Quarterly drift review: SA + leads walk the system vs the doc; close the gap.
  • ADRs are living: when a new decision invalidates an old one, write a new ADR; don't silently change.

21.6 The transition out

Eventually you leave the project. The transition is part of the design.

  • Documentation handoff: the next SA can read your docs cold and operate. Not a verbal walkthrough.
  • Decision log handoff: every irreversible decision documented with rationale and reversibility tag.
  • Risk register handoff: mitigations in flight, decisions still pending.
  • Stakeholder handoff: introduce the next SA in person to the top 5 stakeholders.

The mark of a good SA engagement: six months after you leave, the team is still operating well and the design is still coherent. If it falls apart in 6 weeks, you didn't transition — you abandoned.

22. 🚀 Working with Delivery Teams

You design; they build. The relationship determines whether the design lives.

22.1 Don't out-design the team

The most common SA failure: producing a design the team can't operate. Symptoms:

  • The design depends on tools the team doesn't know.
  • The design assumes 24/7 on-call when the team is 4 people EU-only.
  • The design has 11 environments, 23 services, and a service mesh; the team is 6 engineers.
  • The design optimizes for problems the team will not face for 3 years.

The fix: design with the team, not for them. Bring the TL into discovery. Bring engineers into ADRs. Walk the design with the team before the steering. They'll find issues you'd miss; they'll buy in earlier; they'll own it longer.

22.2 The SA's relationship with the TL

You and the team's tech lead are partners, not competitors. Roles:

  • TL: owns the team's velocity, code quality, day-to-day execution, sprint scope, code review.
  • SA: owns the cross-team integration, the major ADRs, the NFR negotiation, the stakeholder alignment, the long-arc design.

Lines blur in the middle. Resolve early:

  • "Who picks the unit test framework?" TL.
  • "Who decides the inter-service event schema?" SA, with TL input.
  • "Who chooses the database technology?" SA writes ADR; TL co-signs.
  • "Who runs the design review?" SA. "Who runs the sprint review?" TL.

Misalignment between SA and TL is poison — the team gets contradictory direction, picks one, the other escalates, trust evaporates. Have the conversation explicitly in week 1.

22.3 Pairing in the design

The most underused tactic in solution architecture: pair with an engineer on the hard parts of the design. Walk a flow at the whiteboard. Sketch the schema together. Run a load-test plan together. Two effects:

  1. The engineer's local truth surfaces — "actually, that join is 80ms in production, not the 8ms you think."
  2. The design becomes their design too. They defend it.

A common bad SA pattern: produce the design alone, deliver as fait accompli. The team disagrees, can't say so politely, builds something half-aligned, and resents it. Pair early.

22.4 The "spike" tool

When a design decision hinges on uncertainty (will this integration work? what's the actual latency? does this library do what its docs claim?), don't argue — spike. A 1–3 day prototype that answers exactly one question, then is thrown away. Rules:

  • Time-boxed: max 3 days. If you can't answer in 3 days, the question is too big — break it down.
  • Single-question: "Can we get sub-200ms p99 with this integration?" — yes/no.
  • Disposable: spike code is not production code. Throw it away. Do not let a spike become the foundation.

The SA either runs the spike themselves (rare) or writes the spike brief and hands it to a senior engineer.

22.5 The handoff document

When you're handing a design to delivery for build:

  • Reference architecture (C4 L1, L2, L3 of key bits).
  • All ADRs (decisions made + their rationale).
  • NFR register with acceptance tests.
  • Integration contracts (OpenAPI, AsyncAPI, schemas).
  • Runtime view (sequence diagrams of key flows).
  • Operational architecture (observability, on-call, runbook list).
  • Risk register with mitigations the team owns.
  • Open questions with named owners.

Anti-pattern: a 200-slide deck. Counter: a Markdown bundle in the repo, with diagrams in code, ADRs alongside.

23. ⏱️ The Operating Cadence

Without a cadence, the SA defaults to firefighting and inbox-archaeology. With one, the role is leveraged. The default week:

23.1 The weekly template

Block Day(s) Duration Purpose
Deep design / writing Mon, Wed AM 3h × 2 ADRs, briefs, RFC review, longer thinking
Stakeholder 1:1s Tue, Thu 30 min × 4 Sponsor, delivery TLs, EA, security, finance
Design review Wed PM 2h The team's hard design topic of the week
Vendor / external Thu PM 2h Vendor calls, partner integrations
Discovery interviews (during phase) Various 1h × 3–5 When in 30/60-day window
Steering committee prep Fri AM 2h Slides, decisions list
Steering committee (monthly) Last Fri 90 min The big meeting
Operating dashboard review Fri PM 30 min Cost, SLO, risk register, ADR backlog
Reading / learning Fri PM 1h Vendor releases, peer practice, conference talks

About 18–22h of "scheduled" work. The rest is reactive: Slack, ad-hoc unblocks, escalations, urgent design questions, customer crises. Protect the deep blocks. They're where the actual design work happens. Without them, you're just a busy person who attends meetings.

23.2 The quarterly cadence

  • Quarter open: re-confirm NFRs, refresh roadmap, re-cost the TCO.
  • Mid-quarter: WAR (Well-Architected Review) on a specific workload. Drift check.
  • Quarter end: deep retro on the quarter's design decisions — what's standing, what drifted, what should change. Update the principles set if needed.

23.3 The annual cadence

  • Strategic re-baseline: revisit the whole solution shape vs. the original vision. Is the customer's business still the same shape? Is the platform stack still the right one?
  • Cost re-baseline: full TCO recalculation with actuals; re-negotiate vendor commitments.
  • Talent / team check: who's leaving, who's growing, who needs cross-training. (Even though you don't manage them, their continuity is your design's continuity.)
  • Compliance / audit cycle: SOC 2, ISO, etc. Re-evidence controls.

23.4 Boundaries

Without protection, your calendar will fill with meetings other people benefit from.

  • No-meeting block at least one half-day a week. This is when ADRs get written.
  • Default to async. Most "let's get on a call" can be a doc comment.
  • One-screen rule: if the meeting can't be 30 minutes, it should be a doc instead.
  • The "decision-needed" filter: if the meeting has no decision needed, decline or downgrade to async update.

24. 🤖 AI in the SA Role

AI is now in every solution and every SA's workflow. Two flavors: AI in the solution you design, and AI augmenting your SA work.

24.1 AI in the solution: the patterns

Already covered in §12.3. The SA-level design points:

  • Default to LLM API + RAG for natural language workloads. Don't build a model unless data sovereignty, scale, or latency forces it.
  • Treat the LLM as an unreliable upstream — apply circuit breakers, fallbacks, evals.
  • Cost guardrails are mandatory. Token budget per tenant, prompt caching, model fallback. AI cost is the new data-egress cost — it sneaks up.
  • Evaluation harness in production. Golden sets, online evals, human review for sensitive paths.
  • Privacy review. Where do prompts go? Who can see them? How long are they retained? Most data-leak incidents in 2025 started with "we shipped an LLM call." Don't be the next one.

24.2 AI in the SA workflow

Things you can leverage AI for, today:

  • Discovery synthesis: paste interview notes, get a structured context map. Verify, don't trust blind.
  • First-draft ADRs: "Write an ADR comparing AWS Aurora vs. RDS PostgreSQL for the following NFRs." Then you edit, sign, own.
  • RFP response drafts: maintain a question bank; have the model produce first drafts; human-in-the-loop for accuracy.
  • Diagram generation: Mermaid / PlantUML / Structurizr produced from natural-language descriptions.
  • Cost modeling: spreadsheets and TCO comparisons sketched fast.
  • Threat modeling: a STRIDE walk on a C4 diagram, first-draft.
  • Documentation refresh: bring stale docs up to current state by pasting code + asking for diff.

Things to not delegate to AI:

  • The decision itself. Your name is on the ADR; you defend it; you sleep on it.
  • The stakeholder call. No model can read a CIO's mood or the silence after a security objection.
  • Final review. Models hallucinate constraints, invent compliance frameworks, and confidently misquote contracts. Always read the output as if a junior wrote it.

24.3 The hybrid workflow

A typical SA week looks like this:

  1. Spend 10 minutes describing the problem to your AI assistant. It produces a first-draft architecture brief, complete with C4 sketch, NFR draft, ADR stubs.
  2. Spend 90 minutes editing and rewriting — fixing where it's wrong, deepening where it's shallow, removing where it's overconfident.
  3. Spend 30 minutes in a stakeholder call walking the resulting brief. Record. Feed the recording back to the model for a synthesized "decisions and follow-ups" memo.
  4. Spend 15 minutes reviewing and editing the memo. Send.

The 10-90-30-15 — or thereabouts — is roughly 3× faster than pure-human and 2× higher quality than pure-AI. The "centaur" pattern is the SA's modern toolkit.

24.4 The "AI-native solution" pattern

When the customer asks for an "AI-native" solution, what they often want is a human-in-the-loop system: the model does the heavy lifting; the human approves, edits, escalates. The architectural shape:

  • Inference layer (LLM + RAG + tools).
  • Action layer with explicit approval/escalation gates.
  • Observability layer that captures every prompt, response, decision.
  • Eval layer that scores model outputs continuously.
  • Cost layer that tracks per-tenant spend, caps it, alerts.
  • Compliance layer with audit logs of every model interaction.

This shape repeats across customer support, document review, code review, content moderation, claims processing. Recognize it; reuse it.

25. 🧰 Tools of the Trade

A lean toolkit beats a sprawling one. The SAs who deliver consistently rely on a small, mastered set.

25.1 The core kit

  • Diagramming: Excalidraw (whiteboard), Mermaid (in-doc), Structurizr or Lucidchart (formal C4). Stop using Visio for living architecture.
  • Documentation: Markdown in Git, with ADRs as files. Confluence as a publish target, not a source of truth.
  • Modeling: Spreadsheet (Google Sheets, Excel) for TCO, capacity, NFR matrix. Don't underestimate the spreadsheet.
  • Diagrams-as-code: Mermaid for flow/sequence, Structurizr DSL for C4, draw.io / Excalidraw for sketches. Diagrams in code stay current; diagrams in PowerPoint die.
  • Knowledge management: a personal Obsidian / Notion vault for vendor research, customer notes, design patterns, cheat sheets. Reuse aggressively.
  • AI assistant: Claude / ChatGPT / Cursor / Codeium. Become fluent.
  • Collaboration: Slack / Teams for ambient, doc comments for considered, calendar for protected.
  • Project tracking: Linear / Jira for the team, your own running decision log alongside. Don't run the SA's life inside the PM tool.

25.2 Cloud-specific tooling

  • AWS: Well-Architected Tool, Cost Explorer, Trusted Advisor, AWS Application Composer.
  • Azure: Azure Advisor, Cost Management, Architecture Center reference docs.
  • GCP: Active Assist, Cost Recommender, Architecture Framework docs.

For each cloud, there's a vendor-published reference architecture catalog. Read these. Most of your design has been done before by the vendor and is sitting on their site, free.

25.3 The frameworks that pay back

  • C4 model: covered in §8.
  • arc42: covered in §8.
  • TOGAF: enterprise architecture framework. Useful in regulated big-cos. Skim TOGAF 10's ADM cycle once; you'll recognize the pattern in EA conversations. Don't try to be TOGAF.
  • AWS Well-Architected Framework / Azure WAF / GCP Architecture Framework: the cloud-vendor lens. Run a review at gates.
  • DDD (Domain-Driven Design): useful for bounded contexts and cross-team boundaries. Read the Eric Evans book once; quote sparingly.
  • Risk-Based Architecture: surface the top 5 risks and design to mitigate them; bias time-spent toward risk-resolution.

25.4 Reading discipline

The SA who falls behind on the platform stack ages out fast. A working diet:

  • 1 hour a week minimum, blocked, on cloud release notes (one cloud, alternated).
  • 1 vendor briefing or webinar a month on a new category (vector DB, observability, security).
  • 1 architecture-related book a quarter — Designing Data-Intensive Applications, Software Architecture: The Hard Parts, the Phoenix/Unicorn series, Accelerate, Domain-Driven Design, Building Microservices.
  • 1 conference a year, if possible. KubeCon, AWS re:Invent, Azure Build, QCon, GOTO, DDD Europe — pick by what you're designing.

26. ⚠️ The SA Anti-Pattern Catalog

The recurring mistakes. Recognize, name, avoid.

26.1 The Architecture Astronaut

Symptom: layers of abstraction, every system a kafka-event-driven hexagonal-domain mesh, no actual feature ships in 6 months.

Cause: SA is more interested in being clever than in being useful.

Counter: every design has a "what would the simplest thing be?" sentence. If your design is 10× more complex than the simple thing, defend the 10× explicitly. Often it can be cut.

26.2 The Vendor-Captured SA

Symptom: every problem is a use-case for the SA's favorite vendor (AWS Step Functions, ServiceNow, Snowflake — pick your poison).

Cause: certifications, comfort, sales relationship, or being employed by said vendor.

Counter: ask "what would I recommend if this customer was on a different stack?" The answer reveals captivity.

26.3 The Diagram-Heavy, Decision-Light SA

Symptom: 80-page design pack, zero ADRs, "design is still being finalized" for 6 months.

Cause: avoiding the discomfort of irreversible decisions.

Counter: target 1 ADR per week. If a week passed without one, you're stalling.

26.4 The Whiteboard Designer Who Never Ships

Symptom: brilliant in the room, vague on paper, the team builds something different from what was discussed.

Cause: the design lives in the SA's head; the team builds what they understood, which is different.

Counter: write before you whiteboard. Or whiteboard, then immediately photograph and write up. The artifact is the design; the meeting is the discussion about it.

26.5 The "Forever in Discovery" SA

Symptom: month 4, still no design. Just more interviews. The customer is paying.

Cause: fear of committing, masquerading as thoroughness.

Counter: time-box discovery (30 days for most engagements, 60 for big enterprise). After that, ship a design even if rough. Iterate.

26.6 The Over-Architect of Trivial Things

Symptom: a 12-page ADR on the choice between two equivalent libraries. A formal design review for a config flag.

Cause: applying one-way-door rigor to two-way-door decisions.

Counter: explicitly tag every decision as one-way or two-way. Defaults: two-way → fast/cheap. One-way → slow/careful.

26.7 The Solo Architect

Symptom: design is "done," delivery team has questions you can't answer because the design didn't survive contact with the team.

Cause: producing the design alone, without the team.

Counter: design pairing (§22.3). The first draft is yours; the second draft is the team's; the third draft is jointly owned.

26.8 The "Build to Resume" SA

Symptom: every solution involves the technology the SA wants experience with — Kubernetes, Kafka, Cassandra — regardless of fit.

Cause: SA's career incentives ≠ customer's outcome.

Counter: declare your preferences explicitly to a peer; have them challenge you. Or use the "would I recommend this in 5 years to a friend" test.

26.9 The Compliance-Avoider

Symptom: design ignores compliance until week 18, then a compliance review forces a 3-month redesign.

Cause: compliance is boring; engineers postpone.

Counter: bring compliance into discovery. Make compliance constraints explicit in NFRs. Treat them as design inputs, not gates.

26.10 The Cost-Blind SA

Symptom: design works perfectly; bill is 4× what the customer expected; CFO kills the project.

Cause: cost was finance's problem.

Counter: TCO is part of the design (§15). Cost is an NFR. Defend it like latency.

26.11 The Handoff Cliff

Symptom: SA designs, leaves; six months later the team has rewritten half of it.

Cause: design didn't fit the team's reality; team wasn't on board.

Counter: pair-design with the team (§22.3); transition in (§21.6) rather than out.

26.12 The Status-Update Theater

Symptom: weekly 12-slide deck, beautiful charts, but the steering can't tell what's blocked or decide anything.

Cause: confusing visibility with clarity.

Counter: use the boring template (§18.5). Lead with RAG, lead with decisions needed, lead with risks updated.

26.13 The Promised Feature

Symptom (pre-sales): SA promises capability X in the demo to win the deal; delivery team didn't know; deal churns.

Cause: incentive misalignment, no internal review of commitments.

Counter: every promise is a written delivery commitment, reviewed by delivery before the SOW signs.

26.14 The "Single Source of Truth" That Isn't

Symptom: three Confluence pages, two Notion docs, one diagram in Lucidchart, and a Slack thread — all describing the same thing, all slightly different.

Cause: no documentation discipline.

Counter: ONE source-of-truth, declared and linked. Everything else is a mirror or summary, with link-back. Old artifacts archived, not deleted.

26.15 The Architecture Board That Slows Everything

Symptom: every change must go through a weekly board, the queue is 4 weeks long, teams route around it.

Cause: governance over-applied.

Counter: tier governance (§21.4). Most changes are auto + peer; only the load-bearing ones go to the board.

27. 🗺️ The Phased Roadmap (Day 1 → Year 5)

Where you are in your SA career changes which sections matter most.

27.1 Year 0–1: The new SA

You are: a senior engineer or tech lead newly given an SA title, or a first-job SA at a vendor.

Focus:

  • §2 Mindset (it's the hardest shift)
  • §6 Discovery (where most failures originate)
  • §8 ADRs (the deepest skill compound)
  • §9 NFRs (the contract — overlearn it)
  • §18 Communication (writing first, then diagrams)

Avoid:

  • Pretending you have authority you don't.
  • Diagrams without numbers.
  • Designing alone.

Win: ship one solution end-to-end, with documented ADRs, that runs in production and gets renewed.

27.2 Year 2–3: The competent SA

You are: shipping multiple solutions, recognized as the technical lead in a room of stakeholders.

Focus:

  • §13 Build vs Buy (becomes your highest-leverage skill)
  • §14 Vendor evaluation (RFP responses, PoCs)
  • §15 Cost (the language of business)
  • §19 Stakeholder management (the underrated skill)
  • §22 Working with delivery teams (your designs need to ship through people)

Avoid:

  • Becoming captive to a single vendor or stack.
  • Letting your IC craft atrophy completely (the role still needs technical credibility).
  • Thinking the role is done at the SOW signature.

Win: a solution you designed at year 2 is still running well at year 4, run by a team you trust.

27.3 Year 4–6: The principal SA

You are: trusted with the largest, most ambiguous engagements. Mentoring junior SAs.

Focus:

  • §3 Archetypes (consciously choosing your seat)
  • §7 Methodology (yours, opinionated, repeatable)
  • §10–11 Cloud + integration patterns at depth
  • §16 Compliance (becomes a competitive advantage)
  • §24 AI in the role (centaur workflow)

Avoid:

  • Becoming the bottleneck for every decision (delegate downward; mentor up).
  • Drifting into pure pre-sales or pure delivery — keep both muscles.
  • Thinking the playbook is done; the platform stack changes every 2 years.

Win: your patterns (templates, ADR catalog, NFR register, vendor scorecards) are reused across engagements. You are the one teaching the next SA.

27.4 Year 7+: The strategic SA / Chief Architect / EA

Your fork:

  • Path A: Principal SA — bigger, more strategic engagements, fewer of them, deeper. The "we hire you for the hard ones" path.
  • Path B: Chief Architect / Director — own the SA practice; mentor a team of architects; set standards. People-leverage.
  • Path C: Enterprise Architect — multi-year horizon, capability heatmaps, governance board. Less project, more program.
  • Path D: CTO / VPE — you take on the org. Read 👨‍💻 The CTO Playbook 📘: From Best Builder to Best Bet ♟️.

The skills overlap, but the daily life diverges sharply. Choose deliberately. Many great SAs miscast themselves into a chief-architect role and find they hate management; many great chief architects miscast themselves into a CTO role and find they hate the board. Try the role for 6 months in some way (interim, secondment, shadowing) before committing.

28. 📋 Cheat Sheet & Resources

28.1 The 30-second SA pitch

"I'm the Solution Architect for [project]. My job is to deliver a runnable, affordable, supportable solution that closes the business problem within the agreed constraints, working through teams I do not manage and stakeholders I do not control. I will spend the first 30 days listening, the next 30 framing, the next 30 designing and gating, and the rest delivering — through ADRs, an NFR register, a TCO model, and a risk register that I'll keep alive and visible."

28.2 The questions a good SA asks every week

  • "What's the most likely way this project goes wrong this quarter?"
  • "What decision is stuck because nobody owns it?"
  • "What's the cost trajectory vs. what we modeled?"
  • "What's drifting from the design?"
  • "Who hasn't I talked to in two weeks who matters?"

28.3 The pre-meeting checklist

Before any architecture-related meeting:

  • Pre-read sent? (≥24h ahead)
  • Decision needed today, named explicitly?
  • Decider in the room?
  • Alternatives on a slide / in the doc?
  • NFR impact stated?
  • Cost impact stated?
  • Reversibility tagged?
  • Note-taker assigned?

If five of eight are no, the meeting will fail. Reschedule.

28.4 The "ship it or not" gate

Before declaring a solution shippable:

  • All P1 NFRs have passing acceptance tests
  • Threat model signed by security
  • Compliance posture documented
  • TCO Y1 within budget; Y3 within tolerance
  • DR drilled at least once
  • On-call rotation staffed and trained
  • Runbooks for the top 5 incidents
  • Observability covering the critical paths
  • ADRs current and reviewed
  • Risk register reviewed and at acceptable residual

If any are no, ship a limited go-live (single tenant, soft-launch, beta) — not a full GA.

28.5 Reusable artifact templates

Maintain a personal vault with reusable templates:

  • ADR template (Markdown)
  • Architecture brief template (arc42)
  • NFR register (spreadsheet)
  • TCO model (spreadsheet, parameterized)
  • Risk register (spreadsheet)
  • Vendor scorecard (spreadsheet)
  • Discovery interview script
  • Steering committee deck skeleton (≤10 slides)
  • Status update template
  • Threat model template (STRIDE)

Each saves hours per engagement and improves quality. Sharpen them every quarter.

28.6 The reading list (focused)

If you only read 5 books in your SA career:

  1. Designing Data-Intensive Applications — Kleppmann. The vocabulary of data architecture.
  2. Software Architecture: The Hard Parts — Ford, Richards. Tradeoffs, distributed systems, decision frameworks.
  3. Fundamentals of Software Architecture — Ford, Richards. The companion volume.
  4. Building Microservices — Newman. Even if you don't do microservices, the boundary thinking is essential.
  5. The Phoenix Project + The Unicorn Project — Kim. Operational thinking. Less "architecture," more "why architecture fails in practice."

Plus periodically:

  • Domain-Driven Design — Evans (skim, but you must know the vocabulary)
  • Accelerate — Forsgren et al. (the metrics that matter)
  • Site Reliability Engineering — Beyer et al. (the operational mindset)
  • Thinking in Systems — Meadows (the meta-skill)

28.7 Online resources

  • Cloud reference architectures: AWS Architecture Center, Azure Architecture Center, GCP Architecture Framework. Free, vendor-published, current.
  • Martin Fowler's site: martinfowler.com. Patterns and articles aging extraordinarily well.
  • Simon Brown's C4 model: c4model.com. Read this once.
  • arc42: arc42.org. Templates and examples.
  • High Scalability: highscalability.com. Real-world architectures.
  • InfoQ Architecture queue: infoq.com.
  • CNCF Landscape: landscape.cncf.io. The platform-tooling map.

28.8 The companion playbooks in this repo

28.9 The closing reminder

The Solution Architect role is one of the most leveraged in tech: a single good solution shipped for the right reasons can save a customer years and millions, and a single misframed one can burn the same. You sit at a unique intersection: technical enough to design, business-fluent enough to negotiate, organized enough to deliver, and patient enough to listen. Few roles touch all four — most engineers are stronger on the design axis but weaker on the others. The SAs who scale are the ones who deliberately level all four, year over year.

The work compounds. Every engagement teaches you a constraint you hadn't seen, a vendor who let you down, a stakeholder who taught you a new question, a design that survived contact with reality and another that didn't. Keep your vault. Update your patterns. Mentor the next SA. The discipline is younger than software engineering itself; the next decade of practice is being written by the people who are practicing it now, deliberately. Be one of them.

If you found this helpful, let me know by leaving a 👍 or a comment!, or if you think this post could help someone, feel free to share it! Thank you very much! 😃

Android iOS JavaScript ReactJS

All rights reserved

Mục lục


Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí