title: "ADM Guidelines & Techniques: Những kỹ thuật "phụ" không có trong quy trình chính nhưng vô cùng quan trọng"
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: 22
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "14 phút"
tags:

• TOGAF
• Enterprise Architecture
• ADM Guidelines and Techniques
• Requirements Management
• Gap Analysis
• Business Scenarios
• Risk Management

ADM Guidelines & Techniques: Những kỹ thuật "phụ" không có trong quy trình chính nhưng vô cùng quan trọng

Có một câu hỏi tưởng như ngây thơ nhưng lại là bài test hiệu quả nhất để phân biệt một người mới học TOGAF với một Chief EA đã va vấp đủ nhiều: "Requirements Management nằm ở giai đoạn nào trong 8 giai đoạn A-H của ADM?" Phần lớn người mới sẽ lục lại sơ đồ vòng tròn ADM quen thuộc, cố tìm một ô chữ nhật ghi "Requirements" xen giữa Giai đoạn A và B, rồi bối rối khi không thấy. Câu trả lời đúng — và cũng là cái bẫy tư duy nguy hiểm nhất trong toàn bộ TOGAF — là: Requirements Management không nằm ở giai đoạn nào cả, vì TOGAF vẽ nó ở ngay tâm của vòng tròn ADM, không phải trên đường viền.

Sự khác biệt này không phải là chi tiết trình bày cho đẹp sơ đồ. Nó phản ánh một triết lý cốt lõi: yêu cầu (requirements) trong một dự án kiến trúc doanh nghiệp không bao giờ đứng yên. Chúng phát sinh ở Giai đoạn A khi phác thảo Vision, được đào sâu ở Giai đoạn B khi mô hình hoá Business Architecture, bị thách thức ở Giai đoạn C khi va vào giới hạn thực tế của hệ thống dữ liệu và ứng dụng, bị bẻ cong tiếp ở Giai đoạn D bởi giới hạn công nghệ, rồi tiếp tục biến động suốt Giai đoạn E, F khi lập kế hoạch di trú, và thậm chí còn đổi hướng ở Giai đoạn G, H khi governance phát hiện độ lệch giữa triển khai thực tế và kiến trúc mục tiêu. Một tổ chức coi Requirements Management là "một buổi workshop thu thập yêu cầu làm ở đầu dự án rồi đóng file lại" đang tự đặt bẫy cho chính mình — và đây chính là nguyên nhân gốc rễ của phần lớn các dự án ADM thất bại không phải vì kiến trúc sai, mà vì kiến trúc đúng với một tập yêu cầu đã lỗi thời.

Ngoài Requirements Management, TOGAF còn đóng gói một nhóm kỹ thuật khác dưới cùng một cái ô gọi là "ADM Guidelines & Techniques" — không phải giai đoạn, không phải artifact, mà là những công cụ tư duy và quy trình hỗ trợ được áp dụng xuyên suốt nhiều giai đoạn cùng lúc. Bài này khép lại Phần 2 của series bằng việc đưa những kỹ thuật "phụ" này ra ánh sáng — vì kinh nghiệm thực chiến cho thấy chính những thứ không nằm trên vòng tròn chính lại thường quyết định một chương trình ADM sống hay chết.

Bản chất

TOGAF cấu trúc tài liệu của mình thành nhiều phần, trong đó ADM (Architecture Development Method) là phần lõi mô tả 8 giai đoạn tuần hoàn A-H cộng với Preliminary Phase. Nhưng đi kèm với ADM là một tập tài liệu riêng gọi là ADM Guidelines & Techniques — tuyển tập các hướng dẫn thích ứng (adaptation guidelines) và kỹ thuật hỗ trợ (supporting techniques) không gắn cố định vào một giai đoạn nào, mà được rút ra để dùng lặp lại ở nhiều giai đoạn khác nhau tuỳ theo bối cảnh dự án.

Có hai nhóm con cần phân biệt rõ:

Nhóm Guidelines (hướng dẫn thích ứng) trả lời câu hỏi "làm sao điều chỉnh ADM cho phù hợp với bối cảnh cụ thể" — ví dụ áp dụng ADM cho dự án an ninh mạng, cho tổ chức đang chuyển đổi số, cho mô hình vận hành phân tán nhiều đơn vị kinh doanh (federated). Đây là các hướng dẫn mang tính bối cảnh hoá, không phải kỹ thuật thao tác cụ thể.

Nhóm Techniques (kỹ thuật hỗ trợ) là các công cụ thao tác cụ thể, dùng để thực hiện một nhiệm vụ xuyên suốt nhiều giai đoạn. Ba kỹ thuật quan trọng nhất, mà một EA cấp cao bắt buộc phải thành thạo:

