title: "Agile Architecture: Làm sao để "Agile hóa" các quy trình cồng kềnh của TOGAF?"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 4 — Vận hành kiến trúc cấp chuyên gia (Expert Ops)"
order: 34
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• Agile Architecture
• Architecture Runway
• ADM
• Enterprise Architecture
• Scaled Agile

Agile Architecture: Làm sao để "Agile hóa" các quy trình cồng kềnh của TOGAF?

Có một câu nói tôi nghe lặp lại ở gần như mọi tổ chức đang chuyển đổi Agile: "EA là nơi ý tưởng đi vào để chết." Một Product Owner cần một quyết định kiến trúc để unblock sprint hiện tại, nhưng câu trả lời chính thức là "đưa vào agenda ARB tháng sau." Sprint kết thúc, đội làm liều theo cách riêng, và ba tháng sau kiến trúc sư mới phát hiện ra một microservice mới đã được dựng lên ngoài mọi chuẩn, không ai review, không ai biết nó gọi API nào của hệ thống lõi.

Phản ứng phổ biến của tổ chức trước tình huống này là kết luận TOGAF không hợp với Agile — và âm thầm bỏ luôn Architecture Capability, để các đội tự bơi. Đó là phản ứng sai. Vấn đề không nằm ở TOGAF, mà nằm ở cách người ta triển khai TOGAF: đối xử với ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình các giai đoạn A-H) như một waterfall gate, nơi mọi thay đổi dù nhỏ đều phải đi qua đủ 8 giai đoạn và một hội đồng phê duyệt tập trung.

Bài này không bàn chuyện "TOGAF hay Agile, chọn một." Bàn chuyện làm sao để một Chief EA vận hành EA ở đúng nhịp độ của nó — chậm, có chủ đích, nhìn xa — trong khi vẫn để hàng chục đội Scrum chạy sprint hai tuần một mà không cần dừng lại xin phép giữa chừng. Đó là bài toán về tần suất ra quyết định, không phải bài toán về việc giữ hay bỏ khung.

Bản chất

Điểm mấu chốt cần tách bạch: TOGAF và Agile không vận hành ở cùng một tầng thời gian, và đó không phải là khiếm khuyết — đó là thiết kế đúng đắn nếu ta hiểu rõ vai trò của từng tầng.

ADM vốn dĩ không phải một quy trình chạy một lần rồi dừng. Bản thân TOGAF mô tả ADM là một chu trình lặp (iterative cycle) — bạn có thể chạy nhiều vòng lặp lồng nhau ở các phạm vi khác nhau: một vòng lặp lớn cho toàn doanh nghiệp (enterprise-wide, chu kỳ năm/quý), và các vòng lặp nhỏ hơn cho từng segment, capability, hay solution (chu kỳ ngắn hơn nhiều). Sai lầm phổ biến là chỉ chạy một vòng ADM khổng lồ cho mọi thứ, khiến bất kỳ thay đổi nhỏ nào cũng phải đi qua toàn bộ 8 giai đoạn.

Vấn đề thực sự là hạt (granularity) quyết định, không phải bản thân quy trình. Có hai loại quyết định kiến trúc hoàn toàn khác bản chất:

1. Quyết định kiến trúc nền tảng (foundational) — chọn cloud provider, chọn kiến trúc dữ liệu tập trung hay phân tán, chọn chuẩn tích hợp, chọn nguyên tắc bảo mật. Những quyết định này có chi phí thay đổi cực cao, ảnh hưởng nhiều năm, cần Gap Analysis kỹ, cần sự đồng thuận của nhiều bên liên quan. Đây là việc của ADM chu kỳ dài.

2. Quyết định thiết kế cục bộ (local design) — chọn thư viện nào cho một service cụ thể, đặt tên field trong một API nội bộ, cấu trúc một bảng dữ liệu con. Những quyết định này rẻ để thay đổi, tác động cục bộ, và nếu để chờ ARB họp hàng tháng thì chi phí cơ hội (đội ngồi chờ) còn lớn hơn rủi ro kiến trúc.

Việc "Agile hóa" TOGAF, do đó, không phải là làm ADM nhanh hơn cho mọi loại quyết định. Nó là việc phân loại quyết định theo đúng tầng, đưa quyết định loại 1 vào nhịp độ chậm có chủ đích của EA, và trao quyền quyết định loại 2 hoàn toàn cho các đội Agile — miễn là họ di chuyển trong "lan can" (guardrail) mà EA đã dựng sẵn từ trước.

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

Architecture Runway — đường băng kiến trúc

