title: "Thiết lập Architecture Capability: Xây dựng khung năng lực cho một đội ngũ EA chuyên nghiệp"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 1 — Tầng Triết lý & Chiến lược Kiến trúc (EA Foundations)"
order: 5
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• TOGAF
• Architecture Capability
• Enterprise Architecture
• Architecture Governance
• Architecture Repository
• EA Maturity

Thiết lập Architecture Capability: Xây dựng khung năng lực cho một đội ngũ EA chuyên nghiệp

Có một câu hỏi tôi luôn hỏi khi review một tổ chức tự nhận là "đã có EA": "Nếu Chief Architect của các anh nghỉ việc chiều nay, sáng mai công ty còn biết vì sao hệ thống được thiết kế như hiện tại không?" Phần lớn im lặng. Một số trả lời thẳng: "Chắc phải đoán lại từ đầu."

Đó là dấu hiệu rõ nhất của một tổ chức có một người làm kiến trúc, chứ không có năng lực kiến trúc. Sự khác biệt tưởng nhỏ nhưng là ranh giới sống còn: một người thì mong manh, rời đi là mất; một năng lực (capability) thì là tài sản tổ chức — có vai trò, có quy trình, có tri thức được ghi lại, có cơ chế ra quyết định độc lập với bất kỳ cá nhân nào. TOGAF gọi việc xây dựng tài sản này là Architecture Capability, và có hẳn một khung riêng cho nó — Architecture Capability Framework — nằm song song với ADM (Architecture Development Method) chứ không phải một giai đoạn phụ trong đó.

Nhiều Solutions Architect giỏi kỹ thuật khi được đôn lên làm Chief Architect mắc đúng sai lầm này: họ lo vẽ Target Architecture, lo chọn công nghệ, lo review thiết kế — toàn bộ năng lượng đổ vào sản phẩm của kiến trúc. Không ai lo xây bộ máy sản xuất ra kiến trúc. Đến khi họ rời đi hoặc đội ngũ scale gấp ba, cả doanh nghiệp mới phát hiện toàn bộ tri thức nằm trong một cái đầu, không nằm trong tổ chức.

Bản chất

Architecture Capability, theo đúng tinh thần TOGAF, là năng lực tổ chức để thực hiện kiến trúc doanh nghiệp một cách lặp lại, nhất quán và bền vững — không phụ thuộc vào bất kỳ cá nhân cụ thể nào. Nó trả lời bốn câu hỏi thể chế:

1. Ai có quyền ra quyết định kiến trúc, và quyết định đó được governance như thế nào? (Architecture Board / Governance)
2. Làm thế nào một kiến trúc được phát triển, review, phê duyệt — quy trình nào, gate nào? (Architecture Process)
3. Ai đủ năng lực làm công việc đó, và năng lực được phát triển/đánh giá ra sao? (Architecture Skills Framework)
4. Tri thức kiến trúc được lưu ở đâu để người mới có thể tiếp cận mà không cần hỏi lại người cũ? (Architecture Repository)

Bốn thành phần này không phải danh sách tùy chọn — chúng là bốn chân của một cái bàn. Thiếu một chân, cái bàn vẫn có thể đứng tạm nhờ ai đó ghì tay giữ (thường là Chief Architect hiện tại), nhưng buông tay ra là đổ.

Điểm dễ hiểu lầm nhất: Architecture Capability không đồng nghĩa với một phòng ban lớn. Một tổ chức 200 người hoàn toàn có thể có Architecture Capability trưởng thành với 1-2 kiến trúc sư kiêm nhiệm, miễn là bốn thành phần trên tồn tại ở dạng tối giản nhưng có thật — có văn bản, có quy trình được viết ra, không chỉ tồn tại trong thói quen ngầm của một người. Ngược lại, một tổ chức 2.000 người có hẳn "phòng Kiến trúc doanh nghiệp" 15 nhân sự vẫn có thể chỉ là "một người làm EA" trá hình nếu mọi quyết định thực chất chỉ đi qua một Chief Architect độc đoán, còn lại là người thực thi không có tiếng nói.

