title: "Giai đoạn F (Implementation Governance): Kết nối giữa bản thiết kế và thực thi"
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: 19
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "14 phút"
tags:

• TOGAF
• ADM
• Implementation Governance
• Giai đoạn F
• Architecture Contract
• Compliance Assessment

Giai đoạn F (Implementation Governance): Kết nối giữa bản thiết kế và thực thi

Một Chief EA tôi từng làm việc cùng có một câu nói mà anh lặp lại trong mọi buổi kickoff dự án lớn: "Bản thiết kế đẹp nhất thế giới cũng vô giá trị nếu không ai bị ràng buộc phải làm theo nó." Câu này nghe hiển nhiên, nhưng phần lớn tổ chức vận hành EA lại hành xử như thể nó không đúng. Họ đổ toàn bộ năng lượng vào Giai đoạn B, C, D — vẽ Target Architecture công phu, review kỹ lưỡng, trình bày đẹp trong buổi phê duyệt — rồi coi như xong việc. Đội triển khai nhận tài liệu, cảm ơn, và... làm theo cách của họ.

Sáu tháng sau, hệ thống go-live. Kiến trúc sư mở lại bản thiết kế đã duyệt để đối chiếu, và phát hiện ra: tầng tích hợp không dùng event-driven như thiết kế mà dùng point-to-point API gọi trực tiếp giữa các service; lớp dữ liệu không tuân theo mô hình chuẩn hoá đã thống nhất mà mỗi team tự ý denormalize theo nhu cầu riêng; và một microservice quan trọng bị gộp thẳng vào monolith cũ vì "cho nhanh, deadline gấp". Không ai cố tình phá hoại kiến trúc — mỗi quyết định lệch hướng đều có lý do hợp lý tại thời điểm nó được đưa ra, dưới áp lực deadline, thiếu người review, hoặc đơn giản là không ai hỏi lại kiến trúc sư. Nhưng cộng dồn lại, hệ thống đi vào production trông hoàn toàn khác với những gì ban lãnh đạo đã phê duyệt ngân sách để xây.

Đây chính là khoảng trống mà Giai đoạn F — Implementation Governance — được thiết kế để lấp đầy. Nó không phải là một bước thủ tục hình thức giữa "thiết kế xong" và "triển khai xong". Nó là cơ chế ràng buộc pháp lý-nghiệp vụ, chuyển kiến trúc từ một tài liệu tham khảo thành một cam kết có trách nhiệm giải trình rõ ràng — và là nơi phần lớn giá trị thực tế của công tác EA bị đánh mất nếu làm hời hợt.

Bản chất

Trong chu trình ADM, Giai đoạn F đứng ngay sau Giai đoạn E (Migration Planning — lập kế hoạch di chuyển, đã xác định lộ trình chuyển đổi cụ thể) và trước khi các dự án triển khai thực sự chạy. Mục tiêu duy nhất của Giai đoạn F: thiết lập cơ chế quản trị (governance) để đảm bảo các dự án triển khai tuân thủ kiến trúc mục tiêu đã được phê duyệt — không phải bằng thiện chí, mà bằng một công cụ ràng buộc chính thức gọi là Architecture Contract.

Ba hiểu lầm phổ biến khiến Giai đoạn F bị làm cho có:

Hiểu lầm 1 — Governance nghĩa là kiểm tra một lần lúc khởi động dự án. Nhiều tổ chức coi "Implementation Governance" đơn giản là một buổi review kiến trúc trước khi dự án bắt đầu code, giống như một cổng chấp thuận (gate) một chiều. Sau buổi đó, kiến trúc sư biến mất khỏi vòng lặp cho đến khi hệ thống go-live. Đây là sai lầm cốt lõi: TOGAF định nghĩa Giai đoạn F là một hoạt động xuyên suốt vòng đời dự án, không phải một checkpoint đơn lẻ. Kiến trúc drift (lệch dần khỏi thiết kế) xảy ra từ từ, qua hàng chục quyết định nhỏ trong sprint planning, code review, và các buổi họp kỹ thuật hàng tuần — không phải trong một sự kiện lớn duy nhất. Một cơ chế chỉ kiểm tra một lần sẽ bỏ lỡ gần như toàn bộ các điểm lệch hướng thực tế.