Khái niệm Architecture Runway (phổ biến trong các mô hình scaled agile, được TOGAF practitioner áp dụng rộng rãi khi tích hợp với tổ chức Agile) mô tả chính xác cơ chế cần thiết: EA chuẩn bị trước các nền tảng kỹ thuật, quyết định kiến trúc lớn, và các thành phần dùng chung — để khi một đội Agile cần "cất cánh" triển khai một tính năng mới, họ có sẵn đường băng đủ dài để chạy đà, thay vì phải dừng lại giữa chừng chờ một quyết định kiến trúc chưa tồn tại.

Ẩn dụ máy bay ở đây rất chính xác: một đường băng ngắn buộc máy bay phải dừng đột ngột hoặc không thể cất cánh — tương đương một đội Scrum bị chặn giữa sprint vì thiếu quyết định kiến trúc. Một đường băng được xây trước, đủ dài, đúng hướng — cho phép nhiều "chuyến bay" (feature, sprint) cất cánh liên tục mà không cần xây lại đường băng mỗi lần.

Runway gồm ba lớp:

Đội Scrum chỉ cần "xin phép" khi họ muốn bước ra khỏi runway — ví dụ chọn một database engine mới ngoài danh mục đã duyệt, hoặc mở một kết nối tích hợp chưa có trong chuẩn. Trong phạm vi runway, họ tự quyết 100%.

Lightweight ADM — rút gọn Artifact xuống mức tối thiểu cần thiết

Nguyên tắc thứ hai là không chạy đủ bộ Artifact TOGAF cho mọi vòng lặp. TOGAF cung cấp một thư viện Artifact rất đầy đủ (catalog, matrix, diagram cho từng giai đoạn), nhưng không có yêu cầu bắt buộc phải dùng hết. Với tổ chức Agile, nguyên tắc rút gọn nên theo tỷ lệ nghịch với hạt quyết định:

• Vòng ADM chu kỳ dài (foundational, quý/năm): dùng đầy đủ Artifact quan trọng — Architecture Vision, Business Capability Map, Application Portfolio Catalog, Technology Standards Catalog, Gap Analysis. Đây là nơi đầu tư thời gian tài liệu hóa xứng đáng vì tuổi thọ quyết định dài.

• Vòng ADM chu kỳ vừa (shared enablers, theo Program Increment hoặc theo tháng): rút gọn còn 2-3 Artifact cốt lõi — thường là một Solution Building Block diagram và một bảng Architecture Decision Record (ADR) ngắn gọn ghi lại quyết định + lý do + hệ quả, thay vì đầy đủ Architecture Definition Document.

• Vòng cục bộ (sprint, do team tự quyết): không cần Artifact TOGAF chính thức nào — chỉ cần tuân thủ checklist runway (xem template bên dưới) và ghi chú ngắn trong hệ thống quản lý code/ticket.

Cơ chế quan trọng nhất giữ cho lightweight ADM không trôi khỏi kiểm soát là ADR (Architecture Decision Record) — một tài liệu ngắn (thường 1 trang, dạng Markdown lưu cùng repo code) ghi: bối cảnh, các lựa chọn đã cân nhắc, quyết định, và hệ quả. ADR không thay thế Architecture Definition Document đầy đủ của TOGAF, nhưng đóng vai trò "biên bản nhẹ" cho các quyết định tầng shared-enabler, giúp EA sau này lấy thông tin để cập nhật catalog chính thức mà không cần họp trực tiếp mỗi lần.

ARB không họp theo lịch cố định, mà theo ngưỡng rủi ro (risk-tiered governance)

Thay vì một ARB họp hàng tháng xét duyệt mọi thứ, mô hình Agile-friendly phân loại governance theo mức rủi ro:

• Tier 1 — Rủi ro cao (ảnh hưởng nhiều domain, chi phí đảo ngược lớn, liên quan bảo mật/compliance): bắt buộc qua ARB, review đầy đủ.
• Tier 2 — Rủi ro vừa (ảnh hưởng một domain, có thể đảo ngược trong 1-2 sprint): review nhẹ qua kênh async (Slack/ADR review 48h) bởi 1 kiến trúc sư phụ trách domain, không cần họp toàn ARB.
• Tier 3 — Rủi ro thấp (nằm trong runway đã duyệt): không cần review, chỉ log lại.

Đây chính là cơ chế giải quyết trực tiếp nỗi đau "chờ ARB họp hàng tháng" — vì phần lớn quyết định hàng ngày của đội Scrum rơi vào Tier 3, tức là không chạm ARB.

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 công ty cụ thể có thật, số liệu không mang tính chính xác tuyệt đối.)