1. Requirements Management — quy trình quản lý vòng đời yêu cầu, đặt ở TÂM vòng tròn ADM (không phải trên đường viền A-H), vì nó không phải một hoạt động làm-rồi-xong mà là một dòng chảy liên tục nhận đầu vào từ MỌI giai đoạn và cung cấp yêu cầu cho MỌI giai đoạn.
2. Business Scenarios — kỹ thuật làm rõ và kiểm chứng Business Requirements (yêu cầu nghiệp vụ), chủ yếu dùng ở Giai đoạn A để biến một Vision còn mơ hồ thành một tình huống kinh doanh cụ thể, có thể đo lường được mức độ đáp ứng.
3. Gap Analysis — kỹ thuật so sánh có hệ thống giữa Baseline Architecture (kiến trúc hiện trạng) và Target Architecture (kiến trúc mục tiêu), dùng xuyên suốt Giai đoạn B, C, D để phát hiện những gì còn thiếu, thừa, hoặc cần thay đổi.

Ngoài ba kỹ thuật trên, TOGAF còn liệt kê thêm các kỹ thuật khác như Risk Management (quản trị rủi ro kiến trúc, xuyên suốt từ Giai đoạn E trở đi và thực chất chạy song song toàn bộ vòng đời), Capability-Based Planning (lập kế hoạch dựa trên năng lực), Architecture Principles (nguyên tắc kiến trúc, đã thiết lập từ Preliminary Phase và áp dụng xuyên suốt), và Interoperability Requirements. Điểm chung của toàn bộ nhóm này: chúng không có một "ô" cố định trên sơ đồ ADM, mà cắt ngang (cross-cutting) qua nhiều giai đoạn.

Vì sao TOGAF thiết kế như vậy thay vì gộp thẳng vào từng giai đoạn? Câu trả lời nằm ở chính bản chất lặp lại (iterative) của ADM. Nếu Requirements Management chỉ là một bước trong Giai đoạn A, thì khi Giai đoạn D phát hiện một ràng buộc công nghệ khiến yêu cầu ban đầu không khả thi, sẽ không có cơ chế chính thức nào để đưa thông tin đó quay ngược lại và cập nhật Business Architecture đã "chốt" ở Giai đoạn B. Đặt Requirements Management ở tâm, với đường mũi tên hai chiều tới mọi giai đoạn, chính là cách TOGAF mã hoá nguyên tắc: kiến trúc doanh nghiệp không phải một đường thẳng, mà là một hệ thống phản hồi liên tục.

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

1. Requirements Management — vòng đời yêu cầu ở tâm ADM

Quy trình Requirements Management gồm bốn bước lặp lại liên tục, không phải làm một lần:

Điểm mấu chốt khiến Requirements Management khác hẳn một "backlog" thông thường: mỗi khi có thay đổi, bước Đánh giá tác động bắt buộc phải quét ngược lại tất cả các giai đoạn đã hoàn thành để xem có gì cần cập nhật — đây chính là cơ chế phản hồi khiến ADM thực sự là một "phương pháp lặp" (iterative method) chứ không phải một quy trình thác nước (waterfall) đội lốt vòng tròn.

2. Business Scenarios — biến Vision mơ hồ thành yêu cầu kiểm chứng được

Business Scenarios là kỹ thuật cấu trúc hoá một tình huống kinh doanh thành các thành phần rõ ràng: vấn đề kinh doanh cần giải quyết, tác nhân (actor) liên quan (con người, hệ thống, quy trình), kết quả mong muốn, và các ràng buộc môi trường. Kỹ thuật này chủ yếu áp dụng ở Giai đoạn A để kiểm chứng Architecture Vision không chỉ là một câu khẩu hiệu chiến lược mà là một tập yêu cầu có thể đo lường được mức độ đáp ứng khi kiến trúc hoàn thành. Một Business Scenario tốt luôn trả lời được: "Nếu kiến trúc này thành công, điều gì cụ thể sẽ khác đi trong vận hành thực tế?"

3. Gap Analysis — kỹ thuật xuyên suốt B, C, D

Gap Analysis không phải một kỹ thuật riêng của một giai đoạn, mà được lặp lại có hệ thống ở cuối mỗi giai đoạn kiến trúc con (Business, Data, Application, Technology): liệt kê các thành phần trong Baseline Architecture, đối chiếu với Target Architecture, rồi phân loại mỗi khoảng cách vào một trong ba nhóm — Eliminated (thành phần cũ không còn cần trong tương lai), New (thành phần hoàn toàn mới cần xây), hoặc Retained (giữ nguyên, không thay đổi). Kết quả Gap Analysis của từng giai đoạn chính là nguyên liệu đầu vào trực tiếp cho Giai đoạn E khi xây dựng các gói công việc di trú (Work Packages).

