title: "Giai đoạn G (Governance): Quy trình kiểm soát kiến trúc tại chỗ (Architecture Compliance Review)"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 2 — Giải phẫu ADM (Mastering the ADM Cycle)"
order: 20
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• ADM
• Architecture Governance
• Compliance Review
• Architecture Review Board
• Enterprise Architecture

Giai đoạn G (Governance): Quy trình kiểm soát kiến trúc tại chỗ (Architecture Compliance Review)

Sáu tháng sau khi một Architecture Contract được ký (bài 19), Chief EA ngồi lại xem tiến độ dự án migration hệ thống thanh toán. Trên giấy tờ, mọi thứ vẫn "xanh" — đúng tiến độ, đúng ngân sách, PM báo cáo tuần nào cũng suôn sẻ. Nhưng khi lật container registry lên xem, có ba service mới được deploy bằng một message queue mà TRM (Technology Reference Model) chưa từng phê duyệt. Không ai làm sai một cách cố ý — team engineering chỉ đơn giản là cần giải quyết một bài toán độ trễ, tìm được công cụ phù hợp, và tích hợp nó vào sprint mà không nghĩ tới việc "xin phép kiến trúc".

Đây chính là điểm mù chết người của rất nhiều tổ chức: Architecture Contract chỉ là cam kết tại một thời điểm. Governance thực sự không phải là ký hợp đồng rồi ngồi chờ báo cáo cuối kỳ — nó là một vòng lặp kiểm soát liên tục chạy song song với vòng đời phát triển. Nhiều EA hiểu sai giai đoạn G là "họp phê duyệt kiến trúc trước khi build" — đó là nhầm lẫn với Phase F. Giai đoạn G trong ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình của TOGAF) diễn ra SAU KHI dự án đã bắt đầu triển khai, với một câu hỏi hoàn toàn khác: kiến trúc đang được xây có còn đúng như những gì đã cam kết không?

Nếu không có cơ chế này, "kiến trúc trôi dạt" (architecture drift) là điều tất yếu — không phải vì đội ngũ cố tình phá vỡ nguyên tắc, mà vì áp lực deadline luôn thắng thế trước một quy tắc không ai kiểm tra lại.

Bản chất

Giai đoạn G (Implementation Governance) trong ADM có hai vai trò song song: (1) quản trị việc triển khai thực tế đúng theo Architecture Contract đã ký ở Phase F, và (2) vận hành các Architecture Compliance Review — những buổi rà soát định kỳ, có cấu trúc, để xác nhận một dự án đang chạy có tuân thủ Target Architecture đã duyệt hay không.

Điểm khác biệt cốt lõi so với các cổng kiểm soát trước đó trong ADM (như compliance check nội bộ ở Phase B/C/D) là: Compliance Review ở Phase G nhìn vào hệ thống ĐANG ĐƯỢC XÂY, không phải bản thiết kế trên giấy. Nó đối chiếu ba lớp:

1. Cam kết đã ký — nội dung trong Architecture Contract: baseline kiến trúc, các ràng buộc, phạm vi được phê duyệt.
2. Thực tế đang triển khai — code, hạ tầng, cấu hình, quyết định kỹ thuật mà team thực sự đưa ra trong quá trình build.
3. Chuẩn tham chiếu doanh nghiệp — Technology Reference Model, Standards Information Base, các nguyên tắc kiến trúc (Architecture Principles) đã được ban hành.

Compliance Review không phải là công cụ trừng phạt. Nó là cơ chế phát hiện sớm (early detection) — mục tiêu là bắt được độ lệch khi chi phí sửa còn thấp (thường là vài dòng cấu hình hoặc một buổi refactor nhỏ), thay vì phát hiện ở giai đoạn go-live khi chi phí sửa đã leo thang thành một dự án con.

Một hiểu lầm phổ biến khác: Compliance Review không đồng nghĩa với zero-tolerance. Kiến trúc doanh nghiệp tồn tại để phục vụ mục tiêu kinh doanh, không phải để trở thành giáo điều cản trở tốc độ. Vì vậy cơ chế miễn trừ có kiểm soát (waiver) là một phần thiết kế bắt buộc của Phase G, không phải một lỗ hổng.

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