Hiểu lầm 2 — Architecture Contract chỉ là văn bản hình thức, không có hiệu lực thực thi. Nhiều đội architecture soạn ra một tài liệu gọi là "contract" nhưng thực chất chỉ là bản tóm tắt thiết kế, không có điều khoản trách nhiệm, không có cơ chế theo dõi tuân thủ, không có hệ quả khi vi phạm. Khi đó nó chỉ là một tài liệu thông tin, không phải một hợp đồng theo đúng nghĩa TOGAF định nghĩa. Một Architecture Contract thật sự phải có bên ràng buộc rõ ràng, tiêu chí đo lường tuân thủ cụ thể, và cơ chế escalation khi có sai lệch.

Hiểu lầm 3 — Compliance là việc của kiến trúc sư, không phải của đội triển khai. Cách tiếp cận "cảnh sát kiến trúc" — nơi EA đóng vai trò thanh tra đi soi lỗi đội dev — tạo ra quan hệ đối đầu và khiến đội triển khai tìm cách giấu sai lệch thay vì báo cáo sớm. Governance hiệu quả biến compliance thành trách nhiệm chung, được thoả thuận từ đầu qua chính Architecture Contract, chứ không phải một cuộc thanh tra áp đặt từ trên xuống.

Cốt lõi cần nhớ: Giai đoạn F không tồn tại để "bắt lỗi" đội triển khai — nó tồn tại để đảm bảo có một điểm neo chung, được cả hai bên đồng thuận từ đầu, để bất kỳ sai lệch nào cũng được phát hiện và xử lý khi chi phí sửa còn thấp, chứ không phải khi hệ thống đã go-live.

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

Architecture Contract — trục xương sống của Giai đoạn F

Architecture Contract, theo TOGAF, là thoả thuận chính thức giữa bên phát triển kiến trúc (Architecture Development team) và bên chịu trách nhiệm triển khai (Business/IT delivery team), xác nhận rằng dự án cam kết tuân thủ kiến trúc mục tiêu trong phạm vi đã thống nhất. Nó không phải một khái niệm trừu tượng — nó có cấu trúc nội dung cụ thể:

Điểm khác biệt cốt lõi giữa Architecture Contract và một tài liệu thiết kế thông thường: contract có bên ký cam kết và hệ quả khi vi phạm. Đây là lý do TOGAF dùng từ "Contract" chứ không phải "Guideline" hay "Recommendation".

Cơ chế theo dõi tuân thủ liên tục — không chỉ kiểm tra một lần

Đây là phần thường bị bỏ qua nhất trong thực hành, nên cần một khung vận hành cụ thể:

1. Compliance Assessment định kỳ — không phải một lần lúc kickoff, mà lặp lại theo nhịp của dự án (thường gắn với các milestone: kết thúc mỗi sprint lớn, trước mỗi lần deploy staging, trước go-live). Mỗi lần assessment trả lời ba câu hỏi: Kiến trúc hiện tại của dự án có khớp với Architecture Contract không? Nếu có sai lệch, mức độ nghiêm trọng ra sao? Sai lệch đó có lý do chính đáng (cần xin exception chính thức) hay là drift không kiểm soát?

2. Dispensation (miễn trừ có kiểm soát) — TOGAF thừa nhận thực tế: không phải lúc nào dự án cũng có thể tuân thủ 100% kiến trúc đã duyệt, vì ràng buộc thời gian, ngân sách, hoặc phát hiện kỹ thuật mới trong quá trình làm. Thay vì để đội triển khai âm thầm lệch hướng, cơ chế Dispensation cho phép xin miễn trừ chính thức, có ghi nhận, có thời hạn, và có người phê duyệt (thường là Architecture Review Board). Đây là van an toàn hợp pháp — khác hoàn toàn với drift không kiểm soát.

