01 Quyết định kiến trúc & ADR
Ra quyết định định hướng là kỳ vọng cốt lõi của KTS. Ba anti-pattern hay gặp:
Covering Your Assets
Trì hoãn/né quyết định vì sợ sai.
Groundhog Day
Tranh luận lặp lại mãi vì không ai nhớ vì sao quyết định trước.
Email-Driven
Quyết định thất lạc/bị quên vì truyền miệng qua email thay vì lưu tập trung.
ADR — Architecture Decision Record (7 phần)
Tệp văn bản ngắn (1–2 trang) tài liệu hoá một quyết định quan trọng về kiến trúc (ảnh hưởng cấu trúc, đặc tính phi chức năng, phụ thuộc, giao diện, kỹ thuật xây dựng):
Title
Tên ngắn, đánh số thứ tự.
Status
Proposed · Accepted · Superseded · RFC.
Context
Tình huống & các lựa chọn thay thế.
Decision
Khẳng định hành động kèm lý do "vì sao".
Consequences
Tác động tốt & xấu — phân tích đánh đổi.
Compliance
Đo & kiểm soát ra sao (thủ công / fitness function).
Notes
Siêu dữ liệu: tác giả, ngày phê duyệt…
RAG ADR chính là chỗ lưu cái "WHY" của Định luật 2 (topic 01) — ví dụ cho hệ RAG:
# ADR-012: Dùng pgvector thay vì Pinecone
Status: Accepted
Context: dữ liệu nội bộ, đã có Postgres, quy mô < 5M vector.
Decision: pgvector — WHY: giảm hạ tầng & chi phí, giữ ACID metadata + vector.
Consequences: (+) đơn giản, 1 DB; (−) khó scale > chục triệu vector → xem lại sau.
Compliance: fitness function kiểm p95 truy hồi < 200ms mỗi CI.02 Phân tích rủi ro kiến trúc
Rủi ro = Tác động (Impact) × Khả năng xảy ra (Likelihood), mỗi chiều Thấp(1)/Trung bình(2)/Cao(3). Tích 1–9 phân màu:
Risk Storming — 3 bước cộng tác
Định danh (cá nhân)
Mỗi người tự chấm rủi ro trên sơ đồ — không thảo luận để tránh ảnh hưởng lẫn nhau.
Đồng thuận (cả đội)
Thảo luận để thống nhất mức rủi ro lên cùng một sơ đồ kiến trúc.
Giảm thiểu
Đề xuất thay đổi kiến trúc để hạ rủi ro.
RAG Risk storming cho RAG: phụ thuộc vendor LLM (khả năng cao × tác động cao = đỏ) → giảm thiểu bằng lớp adapter đổi vendor (topic 07) + fallback model nội bộ; rò rỉ tài liệu nội bộ (bảo mật) cũng đáng đưa lên ma trận.
03 Vẽ sơ đồ & thuyết trình
Tính nhất quán biểu diễn (representational consistency): luôn cho thấy quan hệ tổng thể trước khi đi sâu, để người xem không lạc.
Mô hình C4 — bốn mức zoom
1 · Context
Hệ thống & người dùng/hệ ngoài xung quanh — bức tranh xa nhất.
2 · Container
App/DB/service triển khai được bên trong hệ.
3 · Component
Các khối bên trong một container.
4 · Code
Chi tiết lớp — mức gần nhất (UML class/sequence).
Mẹo sơ đồ: có tiêu đề; nét liền = đồng bộ, nét đứt = bất đồng bộ; nhãn rõ; màu phân biệt; kèm bảng chú giải (key). Chuẩn khác: UML, ArchiMate.
Thuyết trình — tránh "Death by PowerPoint"
Bullet-Riddled Corpse
- Slide đầy chữ → khán giả mải đọc, không nghe.
- Các slide rời rạc, không kể chuyện.
Kể chuyện liền mạch
- Incremental build: hiện thông tin đúng lúc nói tới.
- Transition để điều khiển thời gian; slide đen để hút chú ý về người nói.
- Phân biệt infodeck (gửi đọc) vs presentation (hỗ trợ người nói).
04 Giúp đội nhóm hiệu quả
KTS đặt ranh giới kiểm soát cho đội — ba kiểu, như truyện "ba chú gấu": quá chặt, quá lỏng, và vừa phải.
Control Freak
Can thiệp quá sâu vào code → lập trình viên ức chế, mất động lực.
Armchair Architect
"Tháp ngà", không quan tâm chi tiết triển khai thực tế.
Effective Architect
Đặt ranh giới đúng mức, trao hướng dẫn & công cụ phù hợp.
Mức kiểm soát co giãn theo 5 yếu tố: độ quen thuộc của đội · kích thước đội · kinh nghiệm tổng thể · độ phức tạp dự án · thời gian dự án.
Dấu hiệu cảnh báo & checklist
Process loss
Thêm người lại làm chậm đi.
Pluralistic ignorance
Đồng ý theo số đông dù thâm tâm phản đối, vì sợ lạc lõng.
Diffusion of responsibility
Đội quá đông → không ai chịu trách nhiệm chính.
Dùng checklist cho các bước hiển nhiên dễ sót: hoàn thiện mã (code completion), kiểm thử đơn vị/chức năng, phát hành phần mềm.
05 Thương lượng, lãnh đạo & sự nghiệp
KTS thương lượng suốt: với stakeholder (chi phí/thời gian), với KTS khác (ý tưởng), với lập trình viên (cách triển khai).
Chứng minh > tranh luận
Dùng thực tế (POC, số liệu) thuyết phục thay vì cãi vã. Cung cấp lý do thay vì ra lệnh từ trên cao.
4 chữ C
Communication · Collaboration · Clarity · Conciseness. Lãnh đạo bằng ví dụ: ngồi cùng đội, dự code review, thành "người đáng tin cậy".
Giữ mình cập nhật — Radar & quy tắc 20 phút
Quy tắc 20 phút: mỗi sáng, trước khi đọc email, dành ≥20 phút học công nghệ mới để giữ bề rộng (breadth — nhớ topic 01).
Tận dụng mối liên kết yếu (weak links) trên mạng xã hội — nguồn ý tưởng & cơ hội ngoài vòng quen.
Luôn học hỏi, luôn thực hành, và luôn ghi lại vì sao đằng sau mỗi quyết định kiến trúc.
Lời khuyên cuối · Richards & Ford06 Ghi nhớ nhanh
Ghi quyết định bằng ADR — 7 phần, lưu cái "vì sao"; chống Groundhog Day & Email-Driven Architecture.
Rủi ro = Impact × Likelihood (1–9) — dùng risk storming 3 bước (cá nhân → đồng thuận → giảm thiểu).
C4 + nhất quán biểu diễn — zoom Context→Container→Component→Code; nét liền/đứt = sync/async. Đừng "Death by PowerPoint".
Làm Effective Architect — ranh giới vừa phải, co giãn theo 5 yếu tố; cảnh giác process loss & khuếch tán trách nhiệm.
4 chữ C + quy tắc 20 phút — chứng minh hơn tranh luận; giữ radar cá nhân để không tụt hậu.