Một công ty fintech tầm trung chuyển đổi sang mô hình Agile với khoảng 10 đội Scrum song song. Trước đó, mọi thay đổi kiến trúc — kể cả việc thêm một field mới vào API nội bộ — đều phải đưa vào agenda ARB họp mỗi tháng một lần. Kết quả: các đội học cách "lách" bằng cách không báo cáo thay đổi nhỏ, dẫn tới hai microservice trùng chức năng được dựng độc lập bởi hai đội khác nhau chỉ trong một quý, vì không ai biết đội kia đang làm gì.

Chief EA của tổ chức không giải tán ARB, cũng không bỏ ADM. Ông tổ chức lại theo ba bước:

1. Chạy một vòng ADM chu kỳ dài (quý) để xác lập runway nền tảng: Technology Reference Model (danh mục công nghệ được duyệt sẵn — ngôn ngữ, database, message broker), chuẩn API (REST + OpenAPI, quy ước versioning), và nguyên tắc bảo mật bắt buộc (auth flow chuẩn, chuẩn mã hóa dữ liệu). Đây là kết quả của Giai đoạn B-D truyền thống, làm kỹ, có Gap Analysis đầy đủ.

2. Thiết lập lớp shared enablers do một "Platform Architecture" squad nhỏ (2-3 kiến trúc sư) phụ trách: một API Gateway dùng chung, một bộ SDK nội bộ chuẩn hóa cách gọi service khác, một sandbox environment để đội nào cũng thử nghiệm mà không đụng production. Runway này được cập nhật theo nhịp Program Increment (khoảng 8-10 tuần).

3. Phân loại governance theo Tier. ARB chỉ còn họp khi có đề xuất Tier 1 (ví dụ: đổi database engine chính, mở kết nối với đối tác thanh toán mới) — trung bình 1-2 lần/quý thay vì đều đặn hàng tháng cho mọi thứ. Các thay đổi Tier 2 được duyệt qua kênh async trong 48 giờ bởi kiến trúc sư phụ trách domain liên quan. Các đội Scrum được cấp một checklist runway rõ ràng: miễn nằm trong danh mục công nghệ đã duyệt và tuân thủ chuẩn API/bảo mật, họ tự quyết hoàn toàn, không cần xin phép ai.

Kết quả sau hai quý: số lần đội bị block giữa sprint vì chờ quyết định kiến trúc giảm mạnh, đồng thời số vụ trùng lặp/xung đột kiến trúc phát hiện muộn cũng giảm — vì phần lớn quyết định giờ được ghi lại qua ADR ngay tại thời điểm ra quyết định thay vì bị giấu đi để né ARB. Mối quan hệ giữa EA và các đội Agile chuyển từ "người gác cổng" sang "người xây đường băng."

📐 Template/Artifact áp dụng ngay

Architecture Runway Checklist — dùng để đội Scrum tự đánh giá một quyết định kỹ thuật có nằm trong runway hay cần leo thang lên EA.

Cách dùng: đội tự chạy checklist này ngay trong sprint planning hoặc khi phát sinh quyết định kỹ thuật giữa sprint. Nếu tất cả câu trả lời dẫn tới Tier 3, đội tự quyết và chỉ cần lưu ADR vào thư mục docs/adr/ trong repo — không cần chờ ai duyệt. Tier 2 gửi ADR nháp cho kiến trúc sư domain qua kênh async, có phản hồi trong SLA 48 giờ. Tier 1 mới cần đưa vào agenda ARB.

🎯 Góc nhìn Chief EA

Nếu ARB của bạn phải họp để duyệt một quyết định mà chi phí đảo ngược nó thấp hơn chi phí chờ họp — bạn đang quản trị sai cấp độ.

Runway của tổ chức bạn có thực sự tồn tại dưới dạng tài liệu/catalog cụ thể, hay chỉ tồn tại trong đầu vài kiến trúc sư kỳ cựu mà các đội mới phải đoán?

Bao nhiêu phần trăm quyết định kiến trúc trong quý vừa rồi được ghi lại bằng ADR tại thời điểm ra quyết định, so với bao nhiêu phần trăm chỉ được phát hiện sau khi đã triển khai xong?

Nếu giải tán ARB ngay ngày mai, tổ chức của bạn có sụp đổ về mặt kiến trúc, hay chỉ đơn giản là các đội tiếp tục chạy đúng như runway đã vạch sẵn?

🔗 Bài viết liên quan

• Cloud-Native EA
• Architecture Review Board (ARB)

Bài trước: Cloud-Native EA · Bài tiếp theo: DevOps & Architecture