3. Compliance Assessment không chỉ là checklist kỹ thuật. Nó cần gắn với business impact: một sai lệch nhỏ về công nghệ (đổi thư viện logging) không cần escalation, nhưng một sai lệch về ranh giới dữ liệu (hai hệ thống đáng lẽ tách biệt nay chia sẻ trực tiếp database) có thể phá vỡ toàn bộ nguyên tắc data governance của tổ chức — cần escalation ngay lập tức.

4. Đường dây báo cáo hai chiều. Đội triển khai phải có kênh chủ động báo cáo sai lệch (thay vì chỉ bị kiểm tra từ trên xuống), và kiến trúc sư phải phản hồi trong thời gian xác định (SLA nội bộ, ví dụ 3-5 ngày làm việc) — nếu không, chính cơ chế governance trở thành nút thắt cổ chai làm chậm dự án, khiến đội triển khai có động lực lách qua nó.

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, không có số liệu thực tế đi kèm.)

Một công ty dịch vụ tài chính triển khai dự án hiện đại hoá hệ thống quản lý khách hàng (CRM), đi qua đầy đủ Giai đoạn A đến E: Architecture Vision được phê duyệt, Target Architecture xác định rõ ràng service quản lý khách hàng phải tách biệt hoàn toàn khỏi service xử lý giao dịch, giao tiếp giữa hai bên chỉ qua một tầng event bus có kiểm soát — nhằm đảm bảo tách biệt trách nhiệm và cho phép mở rộng độc lập từng phần trong tương lai.

Kiến trúc được duyệt, đội triển khai — một nhóm dev thuê ngoài dưới áp lực deadline sáu tháng — bắt tay vào code. Nhưng không có Architecture Contract chính thức nào được ký kết. Kiến trúc sư bàn giao một bộ tài liệu thiết kế dày, tổ chức một buổi trình bày kiến trúc duy nhất lúc kickoff, rồi chuyển sang phụ trách dự án khác. Không có lịch review định kỳ, không có tiêu chí đo lường tuân thủ cụ thể, không có ai chịu trách nhiệm giải trình khi có sai lệch.

Ba tháng vào dự án, để tiết kiệm thời gian phát triển, đội dev quyết định cho service quản lý khách hàng gọi trực tiếp API nội bộ của service giao dịch — bỏ qua event bus vì "đồng bộ dễ debug hơn, event bus phức tạp không cần thiết ở giai đoạn này". Quyết định này hợp lý trong bối cảnh cục bộ của họ, nhưng phá vỡ chính nguyên tắc tách biệt trách nhiệm mà toàn bộ Target Architecture được xây dựng để bảo vệ.

Không ai phát hiện, vì không có cơ chế nào kiểm tra. Hệ thống go-live đúng deadline, được xem là thành công ban đầu. Sáu tháng sau, công ty muốn mở rộng service giao dịch sang một dòng sản phẩm mới với yêu cầu khắt khe hơn về khả năng chịu tải và tuân thủ quy định tài chính. Đội kỹ thuật phát hiện: vì hai service gọi trực tiếp lẫn nhau, không thể scale hay deploy độc lập — mọi thay đổi ở service giao dịch đều có nguy cơ làm sập service khách hàng do coupling chặt. Việc tách lại hai service này đòi hỏi một dự án tái cấu trúc riêng, tốn thời gian và chi phí tương đương gần một nửa dự án gốc.

Nguyên nhân gốc rễ không phải do đội dev thiếu năng lực, mà do thiếu Architecture Contract ràng buộc, thiếu cơ chế theo dõi tuân thủ liên tục, và thiếu kênh báo cáo sai lệch chính thức. Nếu có compliance assessment định kỳ ở tháng thứ ba, sai lệch này đã được phát hiện khi chi phí sửa chỉ là vài ngày refactor, thay vì một dự án tái cấu trúc toàn diện sau khi hệ thống đã go-live và có dữ liệu thật vận hành trên đó.

