title: "Lựa chọn framework EA: Khi nào TOGAF là đủ, khi nào cần kết hợp với Zachman hoặc FEAF?"
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: 7
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• TOGAF
• Zachman Framework
• FEAF
• Enterprise Architecture
• Framework Selection
• ADM

Lựa chọn framework EA: Khi nào TOGAF là đủ, khi nào cần kết hợp với Zachman hoặc FEAF?

Có một câu hỏi mà bất kỳ Chief EA nào cũng từng bị hỏi trong buổi kick-off dự án kiến trúc: "Mình dùng TOGAF đúng không?" — như thể TOGAF là cái duy nhất tồn tại, và câu trả lời chỉ có "có" hoặc "không". Tôi từng ngồi trong phòng họp với một đội kiến trúc trẻ, tự hào khoe bộ ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình của TOGAF) đầy đủ tám giai đoạn, nhưng khi kiểm toán nội bộ hỏi "danh mục tài sản CNTT của các anh phân loại theo tiêu chí nào, ai chịu trách nhiệm cho từng lớp dữ liệu ở từng vị trí triển khai" — cả đội đứng hình. TOGAF không trả lời câu đó tốt, vì TOGAF không được sinh ra để làm việc đó.

Đây chính là cái bẫy phổ biến nhất khi một tổ chức trưởng thành lên trong hành trình EA: coi framework là tôn giáo thay vì công cụ. TOGAF là một quy trình xuất sắc để đưa kiến trúc từ ý tưởng đến vận hành, nhưng nó không phải là toàn bộ vũ trụ tư duy kiến trúc doanh nghiệp. Có những công việc mà Zachman làm tốt hơn nhiều lần, có những bối cảnh mà FEAF (Federal Enterprise Architecture Framework) gần như là bắt buộc. Một Chief EA giỏi không phải là người thuộc lòng ADM, mà là người biết khi nào ADM chưa đủ.

Bài này không nhằm hạ bệ TOGAF — series 40 bài này lấy TOGAF làm xương sống vì lý do chính đáng: nó là framework quy trình toàn diện nhất, được hỗ trợ rộng nhất, và dễ tùy biến nhất. Nhưng một EA chuyên sâu cần hiểu rõ ranh giới năng lực của công cụ mình đang cầm, và biết cách phối hợp nhiều framework mà không biến kiến trúc doanh nghiệp thành một mớ tài liệu chồng chéo, mâu thuẫn nhau.

Bản chất

Điểm mấu chốt để hiểu sự khác biệt giữa các framework EA nằm ở câu hỏi: framework này trả lời câu hỏi "làm thế nào" (process) hay câu hỏi "là gì, thuộc về ai, ở đâu" (taxonomy)?

TOGAF là một process framework. Trọng tâm của nó là ADM — một chu trình lặp gồm các giai đoạn từ Preliminary, Architecture Vision (Giai đoạn A), Business Architecture (B), Information Systems Architecture (C), Technology Architecture (D), Opportunities & Solutions (E), Migration Planning (F), Implementation Governance (G), đến Architecture Change Management (H). TOGAF trả lời: "Chúng ta nên đi qua những bước nào, theo trình tự ra sao, để từ trạng thái hiện tại (Baseline Architecture) đến trạng thái mong muốn (Target Architecture)?" Nó mạnh về vòng đời, về quản trị thay đổi, về cách tổ chức công việc kiến trúc thành một capability có thể lặp lại. Nhưng TOGAF cố tình để ngỏ phần "chúng ta nên phân loại tài sản kiến trúc theo cấu trúc nào" — nó đưa ra Content Metamodel và một số artifact mẫu, nhưng không ép buộc một taxonomy chặt chẽ.

Zachman Framework là một classification schema — không phải một quy trình. Đây là điểm nhiều người mới học EA hiểu sai: Zachman không có "các bước thực hiện", nó là một ma trận 6x6 (đôi khi rút gọn 6x5) chiếu hai chiều lên nhau. Chiều dọc là sáu góc nhìn của các bên liên quan (Planner, Owner, Designer, Builder, Subcontractor, và góc nhìn vận hành thực tế — tương ứng cấp độ trừu tượng giảm dần). Chiều ngang là sáu câu hỏi nền tảng: What (dữ liệu), How (chức năng), Where (mạng lưới/vị trí), Who (con người/tổ chức), When (thời gian), Why (động cơ/mục tiêu). Mỗi ô trong ma trận 36 ô này là một loại artifact riêng biệt, độc lập, không được phép trộn lẫn. Sức mạnh của Zachman nằm ở tính đầy đủ và tính loại trừ lẫn nhau (mutually exclusive, collectively exhaustive) — không có góc nhìn nào bị bỏ sót, không có artifact nào bị xếp nhầm ô.