4. Risk Management — chạy song song, không phải một bước

TOGAF khuyến nghị đánh giá rủi ro kiến trúc (Architecture Risk) ngay từ Giai đoạn E (khi lập kế hoạch di trú, rủi ro triển khai bắt đầu rõ nét) và duy trì xuyên suốt tới Giai đoạn H, nhưng thực hành tốt là bắt đầu ghi nhận rủi ro tiềm ẩn sớm hơn — ngay từ Giai đoạn A khi rủi ro chiến lược hoặc rủi ro về mức độ sẵn sàng thay đổi của tổ chức đã có thể xuất hiện. Giống Requirements Management, Risk Management là một sổ theo dõi sống (risk register sống), không phải một bản đánh giá làm một lần.

Case thực tế minh hoạ

(Đây là minh hoạ điển hình tổng hợp từ các tình huống phổ biến trong thực hành ADM, không phải case của một công ty cụ thể có thật — không nên coi bất kỳ chi tiết nào trong phần này là số liệu chính xác của một tổ chức thực tế.)

Một doanh nghiệp dịch vụ tài chính triển khai chương trình ADM để hiện đại hoá hệ thống xử lý hồ sơ khách hàng. Ở Giai đoạn A, đội kiến trúc tổ chức một loạt workshop thu thập yêu cầu với các bên liên quan, tổng hợp thành một tài liệu Business Requirements dày, được phê duyệt, rồi... đóng file. Từ đó trở đi, tài liệu này được coi là "chốt" — mọi giai đoạn sau chỉ tham chiếu nó như một bản thiết kế cứng, không có cơ chế chính thức nào để cập nhật ngược lại.

Vấn đề bắt đầu lộ diện ở Giai đoạn C. Khi đội kiến trúc dữ liệu đào sâu vào hệ thống hồ sơ khách hàng hiện tại, họ phát hiện một ràng buộc quan trọng: dữ liệu khách hàng đang phân mảnh trên ba hệ thống nguồn khác nhau do lịch sử sáp nhập, và việc hợp nhất theo đúng yêu cầu ban đầu (real-time, đồng bộ hai chiều) sẽ đòi hỏi chi phí và thời gian vượt xa ngân sách đã duyệt. Đây rõ ràng là một thông tin cần được đưa ngược lại Giai đoạn A và B để đánh giá lại mức độ ưu tiên và có thể điều chỉnh Business Requirements — ví dụ chuyển từ đồng bộ real-time sang đồng bộ theo lô (batch) cho giai đoạn đầu. Nhưng vì tổ chức không có một quy trình Requirements Management chính thức, phát hiện này chỉ được ghi trong biên bản họp nội bộ của đội kiến trúc dữ liệu, không được đối chiếu lại với Business Architecture đã "chốt" ở Giai đoạn B.

Hậu quả bộc lộ rõ ở Giai đoạn E khi lập kế hoạch di trú: đội phụ trách Migration Planning vẫn dựa trên giả định đồng bộ real-time từ tài liệu gốc, xây dựng lộ trình và ước tính ngân sách theo giả định đó — hoàn toàn không biết ràng buộc kỹ thuật đã phát hiện từ Giai đoạn C. Khi bản kế hoạch di trú trình lên Ban lãnh đạo, con số ngân sách và timeline lệch pha nghiêm trọng so với những gì đội kỹ thuật dữ liệu đã biết từ nhiều tháng trước — gây ra một vòng tranh cãi nội bộ về "ai đã biết gì, từ khi nào," làm chậm dự án thêm nhiều tuần chỉ để hoà giải lại các bên liên quan và làm rõ lại yêu cầu đã bị lệch pha.

Sau sự cố này, tổ chức thiết lập lại một Requirements Repository tập trung, gắn ID theo dõi cho từng yêu cầu, và bắt buộc mỗi giai đoạn khi phát hiện thông tin ảnh hưởng tới yêu cầu đã "chốt" ở giai đoạn trước phải ghi nhận chính thức vào kho này kèm đánh giá tác động, thay vì chỉ nằm trong biên bản họp nội bộ. Bài học rút ra không phải là kỹ thuật của đội dữ liệu sai — họ đã làm đúng việc phát hiện ràng buộc — mà là tổ chức thiếu cơ chế để thông tin đó lan truyền ngược lại đúng nơi cần biết. Đây chính là lỗ hổng cổ điển của việc coi Requirements Management là một bước làm-một-lần thay vì một dòng chảy liên tục ở tâm vòng tròn ADM.