📐 Template/Artifact áp dụng ngay

Architecture Contract — Compliance Tracker (dùng cho từng dự án triển khai, cập nhật theo mỗi lần Compliance Assessment)

Bảng theo dõi từng lần Compliance Assessment:

Quy tắc phân loại mức nghiêm trọng gợi ý:

• Thấp — sai lệch về công nghệ/công cụ cụ thể, không ảnh hưởng nguyên tắc kiến trúc cốt lõi. Ghi nhận, không cần escalation.
• Trung bình — sai lệch ảnh hưởng một phần nguyên tắc (ví dụ: performance, khả năng bảo trì). Cần Dispensation chính thức, phê duyệt bởi Architecture Owner.
• Cao — sai lệch phá vỡ nguyên tắc nền tảng (tách biệt trách nhiệm, bảo mật dữ liệu, khả năng mở rộng chiến lược). Bắt buộc escalation lên Architecture Review Board, không được tự ý Dispensation ở cấp dự án.

🎯 Góc nhìn Chief EA

Dự án triển khai kiến trúc gần đây nhất của tổ chức bạn có Architecture Contract chính thức được ký kết, hay chỉ có một bộ tài liệu thiết kế được "bàn giao rồi thôi"? Ai là người chịu trách nhiệm giải trình cụ thể nếu kiến trúc bị lệch hướng giữa chừng — có tên, có vai trò rõ ràng, hay chỉ là "team sẽ tự tuân thủ"? Lần cuối cùng bạn kiểm tra compliance của một dự án đang chạy là khi nào — trước khi go-live hay chỉ lúc kickoff? Nếu phát hiện một sai lệch nghiêm trọng ngay bây giờ, tổ chức có một quy trình Dispensation rõ ràng để xử lý nó minh bạch, hay mọi thứ sẽ được xử lý ngầm qua các cuộc trò chuyện không văn bản hóa?

🔄 Vị trí trong chu trình ADM

Giai đoạn F không đứng độc lập — nó là mắt xích chuyển giao then chốt giữa "lập kế hoạch" và "quản trị vận hành liên tục" trong chu trình ADM tuần hoàn:

• Nhận đầu vào từ: Roadmap chuyển đổi (Giai đoạn E, bài 18) — kế hoạch di chuyển cụ thể, các work package và trình tự triển khai đã được xác lập ở Giai đoạn E chính là cơ sở để soạn Architecture Contract cho từng dự án: phạm vi nào áp dụng, mốc thời gian nào cần compliance assessment, dự án nào rủi ro cao cần giám sát chặt hơn.
• Cho đầu ra sang: Giai đoạn G (Governance, bài 20) — cơ chế quản trị thực thi (Architecture Contract, lịch Compliance Assessment, quy trình Dispensation) được thiết lập ở Giai đoạn F, nhưng được vận hành liên tục, xuyên suốt vòng đời sản phẩm ở Giai đoạn G. Nói cách khác, Giai đoạn F trả lời "chúng ta ràng buộc dự án này như thế nào", còn Giai đoạn G trả lời "chúng ta duy trì sự ràng buộc đó ra sao trong suốt thời gian hệ thống còn sống, kể cả sau khi dự án đã đóng".

Nếu Giai đoạn E là bản đồ đường đi, Giai đoạn F chính là hợp đồng buộc người lái xe phải đi đúng bản đồ đó — và Giai đoạn G là trạm kiểm soát dọc đường, hoạt động liên tục chứ không chỉ một lần lúc xuất phát.

🔗 Bài viết liên quan

• Giai đoạn E (Migration Planning) — nơi lộ trình triển khai được lập, làm nền tảng để soạn Architecture Contract ở Giai đoạn F.
• Giai đoạn G (Governance) — nơi cơ chế quản trị được thiết lập ở Giai đoạn F chuyển sang vận hành liên tục trong suốt vòng đời hệ thống.

Bài trước: Giai đoạn E (Migration Planning) · Bài tiếp theo: Giai đoạn G (Governance)