FEAF (Federal Enterprise Architecture Framework) ra đời từ nhu cầu quản trị CNTT của chính phủ liên bang Hoa Kỳ — nó thừa hưởng tinh thần phân loại của Zachman nhưng bổ sung mạnh phần Performance Reference Model, Business Reference Model, Service Reference Model, Data Reference Model, Technology Reference Model — một bộ five reference models được thiết kế để phục vụ việc báo cáo, tuân thủ quy định, và so sánh chuẩn hóa giữa nhiều cơ quan/đơn vị. FEAF không chỉ nói "phân loại thế nào" mà còn nói "báo cáo lên cấp trên bằng biểu mẫu chuẩn nào, đo hiệu suất đầu tư CNTT ra sao". Nó nặng về compliance, về khả năng tổng hợp báo cáo liên-bộ-ngành — thứ mà khu vực tư nhân hiếm khi cần đến mức đó, nhưng khu vực công gần như bắt buộc.

Vậy câu hỏi không phải "framework nào tốt nhất" mà là: tổ chức của bạn cần một cỗ máy vận hành kiến trúc (TOGAF), một hệ thống phân loại tài sản chặt chẽ (Zachman), hay một bộ khung tuân thủ báo cáo khu vực công (FEAF) — hay cả ba, ở các lớp khác nhau?

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

Bảng so sánh dưới đây là công cụ tôi dùng trong mọi buổi tư vấn chọn framework — đưa ra ngay từ đầu để tránh tranh luận cảm tính:

Nguyên tắc kết hợp mà tôi áp dụng nhất quán: TOGAF làm khung xương sống quy trình — ADM chạy vòng đời kiến trúc, quản trị governance qua Architecture Board. Zachman được mượn làm lưới phân loại (taxonomy overlay) mỗi khi TOGAF Content Metamodel tỏ ra không đủ chi tiết — ví dụ khi kiểm toán yêu cầu chứng minh mọi tài sản dữ liệu đều có chủ sở hữu (Who), mọi ứng dụng đều gắn với vị trí triển khai vật lý (Where), mọi quy trình đều truy vết được về động cơ nghiệp vụ (Why). Còn FEAF được mượn — thường chỉ một phần, không toàn bộ — khi tổ chức phải báo cáo lên cơ quan chủ quản, cơ quan quản lý ngành, hoặc khi mô hình đầu tư CNTT cần chứng minh hiệu suất theo biểu mẫu chuẩn.

Điều tối kỵ là làm ngược lại: cố dùng Zachman như một quy trình (nó không có bước thực thi, sẽ sa lầy trong tranh luận phân loại vô tận), hoặc cố dùng TOGAF như một taxonomy chặt chẽ (nó sẽ luôn để lại khoảng trống mà kiểm toán/quy định có thể bắt lỗi).

Case thực tế minh hoạ

(Minh hoạ điển hình tổng hợp — không phải case của một cơ quan cụ thể có thật, không phản ánh số liệu hay tên gọi thực tế nào.)

Một cơ quan quản lý nhà nước cấp tỉnh vận hành hệ thống dịch vụ công trực tuyến, đã triển khai TOGAF ADM tương đối bài bản: có Architecture Vision rõ ràng, có Business Architecture mô tả luồng xử lý hồ sơ, có Technology Architecture xác định hạ tầng cloud lai (hybrid cloud). Đội kiến trúc tự tin rằng bộ tài liệu ADM của mình là đầy đủ.