📐 Template/Artifact áp dụng ngay

Requirements Repository — Bảng theo dõi vòng đời yêu cầu:

Quy tắc sử dụng:

• Mọi yêu cầu mới hoặc thay đổi phát hiện ở BẤT KỲ giai đoạn nào đều phải được ghi vào Repository này trước khi tiếp tục, không được xử lý ngầm trong biên bản họp nội bộ của một đội đơn lẻ.
• Bước "Đánh giá tác động" là bắt buộc — không được bỏ qua ngay cả khi thay đổi có vẻ nhỏ; chính những thay đổi "nhỏ" không được đánh giá tác động là nguyên nhân phổ biến nhất gây lệch pha giữa các giai đoạn.
• Repository nên được rà soát trong mỗi phiên họp Architecture Board định kỳ, không chỉ khi có sự cố.
• Khi một yêu cầu buộc phải xử lý lại một giai đoạn đã hoàn thành, cần cập nhật rõ baseline nào bị ảnh hưởng và thông báo tới toàn bộ đội đang làm việc ở các giai đoạn tiếp theo.

🎯 Góc nhìn Chief EA

Nếu một yêu cầu quan trọng thay đổi giữa Giai đoạn D và Giai đoạn F, tổ chức tôi có một cơ chế chính thức để lan truyền thay đổi đó ngược lại các giai đoạn đã "chốt," hay nó chỉ nằm im trong biên bản họp của một đội đơn lẻ?

Chúng tôi có đang coi Gap Analysis là một bài tập làm-cho-có ở cuối mỗi giai đoạn, hay thực sự dùng nó để định hình các gói công việc di trú ở Giai đoạn E?

Business Scenarios ở Giai đoạn A của chúng tôi có đủ cụ thể để đo lường được mức độ đáp ứng khi kiến trúc hoàn thành, hay vẫn chỉ là một tập slide chiến lược mơ hồ?

Ai trong tổ chức tôi thực sự "sở hữu" Requirements Repository — hay mỗi giai đoạn đang tự quản lý yêu cầu của riêng mình trong một file Excel cục bộ?

🔄 Vị trí trong chu trình ADM

Đây là điểm khác biệt quan trọng nhất của bài này so với các bài Giai đoạn A-H đã trình bày ở Phần 2: ADM Guidelines & Techniques — và đặc biệt là Requirements Management — không nằm trên vòng tròn ADM chính (A-H). Chúng là các kỹ thuật/hướng dẫn bổ trợ, được áp dụng xuyên suốt nhiều giai đoạn cùng lúc, chứ không gắn cố định vào một giai đoạn tuần tự nào.

Riêng Requirements Management giữ vị trí đặc biệt nhất trong toàn bộ mô hình TOGAF: nó được đặt Ở TÂM vòng tròn ADM, liên tục nhận yêu cầu phát sinh từ mọi giai đoạn và cung cấp lại yêu cầu đã được đánh giá, ưu tiên hoá cho mọi giai đoạn — từ Giai đoạn A (Bài 11) cho tới Giai đoạn H (Bài 21). Không có một mũi tên "nhận đầu vào từ" và "cho đầu ra sang" theo một chiều duy nhất như các giai đoạn khác — quan hệ của nó với toàn bộ vòng tròn là hai chiều và liên tục:

• Nhận đầu vào từ: mọi giai đoạn A-H, bất cứ khi nào một giai đoạn phát hiện thông tin mới ảnh hưởng tới yêu cầu đã có — ví dụ ràng buộc kỹ thuật phát hiện ở Giai đoạn C/D, hoặc độ lệch giữa triển khai thực tế và kiến trúc mục tiêu phát hiện ở Giai đoạn G (Governance).
• Cho đầu ra sang: mọi giai đoạn A-H, dưới dạng yêu cầu đã được đánh giá tác động và ưu tiên hoá, buộc giai đoạn liên quan phải xử lý lại nếu cần thiết trước khi tiếp tục vòng lặp ADM kế tiếp.

Gap Analysis và Business Scenarios có phạm vi hẹp hơn — chủ yếu phục vụ Giai đoạn A (Business Scenarios) và các giai đoạn B, C, D (Gap Analysis) — nhưng cùng chung nguyên tắc: đây là kỹ thuật hỗ trợ dùng lặp lại nhiều lần trong một chu trình ADM, không phải một bước làm một lần rồi bỏ qua.

🔗 Bài viết liên quan

• Bài 11: Giai đoạn A (Architecture Vision)
• Bài 20: Giai đoạn G (Governance & Compliance Review)

Bài trước: Giai đoạn H (Change Management) · Bài tiếp theo: Ngôn ngữ ArchiMate