Cấu trúc một buổi Compliance Review điển hình

Một buổi Architecture Compliance Review hiệu quả thường kéo dài 60-90 phút, diễn ra định kỳ (phổ biến: hàng tháng cho dự án lớn, hàng quý cho dự án ổn định) hoặc tại các milestone quan trọng (trước UAT, trước go-live). Cấu trúc gồm 5 bước:

Tiêu chí đánh giá cốt lõi

Một Compliance Review đúng chuẩn không đánh giá cảm tính "trông có ổn không" — nó chạy qua các tiêu chí cụ thể:

• Tuân thủ Baseline/Target Architecture: Kiến trúc đang build có khớp với Target Architecture đã duyệt ở các giai đoạn B/C/D không? (Baseline Architecture là hiện trạng trước dự án, Target Architecture là đích đến đã thiết kế)
• Tuân thủ TRM (Technology Reference Model): Công nghệ, nền tảng, công cụ được dùng có nằm trong danh mục chuẩn đã phê duyệt không?
• Tuân thủ Architecture Principles: Các nguyên tắc kiến trúc nền tảng (ví dụ "data là tài sản chung", "ưu tiên buy trước build", "bảo mật theo mặc định") có bị vi phạm ngầm không?
• Tuân thủ Standards: Chuẩn tích hợp, chuẩn API, chuẩn đặt tên, chuẩn bảo mật dữ liệu.
• Đúng phạm vi (scope) đã cam kết: Dự án có đang "leo thang phạm vi" (scope creep) vượt khỏi những gì Architecture Contract cho phép không?

Phân loại mức độ vi phạm

Cơ chế xin miễn trừ có kiểm soát (Waiver)

Không phải mọi điểm lệch đều cần sửa ngay — đôi khi lý do kinh doanh hợp lý hơn việc tuân thủ tuyệt đối (ví dụ: deadline pháp lý không thể lùi, hoặc công nghệ chuẩn chưa sẵn sàng ở thị trường đó). TOGAF khuyến khích một quy trình waiver có kiểm soát thay vì để dự án "âm thầm lách luật":

1. Team đề xuất waiver bằng văn bản, nêu rõ: lý do lệch, rủi ro nếu chấp nhận, rủi ro nếu không chấp nhận, thời hạn hiệu lực của waiver, điều kiện để đóng waiver (ví dụ: "chấp nhận đến Q4, sau đó bắt buộc migrate về chuẩn").
2. Waiver mức Nhẹ/Trung bình: EA phụ trách domain có thể phê duyệt trực tiếp, ghi vào Compliance Log.
3. Waiver mức Nặng: bắt buộc đưa lên Architecture Review Board (ARB) — hội đồng quản trị kiến trúc cấp cao sẽ được khai triển chi tiết ở bài 31 — để xem xét tập thể, vì mức độ rủi ro vượt quá thẩm quyền cá nhân.
4. Mọi waiver đều có ngày hết hạn và được review lại — waiver không phải là giấy phép vĩnh viễn, nó là một khoản "nợ kiến trúc" (architecture debt, sẽ bàn sâu ở bài 32) được ghi sổ công khai thay vì giấu đ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 pattern governance phổ biến, không phải case của một công ty cụ thể, không phản ánh số liệu thật của bất kỳ tổ chức nào.

Một doanh nghiệp bán lẻ đa kênh đang chạy dự án hiện đại hoá hệ thống quản lý đơn hàng (Order Management System). Architecture Contract đã quy định rõ: mọi giao tiếp bất đồng bộ giữa các service phải qua nền tảng message broker đã được chuẩn hoá trong TRM — lý do là để đảm bảo khả năng giám sát tập trung, replay message khi có sự cố, và tuân thủ chuẩn audit log của ngành.

Tại buổi Compliance Review định kỳ hàng tháng, architect phụ trách domain Order rà soát kiến trúc as-built và phát hiện: team phát triển tính năng "thông báo tồn kho realtime" đã âm thầm tích hợp một message queue nhẹ, dễ triển khai, ngoài danh mục TRM — không phải vì cố tình phá luật, mà vì broker chuẩn của công ty yêu cầu thời gian xin cấp quyền và cấu hình khá lâu, trong khi deadline tính năng chỉ còn hai tuần. Đây rõ ràng là vi phạm mức Nặng: công nghệ ngoài TRM, ảnh hưởng tới khả năng giám sát tập trung và audit log toàn hệ thống.