Đến kỳ kiểm toán an toàn thông tin theo quy định của cơ quan quản lý cấp trên, đoàn kiểm toán yêu cầu cung cấp: danh mục toàn bộ tài sản CNTT được phân loại theo mức độ nhạy cảm dữ liệu (What), đơn vị/cá nhân chịu trách nhiệm cho từng tài sản (Who), vị trí lưu trữ và xử lý vật lý — bao gồm việc dữ liệu có rời khỏi biên giới quốc gia hay không (Where), và mục tiêu/căn cứ pháp lý cho việc thu thập từng loại dữ liệu (Why). Đây chính xác là bốn trong sáu câu hỏi nền tảng của Zachman — và bộ tài liệu TOGAF hiện có, dù đầy đủ về quy trình, lại rời rạc và không đủ chi tiết để trả lời trực tiếp, vì TOGAF Content Metamodel không ép buộc mức độ phân rã đó.

Đội kiến trúc buộc phải bổ sung một lớp taxonomy kiểu Zachman: dựng một ma trận phân loại tài sản CNTT với các cột đúng tinh thần What/Who/Where/Why, ánh xạ ngược từ các artifact TOGAF đã có (Application Portfolio Catalog, Technology Portfolio Catalog) sang ma trận này. Công việc không phải làm lại từ đầu — mà là "chiếu" dữ liệu đã có qua một lưới phân loại mới, lấp đầy các ô còn trống bằng cách phỏng vấn chủ sở hữu nghiệp vụ (business owner) từng hệ thống.

Kết quả: TOGAF vẫn là quy trình vận hành chính — ADM tiếp tục chạy các vòng lặp cải tiến kiến trúc. Nhưng ma trận phân loại kiểu Zachman trở thành một artifact thường trực, được cập nhật song song mỗi khi Application Portfolio Catalog thay đổi, phục vụ trực tiếp cho các đợt kiểm toán tuân thủ định kỳ. Bài học rút ra: taxonomy không thay thế process, nhưng process không tự sinh ra taxonomy chặt — hai framework phục vụ hai nhu cầu khác nhau và cùng tồn tại được nếu phân vai rõ ràng.

📐 Template/Artifact áp dụng ngay

Bảng quyết định chọn/kết hợp framework EA — dùng trong buổi thiết lập Architecture Capability hoặc khi rà soát lại bộ công cụ kiến trúc hiện có:

Checklist trước khi quyết định kết hợp framework:

• Đã xác định rõ ai là "khách hàng" của yêu cầu bổ sung (kiểm toán nội bộ? cơ quan quản lý? ban điều hành?)
• Đã kiểm tra TOGAF Content Metamodel hiện có còn thiếu trường/thuộc tính nào so với yêu cầu
• Đã xác định framework bổ sung chỉ dùng ở phạm vi nào (toàn bộ tổ chức hay một domain cụ thể)
• Đã có kế hoạch đồng bộ hai bộ artifact (tránh một nguồn sự thật (single source of truth) bị phân mảnh thành hai nơi không khớp nhau)
• Đã truyền thông rõ cho đội kiến trúc: framework bổ sung là lớp phủ (overlay), không thay thế ADM

🎯 Góc nhìn Chief EA

• Nếu bỏ TOGAF đi, đội của tôi còn giữ được kỷ luật quy trình kiến trúc không, hay mọi thứ về lại tùy hứng từng dự án?
• Bộ tài liệu kiến trúc hiện tại có trả lời được đầy đủ sáu câu hỏi What/How/Where/Who/When/Why cho từng tài sản trọng yếu không — hay tôi chỉ đang giả định là có?
• Áp lực kết hợp thêm framework đến từ nhu cầu thực của tổ chức, hay từ việc tôi/đội muốn "trưng" thêm một chứng chỉ, một cái tên framework cho oai?
• Nếu thêm một lớp framework mới, ai là người duy trì nó lâu dài — hay nó sẽ chết yểu sau đợt kiểm toán đầu tiên?

🔗 Bài viết liên quan

• Giá trị của TOGAF — vì sao chọn TOGAF làm khung xương sống trước khi bàn đến việc kết hợp framework khác.
• Tư duy Hệ thống (Systems Thinking) trong EA — nền tảng tư duy giúp nhìn ra khi nào một framework đơn lẻ không còn đủ để mô tả toàn bộ hệ thống.

Bài trước: Tư duy Hệ thống (Systems Thinking) trong EA · Bài tiếp theo: Văn hóa kiến trúc