Capability trưởng thành hay không đo bằng mức độ tri thức và quyền quyết định được phân tán và thể chế hóa, không đo bằng headcount.

Khung & Kỹ thuật áp dụng

Bốn thành phần của Architecture Capability

Lộ trình trưởng thành: từ một cá nhân đến một năng lực

Đừng kỳ vọng dựng cả bốn thành phần cùng lúc — đó là cách chắc chắn thất bại vì quá tải tổ chức. Thứ tự thực tế nên đi theo mức độ rủi ro giảm dần khi mất người:

Cấp 0 — Cá nhân anh hùng (Heroic Individual). Một người biết hết, quyết hết, không văn bản. Đây là điểm khởi đầu của hầu hết công ty, không phải điều đáng xấu hổ — nhưng là trạng thái rủi ro cao cần thoát ra càng sớm càng tốt.

Cấp 1 — Ghi lại quyết định (Decision Log tối thiểu). Bước rẻ nhất, hiệu quả nhất, thường bị bỏ qua: bắt buộc mọi quyết định kiến trúc quan trọng (chọn công nghệ, đổi pattern, chấp nhận nợ kỹ thuật có chủ đích) phải có một Architecture Decision Record (ADR) ngắn — bối cảnh, phương án đã cân nhắc, lý do chọn, ngày, người quyết. Đây chính là hạt giống của Architecture Repository.

Cấp 2 — Governance tối thiểu khả thi. Lập một Architecture Board nhỏ (có thể chỉ 3 người: Chief Architect + 1-2 Lead Engineer/Product) họp định kỳ để review các quyết định lớn thay vì để một người tự quyết. Không cần hoành tráng — một buổi 45 phút mỗi hai tuần với biên bản là đủ để phá vỡ tình trạng "một đầu quyết hết".

Cấp 3 — Quy trình được viết ra. Chuẩn hóa Architecture Process: khi nào cần Architecture Vision, khi nào cần review Board, tiêu chí pass/fail của một thiết kế. Neo theo các giai đoạn ADM sẽ được đào sâu ở Phần 2 của series này.

Cấp 4 — Năng lực được thể chế hóa. Có Architecture Skills Framework rõ ràng — phân biệt Solutions Architect và Enterprise Architect (đã bàn ở Bài 3), có lộ trình phát triển, có tiêu chí đánh giá. Tri thức không còn phụ thuộc bất kỳ cá nhân nào, kể cả Chief Architect hiện tại.

Sai lầm phổ biến nhất khi leo lộ trình này là nhảy cóc — cố dựng Skills Framework hoành tráng (Cấp 4) trong khi còn chưa có nổi một ADR log (Cấp 1). Kết quả là tài liệu đẹp nhưng không ai dùng, vì nền tảng ghi chép quyết định hàng ngày chưa tồn tại.

Case thực tế minh hoạ

(Đây là tình huống minh hoạ điển hình tổng hợp từ các mẫu hình thường gặp, không phải case của một doanh nghiệp cụ thể nào.)

Một công ty fintech tầm trung, khoảng 400 nhân sự, có một Chief Architect kỳ cựu — gọi là A — người đã ở đó từ ngày đầu, thiết kế gần như toàn bộ kiến trúc hệ thống thanh toán, luồng dữ liệu tuân thủ, và chiến lược migration lên cloud. A giỏi, được tin tưởng tuyệt đối, và vì vậy không ai đặt câu hỏi "nếu A nghỉ thì sao". Mọi quyết định kiến trúc lớn — từ chọn message broker, thiết kế multi-tenant, đến chiến lược tách monolith — đều đi qua đầu A, phần lớn không văn bản hóa, vì "hỏi A là ra".

Khi A nghỉ việc đột ngột (chuyển sang một cơ hội khác), công ty phát hiện ra một chuỗi hậu quả liên hoàn:

• Không ai biết vì sao hệ thống matching engine được thiết kế đồng bộ thay vì bất đồng bộ — quyết định đó A đưa ra 3 năm trước dựa trên một ràng buộc compliance đã hết hiệu lực từ lâu, nhưng vì không có ADR, đội kỹ thuật hiện tại coi đó là "luật bất di bất dịch" và tiếp tục thiết kế theo hướng đó dù không còn cần thiết — gây nghẽn hiệu năng không đáng có.
• Roadmap tách monolith đứt gãy giữa chừng. A đã lên kế hoạch tách 12 tháng, nhưng chỉ có 2 giai đoạn đầu được viết thành tài liệu; 4 giai đoạn còn lại "nằm trong đầu A". Đội ngũ phải dừng lại 6 tuần chỉ để đoán lại ý đồ ban đầu qua việc phỏng vấn ngược các kỹ sư từng làm việc với A.
• Không có Architecture Board để lấp khoảng trống quyền lực. Vì mọi quyết định trước giờ chỉ một người ký, khi vị trí trống, không có cơ chế nào để ra quyết định tạm thời có tính chính danh. Các team bắt đầu tự quyết theo hướng riêng — một số dịch vụ dùng gRPC, một số quay lại REST, không ai đủ thẩm quyền chặn lại.
• Tuyển Chief Architect mới mất gần một năm không phải vì thiếu ứng viên giỏi, mà vì không có Architecture Skills Framework để định nghĩa rõ vai trò cần gì — mô tả công việc thực chất là "làm mọi thứ A từng làm", một tiêu chí không thể tuyển được.

Điều đáng nói: về mặt kỹ thuật thuần túy, không có gì trong case này là do A làm sai. A là một kiến trúc sư giỏi. Vấn đề là tổ chức chưa bao giờ đầu tư xây capability — chỉ đầu tư vào con người. Khi capability không tồn tại độc lập với cá nhân, mọi rủi ro nhân sự tự động trở thành rủi ro kiến trúc toàn công ty.

📐 Template/Artifact áp dụng ngay

Architecture Capability Readiness Checklist — dùng để tự chấm điểm nhanh mức độ trưởng thành hiện tại và xác định thành phần nào cần đầu tư trước.

Cách dùng: tổ chức nào trả lời "Không" từ 4 câu trở lên nên coi là ở Cấp 0-1 trong lộ trình trưởng thành — ưu tiên tuyệt đối là dựng ADR log (Repository tối thiểu) và Architecture Board tối thiểu (Governance tối thiểu) trước khi đầu tư vào Skills Framework hoành tráng.

🎯 Góc nhìn Chief EA

• Nếu tôi nghỉ việc chiều nay, ai trong tổ chức có thể trả lời "vì sao chúng ta thiết kế hệ thống X như vậy" mà không cần gọi cho tôi?
• Quyết định kiến trúc lớn nhất trong 6 tháng qua — nó được ghi lại ở đâu, hay chỉ tồn tại trong Slack DM và trí nhớ của vài người?
• Tôi đang xây một năng lực tổ chức, hay đang vô tình biến mình thành điểm nghẽn duy nhất mà cả công ty phụ thuộc vào?
• Nếu đội ngũ kiến trúc phải tăng gấp đôi trong 12 tháng tới, quy trình và tiêu chí tuyển hiện tại có đủ rõ ràng để nhân bản năng lực đó, hay mọi thứ vẫn phải "học nghề" trực tiếp từ tôi?

🔗 Bài viết liên quan

• Kiến trúc sư doanh nghiệp (EA) vs. Kỹ sư giải pháp (SA) — nền tảng để xây Architecture Skills Framework phân biệt rõ hai vai trò.
• Kỹ năng lãnh đạo của một Chief EA — năng lực lãnh đạo cá nhân cần có để dẫn dắt quá trình thể chế hóa capability này.

Bài trước: Kỹ năng lãnh đạo của một Chief EA · Bài tiếp theo: Tư duy Hệ thống (Systems Thinking) trong EA