Điểm mấu chốt là thời điểm phát hiện: tính năng mới build được ba tuần, chưa go-live, dữ liệu chưa production. Nếu phát hiện muộn hơn — ví dụ sau khi đã go-live sáu tháng và có hàng triệu message đã đi qua hệ thống ngoài chuẩn — chi phí khắc phục sẽ bao gồm cả migration dữ liệu, downtime, và rủi ro mất audit trail cho giai đoạn đã qua.

Quy trình xử lý: điểm lệch được đưa thẳng lên ARB trong tuần đó (do là vi phạm Nặng). ARB đánh giá lý do đội ngũ đưa ra là hợp lý về mặt vận hành ngắn hạn, nhưng không chấp nhận duy trì vĩnh viễn. Kết quả: cấp một waiver có thời hạn 6 tuần để đội ngũ hoàn tất tích hợp broker chuẩn song song, kèm điều kiện bắt buộc — tính năng chỉ được go-live sau khi đã chuyển hẳn sang broker chuẩn. Chi phí phát sinh: khoảng một sprint để re-platform, so với việc phải làm lại toàn bộ migration dữ liệu nếu phát hiện sau go-live.

Bài học rút ra không nằm ở việc "bắt lỗi ai" mà ở việc quy trình Compliance Review định kỳ đã tạo ra một điểm chặn tự nhiên — không phụ thuộc vào việc đội ngũ có chủ động báo cáo hay không.

📐 Template/Artifact áp dụng ngay

Architecture Compliance Assessment Sheet — dùng trong mỗi buổi Compliance Review, gắn với một dự án/work package cụ thể:

Bảng đối chiếu tiêu chí:

Bảng theo dõi Waiver đang hiệu lực:

Kết luận buổi review: ☐ Tuân thủ đầy đủ ☐ Tuân thủ có điều kiện (waiver đính kèm) ☐ Không tuân thủ — yêu cầu escalate ARB

🎯 Góc nhìn Chief EA

• Nếu tôi không tổ chức Compliance Review, ai đang thực sự kiểm tra việc dự án còn bám sát kiến trúc đã duyệt — hay tất cả chỉ dựa vào lòng tin?
• Waiver đang mở của tổ chức tôi có bao nhiêu cái, và bao nhiêu cái đã quá hạn mà chưa ai đóng lại?
• Khi phát hiện một điểm lệch Nặng, tôi có đang tạo ra một quy trình escalate rõ ràng, hay để nó chìm trong email cá nhân?
• Tần suất Compliance Review của tôi có đang tương xứng với tốc độ thay đổi của các dự án đang chạy, hay đang review sau khi mọi chuyện đã an bài?

🔄 Vị trí trong chu trình ADM

Giai đoạn G nhận đầu vào từ Architecture Contract (Giai đoạn F, bài 19) — chính bản cam kết đã ký ở Phase F là "thước đo chuẩn" mà mọi Compliance Review dùng để đối chiếu với thực tế triển khai.

Giai đoạn G cho đầu ra sang Giai đoạn H (Change Management) (bài 21) — mọi phát hiện không tuân thủ, mọi thay đổi kiến trúc cần thiết được nhận diện qua Compliance Review (dù là do drift ngoài ý muốn hay do nhu cầu kinh doanh mới phát sinh) đều trở thành đầu vào chính thức cho quy trình quản trị thay đổi ở giai đoạn tiếp theo.

🔗 Bài viết liên quan

• Giai đoạn F (Implementation Governance) — nơi Architecture Contract được thiết lập, là nền tảng cho mọi Compliance Review ở Phase G.
• Giai đoạn H (Change Management) — nơi các phát hiện không tuân thủ từ Compliance Review được chuyển hoá thành quyết định thay đổi có kiểm soát.

Bài trước: Giai đoạn F (Implementation Governance) · Bài tiếp theo: Giai đoạn H (Change Management)