Nội dung
01Mục đích & phạm vi
Chuẩn hoá cách hiểu về vai trò Solution Architect trong SU02, làm cơ sở cho khảo sát năng lực, chương trình Architecture Dojo, phân công trách nhiệm trong dự án, và lộ trình nghề nghiệp Dev → Tech Lead → Solution Architect.
Áp dụng cho: toàn bộ Developer, Tech Lead, Solution Architect và Project Manager của SU02.
Vì sao cần Charter trước khi khảo sát. Nếu Tech Lead và Developer chưa có cách hiểu thống nhất về vai trò SA, mọi kết quả tự đánh giá đều vô nghĩa — ai cũng sẽ tự chấm là "biết thiết kế hệ thống". Charter là điều kiện tiên quyết, không phải tài liệu bổ trợ.
02Định nghĩa vai trò
Solution Architect tại SU02 là người chịu trách nhiệm về tính đúng đắn kỹ thuật của giải pháp ở phạm vi vượt ra ngoài một team — bao gồm cách hệ thống được chia tách, cách các hệ thống nói chuyện với nhau, và cách giải pháp đáp ứng các ràng buộc phi chức năng trong dài hạn.
SA không phải là dev giỏi nhất. SA không phải người ra quyết định thay Tech Lead trong phạm vi một team. SA là người trả lời câu hỏi: "cấu trúc này còn đứng vững sau 18 tháng và 5 lần thay đổi yêu cầu không?"
03Ranh giới Developer / Tech Lead / Solution Architect
| Khía cạnh | Developer | Tech Lead | Solution Architect |
|---|---|---|---|
| Phạm vi | Module / feature | 1 team, 1 sản phẩm | Cross-system, cross-team |
| Chân trời thời gian | Sprint | Sprint → quý | Quý → 24 tháng |
| Câu hỏi trung tâm | Code này chạy đúng chưa? | Team làm đúng cách chưa? | Cấu trúc này còn đúng khi quy mô gấp 10 không? |
| Sản phẩm | Code, unit test | Coding standard, code review, technical plan sprint | HLD, ADR, integration contract, NFR spec |
| Thất bại điển hình | Bug lọt production | Nợ kỹ thuật tích tụ trong team | Hệ thống không scale / không tích hợp được / phải viết lại |
| Ảnh hưởng | Chất lượng feature | Năng lực team | Chi phí và tốc độ của cả portfolio |
04Ranh giới với PM, BA và Core Telco
PM
Khi nào & nguồn lực nào
PM sở hữu tiến độ và nguồn lực. SA sở hữu cách làm về mặt kỹ thuật. Khi SA nói "phương án này cần thêm 3 tuần", PM là người quyết định đánh đổi — SA có trách nhiệm nêu rõ hậu quả của việc bỏ qua.
BA
Bài toán nghiệp vụ là gì
BA sở hữu vấn đề nghiệp vụ và yêu cầu chức năng. SA chuyển bài toán đó thành ràng buộc kỹ thuật định lượng được: bao nhiêu user, bao nhiêu TPS, độ trễ chấp nhận được.
Core Telco
Hệ thống lõi
Core Telco SA sở hữu ràng buộc và hệ quả lên hệ thống lõi. SU02 SA sở hữu kiến trúc giải pháp và integration contract phía Delivery. Điểm chạm phải có contract với tên người chịu trách nhiệm hai phía.
§4.1 — Giới hạn phạm vi. SA trong Charter này là SA phía Software Delivery: chịu trách nhiệm kiến trúc giải pháp của sản phẩm được giao phát triển. Vai trò SA phía Core Telco gắn với quyền sở hữu hệ thống lõi và bối cảnh nghiệp vụ viễn thông. Hai vai trò cùng tên gọi nhưng khác phạm vi — khi cùng tham gia một dự án phải làm rõ ai sở hữu điểm chạm.
05Sáu trách nhiệm cốt lõi
| # | Trách nhiệm | Nghĩa là gì trong công việc hàng ngày |
|---|---|---|
| 1 | Làm rõ ràng buộc trước khi thiết kế | Không nhận yêu cầu rồi vẽ ngay. Phải định lượng được NFR: số user, TPS đỉnh, độ trễ chấp nhận được, dữ liệu được phép mất bao nhiêu (RPO/RTO). |
| 2 | Phân rã hệ thống, xác định ranh giới | Cái gì là một service, cái gì không, ranh giới đặt ở đâu và vì sao đặt ở đó chứ không phải chỗ khác. |
| 3 | Sở hữu integration contract | Mọi điểm hai hệ thống chạm nhau đều phải có hợp đồng rõ ràng, có người chịu trách nhiệm hai phía, có phiên bản, có cách tiến hoá. |
| 4 | Ghi lại quyết định kiến trúc | Mọi quyết định không thể đảo ngược trong dưới 1 tháng đều phải có ADR: bối cảnh, các phương án, đánh đổi, quyết định, hệ quả. |
| 5 | Bảo vệ thuộc tính chất lượng | Performance, availability, security, cost. SA là người duy nhất có trách nhiệm nêu ra khi những thứ này đang bị hy sinh âm thầm. |
| 6 | Nâng năng lực xung quanh | SA không giữ kiến thức, SA lan toả nó. Đây là tiêu chí đánh giá, không phải việc làm thêm khi rảnh. |
06Sản phẩm bắt buộc
| Sản phẩm | Khi nào | Người duyệt |
|---|---|---|
| Solution Overview (C4 Level 1–2) | Trước khi bắt đầu development | TP / SA cấp trên |
| NFR Specification | Cùng lúc với BRD sign-off | PM + Sponsor |
| ADR | Mỗi quyết định không thể đảo ngược nhanh | Peer SA / TP |
| Integration Contract | Trước khi hai team bắt đầu code | SA hai phía |
| Technical Risk Register | Kick-off, cập nhật hàng tháng | PM |
Nguyên tắc tài liệu: vừa đủ để người khác ra quyết định đúng, không phải để đầy hồ sơ. Một ADR 1 trang tốt hơn một HLD 40 trang không ai đọc.
07Quyền quyết định & escalation
| Loại quyết định | Người quyết | Người tham vấn bắt buộc |
|---|---|---|
| Ngôn ngữ / framework trong 1 service | Tech Lead | SA |
| Tách hay gộp service | SA | TL, PM |
| Chọn cơ chế tích hợp giữa 2 hệ thống | SA | TL hai phía |
| Chọn database / message broker mới | SA | TL, Hạ tầng |
| Đánh đổi scope vs kiến trúc | PM | SA (bắt buộc) |
| Chấp nhận nợ kiến trúc có chủ đích | PM + SA đồng thuận | TP |
| Build vs Buy | TP / BGĐ | SA (phân tích) |
Escalation: SA và TL bất đồng → TP quyết trong 48 giờ. SA và PM bất đồng về đánh đổi → ra quyết định kèm ghi nhận rủi ro bằng văn bản, không tranh luận kéo dài.
08Bốn mức năng lực
| Mức | Tên | Đặc trưng | Phạm vi ảnh hưởng |
|---|---|---|---|
| SA0 | Architecture Aware | Đọc hiểu và tuân theo kiến trúc có sẵn. Biết đặt câu hỏi đúng khi thiết kế không hợp lý. | Module |
| SA1 | Associate Architect | Thiết kế được một hệ thống vừa dưới hướng dẫn. Biết hỏi NFR nhưng chưa định lượng chắc. Viết được ADR. | 1 sản phẩm |
| SA2 | Practitioner | Thiết kế độc lập hệ thống nhiều thành phần. Xử lý ràng buộc mâu thuẫn. Bảo vệ phương án dưới phản biện. Dẫn dắt tích hợp cross-team. | 2–3 sản phẩm |
| SA3 | Lead Architect | Đặt chuẩn kiến trúc cho portfolio. Ra quyết định build/buy có phân tích chi phí. Kiến trúc lại hệ thống legacy đang chạy. Phát triển SA khác. | Portfolio |
Điều kiện lên mức — cần cả hai: điểm rubric từ Architecture Dojo và bằng chứng thực tế trong dự án (ADR đã được áp dụng, hệ thống đã go-live theo thiết kế của mình). Chỉ có điểm Dojo mà không có bằng chứng thực chiến thì trần ở SA1 — áp cùng nguyên tắc Evidence Factor của ECF.
09Anti-patterns
AP-1
SA tháp ngà
Vẽ xong ném cho team, không tham gia khi thiết kế va vào thực tế.
AP-2
SA gác cổng
Biến mình thành nút thắt duyệt mọi thứ, làm chậm team thay vì tăng tốc.
AP-3
SA vẽ theo công nghệ
Chọn kiến trúc vì công nghệ hay, không vì bài toán. CV-driven architecture.
AP-4
SA né đánh đổi
Đưa ra phương án "lý tưởng" bỏ qua ngân sách, thời gian và năng lực đội ngũ.
AP-5
SA im lặng
Thấy nợ kiến trúc đang hình thành nhưng không nêu vì ngại PM hoặc ngại xung đột.
AP-6
TL bị gọi là SA
Đổi tên chức danh mà không đổi phạm vi trách nhiệm và quyền quyết định.
10Cách SA được đánh giá
Không đánh giá bằng số lượng tài liệu viết ra. Đánh giá bằng bốn tín hiệu:
| Tín hiệu | Cách quan sát |
|---|---|
| Độ chính xác của dự báo | Rủi ro kỹ thuật đã cảnh báo có xảy ra không. Sự cố đã xảy ra có nằm trong những thứ bị bỏ qua không. |
| Tỉ lệ quyết định phải đảo ngược | Thấp là tốt. Nhưng bằng 0 nghĩa là đang chơi quá an toàn, không dám quyết. |
| Chất lượng tích hợp | Số lần hai team phải sửa lại vì hiểu sai contract. |
| Năng lực lan toả | Số Tech Lead / Developer tự thiết kế được sau khi làm việc với SA này. |