Khung Zachman (Zachman Framework)

1. Tổng quan

A. Định nghĩa

Khung Zachman (Zachman Framework) là một lược đồ phân loại hai chiều (classification schema, ontology) phân loại các sản phẩm cấu thành một doanh nghiệp (tổ chức) thành các giao điểm của sáu câu hỏi (cột) — "cái gì, như thế nào, ở đâu, ai, khi nào, tại sao" — và sáu góc nhìn của các bên liên quan (hàng): "Người lập kế hoạch, Chủ sở hữu, Người thiết kế, Người xây dựng, Người triển khai, Người sử dụng." Nói cách khác, đó là một bản đồ chuẩn hóa quy định "cần ghi lại cái gì thành tài liệu," chứ không phải một phương pháp luận quy định "xây dựng như thế nào."

Khung Zachman thường được ví như "bảng tuần hoàn của kiến trúc doanh nghiệp (EA)." Giống như bảng tuần hoàn hóa học không chỉ cho ta cách tổng hợp các nguyên tố nhưng lại quy định đầy đủ, không trùng lặp vị trí mà mọi nguyên tố thuộc về, Khung Zachman cũng không đưa ra quy trình tạo ra các sản phẩm kiến trúc của tổ chức, nhưng quy định một cách trọn vẹn sản phẩm nào thuộc về ô nào. Đây chính là điểm phân biệt mang tính quyết định với các phương pháp luận như ADM của TOGAF, và vì thế hai bên không phải quan hệ cạnh tranh mà bổ sung cho nhau theo kiểu lược đồ phân loại (Zachman) + quy trình phát triển (TOGAF).

Có ba đặc trưng cốt lõi. Thứ nhất, 6×6 = 36 ô tạo thành một cấu trúc chuẩn hóa (normalized) độc lập lẫn nhau và không trùng lặp. Thứ hai, mỗi ô là một mô hình nguyên thủy (primitive model) chỉ xử lý một biến duy nhất, nên một sản phẩm trộn lẫn hai biến trở lên (mô hình phức hợp, composite) được biểu diễn không phải bằng ô đó mà bằng tổ hợp các ô. Thứ ba, nó trung lập đối với bất kỳ công cụ, ký pháp, phương pháp luận cụ thể nào, nên bất kỳ ngôn ngữ mô hình hóa nào (UML, ERD, BPMN, v.v.) cũng có thể lấp đầy một ô.

Để hiểu đúng Khung Zachman, cần làm rõ rằng "khung không tạo ra kiến trúc giúp bạn." Khung chỉ cung cấp các "hộp phân loại rỗng" nơi các sản phẩm kiến trúc sẽ được đặt vào; vẽ cái gì và vẽ ra sao trong từng hộp được giao cho phương pháp luận, ký pháp và công cụ mà tổ chức lựa chọn. Chính nhờ tính trung lập này mà Zachman đã duy trì sức sống hơn ba mươi năm mà không bị trói buộc vào một nhà cung cấp hay trào lưu cụ thể nào, đồng thời cũng khiến người thực hành phàn nàn "vậy rốt cuộc nên bắt đầu từ cái gì trước." Tính hai mặt này không phải là khiếm khuyết mà là hệ quả tự nhiên của bản chất vốn có của nó: một lược đồ phân loại.

B. Bối cảnh ra đời và sự cần thiết

Khung Zachman bắt nguồn từ "A Framework for Information Systems Architecture" do John A. Zachman công bố trên IBM Systems Journal năm 1987. Vào thời điểm đó, khi các hệ thống thông tin lớn gia tăng nhanh chóng, có một vấn đề nghiêm trọng: đối với cùng một doanh nghiệp, bộ phận lập kế hoạch, người dùng nghiệp vụ, người thiết kế và người phát triển đều mô tả hệ thống bằng những ngôn ngữ và sản phẩm khác nhau, làm đứt gãy giao tiếp. Zachman tìm cách đưa vào hệ thống thông tin cách thức mà các ngành kỹ thuật trưởng thành như kiến trúc và chế tạo máy bay, qua hàng trăm năm, đã hệ thống hóa việc "mô tả cùng một đối tượng thông qua các bản vẽ từ nhiều góc nhìn."

Động lực thứ nhất là sự đứt gãy giao tiếp giữa các góc nhìn. "Khách hàng" mà một lãnh đạo nói đến và "bảng khách hàng" mà một DBA nói đến ở các mức trừu tượng khác nhau, nhưng khi bị trộn vào một tài liệu, những người khác nhau rốt cuộc lại hình dung những thứ khác nhau. Bằng cách tách các hàng (góc nhìn), khung buộc người ta phải làm rõ "ngay bây giờ chúng ta đang nói về mức trừu tượng nào."

Động lực thứ hai là kiểm soát việc thiếu sót và trùng lặp sản phẩm. Khi tài liệu kiến trúc lên đến hàng trăm loại, không có tiêu chí để phán đoán "cái gì bị thiếu và cái gì bị chồng chéo." Hệ tọa độ cố định gồm 36 ô đóng vai trò danh sách kiểm tra, phơi bày sớm, chẳng hạn, rằng "ô mô hình nghiệp vụ của cột Why (động cơ/quy tắc) đang trống → rủi ro các quy tắc nghiệp vụ không được phản ánh vào thiết kế."

Động lực thứ ba là khả năng truy vết (traceability) và phân tích tác động của thay đổi. Khi việc các yêu cầu của các hàng trên (phạm vi, nghiệp vụ) đi xuống thành các sản phẩm của các hàng dưới (công nghệ, triển khai) được nối bằng tọa độ, người ta có thể truy vết theo cột và hàng các dữ liệu, chức năng, hệ thống bị ảnh hưởng khi một quy tắc nghiệp vụ cụ thể thay đổi. Hàn Quốc cũng vậy, trong quá trình đưa vào kiến trúc công nghệ thông tin (ITA/EA) dựa trên Luật Chính phủ Điện tử, đã tham chiếu rộng rãi tư tưởng phân loại của Zachman làm cơ sở cho mô hình siêu dữ liệu của sản phẩm.

Động lực thứ tư là sự trưởng thành với tư cách một ngành kỹ thuật. Zachman cho rằng việc xây dựng hệ thống thông tin vẫn còn dừng ở giai đoạn chưa trưởng thành, phụ thuộc vào kinh nghiệm của người thợ, và chỉ ra rằng kiến trúc và chế tạo đã phát triển thành ngành kỹ thuật có thể tái lập và kiểm soát được bằng cách "hệ thống hóa cùng một đối tượng qua nhiều bản vẽ chính thức." Khung cung cấp điều kiện tiên quyết cho sự trưởng thành đó, tức là một hệ tọa độ chuẩn cho "cần mô tả cái gì từ góc nhìn nào." Định hướng này đến nay vẫn còn hiệu lực: khi tổ chức và hệ thống trở nên phức tạp hơn với chuyển đổi số, kiến trúc dựa vào tri thức ngầm rơi vào tình trạng mất kiểm soát, và nhu cầu về một lược đồ phân loại tường minh lại càng lớn hơn.

2. Cấu trúc của khung — Hai trục và 36 ô

Bản chất của Khung Zachman nằm ở chỗ "phân rã hoàn toàn một doanh nghiệp theo hai trục độc lập." Trục ngang (cột) biểu thị loại trừu tượng hóa; trục dọc (hàng) biểu thị mức độ cụ thể hóa (hiện thực hóa). Vì hai trục trực giao (orthogonal) với nhau nên bất kỳ sản phẩm kiến trúc nào cũng được phân loại bằng một tọa độ duy nhất: "nó trả lời câu hỏi nào (cột) × là góc nhìn của ai (hàng)." Tính trực giao này là cơ chế ngăn chặn trùng lặp và thiếu sót từ gốc rễ.

graph TD
    Z["Khung Zachman<br/>(ma trận phân loại 6 x 6)"]
    Z --> COL["Trục ngang: sáu câu hỏi (loại trừu tượng hóa)"]
    Z --> ROW["Trục dọc: góc nhìn các bên liên quan (mức cụ thể hóa)"]
    COL --> C1["What: Dữ liệu"]
    COL --> C2["How: Chức năng"]
    COL --> C3["Where: Mạng lưới"]
    COL --> C4["Who: Tổ chức/Con người"]
    COL --> C5["When: Thời gian/Lịch trình"]
    COL --> C6["Why: Động cơ/Quy tắc"]
    ROW --> R1["Phạm vi (Người lập kế hoạch/Executive)"]
    ROW --> R2["Mô hình nghiệp vụ (Chủ sở hữu/Business)"]
    ROW --> R3["Mô hình hệ thống (Người thiết kế/Architect)"]
    ROW --> R4["Mô hình công nghệ (Người xây dựng/Engineer)"]
    ROW --> R5["Biểu diễn chi tiết (Người triển khai/Technician)"]
    ROW --> R6["Doanh nghiệp vận hành (Người sử dụng/Enterprise)"]

A. Sáu cột — Sáu câu hỏi căn bản

Các cột tương ứng với sáu câu hỏi nguyên sơ (5W1H) mà con người đặt ra khi giải thích bất kỳ đối tượng nào. What (Dữ liệu) xử lý các sự vật/khái niệm mà tổ chức nắm giữ, tức là các thực thể và quan hệ giữa chúng. How (Chức năng) xử lý logic biến đổi của các tiến trình/chức năng mà tổ chức thực hiện. Where (Mạng lưới) xử lý các vị trí nơi công việc được thực hiện và cấu trúc truyền thông/hậu cần nối chúng. Who (Tổ chức) xử lý con người/vai trò/trách nhiệm thực hiện công việc và hệ thống thẩm quyền. When (Thời gian) xử lý các ràng buộc thời gian như thứ tự, chu kỳ, lịch trình của các sự kiện. Why (Động cơ) xử lý lý do mà tất cả tồn tại, tức là chiến lược, mục tiêu và quy tắc nghiệp vụ.

Một quy tắc quan trọng là giữa các cột không có thứ tự (no inherent order). Không có lý do gì để What phải đứng trước How; sáu câu hỏi là các trục phân rã ngang hàng. Hơn nữa, mỗi cột có mô hình cơ bản đơn giản và duy nhất của riêng nó. Chẳng hạn, mô hình cơ bản của cột What là cấu trúc "thực thể–quan hệ," còn của cột Who là cấu trúc "vai trò–trách nhiệm," và hai cái không quy giản về nhau. Trong thực tế, người ta thường chỉ vẽ chi tiết dữ liệu (What) và chức năng (How) và để trống Who, When, Why; vì điều này báo hiệu các khoảng trống thiết kế về tổ chức, quy tắc, thời điểm, nên khung làm cho các ô trống đó hiển thị và thúc đẩy việc bổ sung.

Việc sáu cột cấu thành một "phân rã hoàn chỉnh" bắt nguồn từ chỗ không tồn tại câu hỏi căn bản nào ngoài chúng. Ví dụ, nếu mô tả nghiệp vụ tín dụng của một ngân hàng, What nắm các thực thể như "khoản vay, tài sản bảo đảm, khách hàng"; How nắm các tiến trình "thẩm định, giải ngân, thu hồi tín dụng"; Where nắm vị trí xử lý của "hội sở, chi nhánh, trung tâm thẩm định"; Who nắm thẩm quyền của "cán bộ thẩm định, giám đốc chi nhánh, hội đồng tín dụng"; When nắm thời điểm "nộp hồ sơ → thẩm định → phê duyệt → giải ngân" và chu kỳ đáo hạn; Why nắm "quy định tỷ lệ BIS, quy tắc hạn mức tín dụng nội bộ," tương ứng. Trả lời đủ cả sáu thì nghiệp vụ tín dụng được mô tả không thiếu sót; để trống dù chỉ một thì lời giải thích khuyết đi bấy nhiêu. Như vậy các cột đóng vai trò "các trục MECE (loại trừ lẫn nhau, bao phủ toàn bộ) của sự giải thích."

B. Sáu hàng — Sáu góc nhìn của các bên liên quan

Các hàng là góc nhìn của những bên liên quan khác nhau nhìn vào cùng một doanh nghiệp, và càng đi từ trên xuống dưới, chúng càng được hiện thực hóa từ trừu tượng sang cụ thể. Hàng 1, Phạm vi (góc nhìn Người lập kế hoạch), là phác thảo ở mức phạm vi nghiệp vụ và các danh mục cốt lõi mà lãnh đạo nhìn thấy. Hàng 2, Mô hình nghiệp vụ (góc nhìn Chủ sở hữu), là cấu trúc nghiệp vụ ở mức khái niệm mà người dùng nghiệp vụ hiểu. Hàng 3, Mô hình hệ thống (góc nhìn Người thiết kế), là thiết kế logic độc lập với công nghệ triển khai. Hàng 4, Mô hình công nghệ (góc nhìn Người xây dựng), là thiết kế vật lý phụ thuộc vào sản phẩm/nền tảng cụ thể. Hàng 5, Biểu diễn chi tiết (góc nhìn Người triển khai), là đặc tả chi tiết theo từng đơn vị cấu thành như chương trình và DDL. Hàng 6, Doanh nghiệp vận hành (góc nhìn Người sử dụng), là chính tổ chức/hệ thống đang vận hành thực tế.

Điểm cốt lõi là mỗi hàng là một góc nhìn độc lập, hoàn chỉnh. Góc nhìn người thiết kế (hàng 3) không đơn thuần là sự chi tiết hóa góc nhìn chủ sở hữu (hàng 2), mà là kết quả của việc "biến đổi (transformation)" các yêu cầu của chủ sở hữu sang ngôn ngữ của người thiết kế. Do đó, gom sáu ô của một hàng theo chiều ngang thì được mô hình hoàn chỉnh của tổ chức nhìn từ góc nhìn ấy; gom sáu ô của một cột theo chiều dọc thì được toàn bộ quá trình một câu hỏi (ví dụ: dữ liệu) được tinh chỉnh từ trừu tượng sang cụ thể. Ví dụ dưới đây cho thấy cột What (Dữ liệu) được hiện thực hóa như thế nào dọc theo sáu hàng.

Một cách cụ thể, đưa một cổng dịch vụ hành chính công đi xuống qua sáu hàng trông như sau. Ở Phạm vi (hàng 1), phác thảo nghiệp vụ "tiếp nhận và xử lý khiếu nại trực tuyến" và danh mục khiếu nại mục tiêu được xác định; ở Mô hình nghiệp vụ (hàng 2), luồng nghiệp vụ khái niệm "tiếp nhận → phân công → xử lý → thông báo" và các khái niệm khiếu nại/cán bộ xử lý được vẽ ra. Ở Mô hình hệ thống (hàng 3), những cái này được thiết kế thành use case, mô hình dữ liệu logic và giao diện dịch vụ; ở Mô hình công nghệ (hàng 4), chúng được cụ thể hóa thành cấu trúc vật lý phù hợp với các sản phẩm WAS, DBMS, API gateway cụ thể. Biểu diễn chi tiết (hàng 5) là các sản phẩm theo đơn vị như màn hình, chương trình, DDL; Doanh nghiệp vận hành (hàng 6) là chính cổng khiếu nại đang vận hành thực tế. Ví dụ này làm rõ rằng cùng một đối tượng — "khiếu nại" — được biểu đạt bằng những ngôn ngữ hoàn toàn khác nhau khi đi xuống các hàng.

Việc một hàng là "biến đổi" chứ không phải "chi tiết hóa" thường bị bỏ qua trong thực tế và sinh ra lẫn lộn. Nếu là chi tiết hóa thì chỉ cần thêm các mục vào sản phẩm phía trên; nhưng nếu là biến đổi thì khi góc nhìn thay đổi, chủ thể chịu trách nhiệm và ngôn ngữ biểu đạt thay đổi toàn bộ. Chẳng hạn, nếu chủ sở hữu (hàng 2) mô tả quy tắc nghiệp vụ "gửi hóa đơn cho khách hàng mỗi tháng một lần," thì người thiết kế (hàng 3) biến đổi nó thành cấu trúc logic "tác vụ batch lập hóa đơn + thực thể hóa đơn + sự kiện gửi," còn người xây dựng (hàng 4) lại biến đổi tiếp thành một trình lập lịch batch và một sản phẩm hàng đợi thông điệp cụ thể. Vì thông tin được thêm vào và giả định được cụ thể hóa ở mỗi bước, giữa hàng trên và hàng dưới nhất thiết phải có liên kết truy vết để xác minh "yêu cầu đã được biến đổi đúng hay chưa." Khi liên kết này đứt, thất bại điển hình xảy ra: quy tắc đã thống nhất ở trên biến mất không tiếng động trong triển khai bên dưới.

graph LR
    D1["Phạm vi: danh mục dữ liệu nghiệp vụ cốt lõi (thực thể ứng viên)"] --> D2["Mô hình nghiệp vụ: mô hình dữ liệu khái niệm (ERD theo chủ đề)"]
    D2 --> D3["Mô hình hệ thống: mô hình dữ liệu logic (ERD đã chuẩn hóa)"]
    D3 --> D4["Mô hình công nghệ: mô hình dữ liệu vật lý (thiết kế phụ thuộc DBMS)"]
    D4 --> D5["Biểu diễn chi tiết: DDL bảng/script chỉ mục"]
    D5 --> D6["Doanh nghiệp vận hành: thực thể cơ sở dữ liệu đang vận hành thực tế"]

3. Bản chất của ô và các quy tắc của khung

A. Các quy tắc cơ bản của khung

Các quy tắc mà Zachman đưa ra bảo đảm rằng khung không phải là một bảng tùy ý mà là một lược đồ phân loại khép kín về mặt logic. Các quy tắc cốt lõi có thể tóm tắt như sau.

Các cột không có thứ tự: sáu câu hỏi ngang hàng, không có trước–sau hay hơn–kém. Không tồn tại sự ép buộc phải vẽ một cột cụ thể trước.
Mỗi cột có mô hình cơ bản đơn giản, duy nhất: What là thực thể–quan hệ, Who là vai trò–trách nhiệm; mỗi cột có một mô hình đặc hữu không thể quy giản.
Mỗi hàng là một góc nhìn phân biệt, hoàn chỉnh: không phải là chi tiết hóa của hàng trên mà là kết quả biến đổi góc nhìn.
Mỗi ô là duy nhất: 36 ô không chồng chéo về nghĩa, và nếu hai sản phẩm mâu thuẫn trở lên cùng chiếm một tọa độ thì đó là vấn đề quản trị.
Tổ hợp các ô của một hàng là mô hình hoàn chỉnh của góc nhìn đó: sự kết hợp theo chiều ngang tạo thành góc nhìn tích hợp của bên liên quan ấy.
Không đặt khái niệm meta vào ô: các khái niệm giải thích về khung không thể là nội dung của một ô (giữ tính chuẩn hóa).

B. Mô hình nguyên thủy và mô hình phức hợp

Lý do khung được gọi là "bản thể luận (ontology)" chứ không chỉ là một bảng 6×6 nằm ở các quy tắc nghiêm ngặt.

Việc rèn luyện diễn giải các sản phẩm phức hợp thành tổ hợp các ô giúp nắm bắt chính xác bản chất của các tài liệu thực tế. Chẳng hạn, lược đồ luồng dữ liệu (DFD) phân rã thành tổ hợp của dữ liệu (What) và xử lý (How); đặc tả use case thành tổ hợp của chức năng (How), tác nhân (Who) và thứ tự sự kiện (When); kế hoạch duy trì hoạt động liên tục thành tổ hợp của vị trí (Where), thời gian (When) và động cơ (Why). Phân rã như vậy làm lộ ra "tài liệu này trả lời những câu hỏi nào và bỏ sót câu hỏi nào," nên khung cũng được dùng như một thấu kính để ngược lại kiểm tra tính đầy đủ của sản phẩm.

Sự phân biệt giữa mô hình nguyên thủy và mô hình phức hợp cũng quan trọng từ góc độ tái sử dụng. Mô hình nguyên thủy (một ô) chỉ có một biến nên có thể tái sử dụng nguyên trạng trong bối cảnh khác, trong khi mô hình phức hợp (tổ hợp nhiều ô) bị ràng buộc vào một cách kết hợp cụ thể nên khả năng tái sử dụng kém hơn. Do đó khung hàm ý triết lý thiết kế "nơi nào có thể thì chuẩn hóa thành mô hình nguyên thủy để tích lũy, và dẫn xuất các sản phẩm phức hợp như các tổ hợp của chúng." Điều này đồng dạng (đồng dạng) với tư duy trong chuẩn hóa dữ liệu nhằm loại bỏ trùng lặp để giảm bất thường (anomaly), và việc áp dụng khái niệm chuẩn hóa vào các sản phẩm kiến trúc là đóng góp độc đáo của Zachman. Tuy vậy, trên thực tế khó giữ mọi sản phẩm ở dạng mô hình nguyên thủy, và các sản phẩm phức hợp thường hiệu quả hơn cho giao tiếp, nên vận hành theo kiểu phân chia vai trò "tích lũy thì chuẩn hóa, giao tiếp thì phức hợp" là thực tế hơn.

Lợi ích thực tiễn mà quy tắc này mang lại là "xác định vị trí của sản phẩm." Khi một tài liệu mới được tạo ra, hãy hỏi "nó trả lời câu hỏi nào và là góc nhìn của ai," thì tọa độ được ấn định; nếu đã có một tài liệu khác ở cùng tọa độ, có thể nghi ngờ trùng lặp hoặc xung đột phiên bản. Như trong trường hợp ở một dự án thế hệ mới ngành tài chính, cả "chuẩn dữ liệu lõi ngân hàng" lẫn "từ điển dữ liệu sản phẩm" đều được phân loại là (What, hàng 3 Mô hình hệ thống) và người ta phát hiện hai tổ chức đang vận hành các mô hình logic mâu thuẫn nhau, khung hoạt động như hệ tọa độ phát hiện xung đột trong quản trị.

Phân loại	Cột (What ~ Why)	Hàng (Phạm vi ~ Doanh nghiệp vận hành)
Ý nghĩa	Loại trừu tượng hóa (câu hỏi)	Mức cụ thể hóa (hiện thực hóa)
Thứ tự	Không có thứ tự (ngang hàng)	Hiện thực hóa trên → dưới
Kết hợp ngang	—	Mô hình hoàn chỉnh của một góc nhìn
Kết hợp dọc	Quá trình tinh chỉnh của một câu hỏi	—
Ví dụ sản phẩm tiêu biểu	Mô hình dữ liệu, bản đồ tiến trình, sơ đồ tổ chức, lịch trình, tập quy tắc	Tầm nhìn → mô hình khái niệm → thiết kế logic → thiết kế vật lý → mã → vận hành

4. So sánh và các trường hợp áp dụng — Quan hệ với TOGAF và EA chính phủ

Hiểu Khung Zachman như đối lập với TOGAF là một ngộ nhận phổ biến. Hai bên xử lý những câu hỏi hoàn toàn khác nhau. Zachman là một lược đồ phân loại quy định "những sản phẩm nào (What artifacts)" phải được mô tả để đầy đủ, còn TOGAF ADM là một phương pháp luận quy định "xây dựng theo thứ tự nào (how-to process)." Trong các dự án EA khu vực công và tài chính thực tế, một phương thức lai (hybrid) được dùng rộng rãi, trong đó mô hình siêu dữ liệu của sản phẩm (các loại sản phẩm và tọa độ) được xác định bằng hệ thống ô của Zachman, còn quy trình soạn thảo được vận hành theo các giai đoạn của TOGAF ADM (tầm nhìn → kiến trúc nghiệp vụ, dữ liệu, ứng dụng, công nghệ → cơ hội và kế hoạch chuyển đổi).

Góc nhìn	Khung Zachman	TOGAF	FEA (EA liên bang)
Bản chất	Lược đồ phân loại (ontology)	Phương pháp luận phát triển (ADM)	Lấy mô hình tham chiếu làm trung tâm
Câu hỏi cốt lõi	Ghi tài liệu cái gì	Phát triển như thế nào	Đo lường/chia sẻ cái gì
Cung cấp quy trình	Không (chỉ quy định "cái gì")	Có (ADM lặp)	Một phần
Điểm mạnh	Tính đầy đủ, kiểm tra thiếu sót	Quy trình thực thi, quản trị	Hiệu quả, mô hình tham chiếu
Hạn chế	Không trình bày cách soạn thảo	Tính đầy đủ phân loại là riêng	Áp dụng phức tạp

Như một trường hợp áp dụng có số liệu, trong một đợt nâng cấp EA của một cơ quan công, trong 36 ô chỉ những ô liên quan đến dữ liệu/ứng dụng được lấp đầy trên 70%, còn các cột Why (động cơ/quy tắc) và When (thời gian) chỉ được soạn ở mức dưới 20%. Điều này làm lộ ra rằng "các quy tắc và lịch trình chỉ tồn tại ngầm trong thiết kế," và dẫn đến một nhiệm vụ cải tiến là xây dựng riêng một kho quy tắc nghiệp vụ. Trong một trường hợp khác ở ngành chế tạo, cột Where (Mạng lưới) được làm tường minh trên cơ sở các dây chuyền nhà máy và trung tâm hậu cần, và được dùng làm bản đồ tham chiếu cho thiết kế tích hợp OT/IT trong quá trình chuyển đổi nhà máy thông minh. Như vậy, giá trị của khung không nằm ở "36 ô đã hoàn thành" mà ở "năng lực chẩn đoán để phát hiện các ô còn trống."

Nhìn sự so sánh không như một liệt kê các mục mà như "lý do khiến khác biệt phát sinh" sẽ rõ hơn. Khác biệt giữa Zachman và TOGAF rốt cuộc bắt nguồn từ khác biệt về tính chất phân loại đối với quy trình. Vì Zachman là một hệ tọa độ tĩnh nên nó mạnh ở việc phán đoán "tính đầy đủ" nhưng không thể trả lời "vậy soạn cái gì trước và như thế nào." Ngược lại, vì TOGAF ADM cung cấp một quy trình lặp nên nó mạnh ở thực thi nhưng tự nó không bảo đảm rằng các sản phẩm đã soạn bao phủ toàn bộ tổ chức không thiếu sót. Nên kết hợp cả hai sẽ cho ra sự bổ sung lẫn nhau: "chạy ADM, nhưng ánh xạ sản phẩm của từng giai đoạn vào các ô Zachman để kiểm tra thiếu sót." ArchiMate bổ sung ký pháp ở đây, cho phép vẽ nội dung các ô thành các sơ đồ nhất quán.

Một biến số khác quyết định thành bại trong áp dụng thực tiễn là mức độ tích hợp với quản trị. Nếu chỉ xác định các tọa độ phân loại mà không có quản trị kiểm soát việc tạo, cập nhật, thẩm định sản phẩm, thì 36 ô trở thành "tài liệu chết" tách rời khỏi thực tế một khi đã được lấp đầy. Điểm chung của các trường hợp thành công là họ đã liên kết tọa độ ô với quản lý cấu hình và kho siêu dữ liệu, sao cho khi một quy tắc nghiệp vụ (Why) thay đổi, các ô dữ liệu (What) và chức năng (How) bị ảnh hưởng được tự động truy vết và đưa qua thẩm định thay đổi. Nghĩa là, Zachman không dừng lại ở "bảng phân loại tĩnh"; nó chỉ sinh lợi trên vốn đầu tư khi tiếp tục sống như chỉ mục của quy trình quản lý thay đổi.

5. Chuyên sâu — Zachman 3.0 và sự diễn giải lại trong thời đại chuyển đổi số

Kể từ lần công bố đầu tiên năm 1987, Khung Zachman đã được tinh chỉnh ký pháp và thuật ngữ nhiều lần. Nó khởi đầu với ba cột (dữ liệu, chức năng, mạng lưới) và ba hàng, nhưng về sau các cột Who, When, Why và các hàng Biểu diễn chi tiết, Doanh nghiệp vận hành được thêm vào để hoàn thiện cấu trúc 6×6 hiện tại. Bản thân quá trình mở rộng này phản ánh định hướng "bao phủ không thiếu sót các trục của sự giải thích."

Zachman Framework 3.0, phát hành năm 2011, đã tinh chỉnh thuật ngữ để các cột là What (Inventory), How (Process), Where (Distribution), Who (Responsibility), When (Timing), Why (Motivation), và các hàng là Executive, Business Management, Architect, Engineer, Technician, Enterprise Perspective. Đặc biệt, nó làm rõ rằng hàng dưới cùng không phải là "sản phẩm triển khai" mà là "doanh nghiệp đang vận hành (the operating enterprise)," nhấn mạnh rằng kiến trúc hướng tới thực thể đang vận hành chứ không phải tài liệu.

Trong thời đại chuyển đổi số, điện toán đám mây và vi dịch vụ, có lời phê bình rằng "EA nặng nề lấp đầy cả 36 ô là lạc hậu," nhưng đây là sự lẫn lộn giữa lược đồ phân loại và cách thức soạn thảo. Ngay cả trong môi trường agile/lean, bản thân hệ tọa độ cho "ghi tài liệu cái gì" vẫn còn hiệu lực; điểm mấu chốt chỉ là cách dùng thích ứng — chỉ lấp đầy những ô cần thiết, một cách đúng lúc và nhẹ nhàng — được khuyến nghị hơn là sản xuất quá mức mọi ô ngay từ đầu. Gần đây cũng quan sát thấy các nỗ lực tái sử dụng phân loại ô của Zachman làm phân loại siêu dữ liệu của quản trị dữ liệu/catalog dữ liệu hoặc làm bản thể luận cấp trên của một đồ thị tri thức doanh nghiệp, và mượn nó làm hệ thống gán nhãn khi AI tạo sinh tự động phân loại và tóm tắt tài liệu của tổ chức. Tuy vậy, vì các ứng dụng gần đây này là những nỗ lực chưa được chuẩn hóa, nên hiểu chúng ở mức "định hướng" hơn là khẳng định là thích hợp.

Môi trường vi dịch vụ/cloud-native một cách nghịch lý lại làm nổi bật tầm quan trọng của cột Where (Phân tán) và cột When (Thời điểm) của Zachman. Trong thời đại monolith, hầu hết xử lý diễn ra tuần tự tại một vị trí nên Where và When đơn giản; nhưng nay, với hàng trăm dịch vụ phân tán qua nhiều region/availability zone và tương tác qua các sự kiện bất đồng bộ, "chạy ở đâu và khi nào xảy ra theo thứ tự nào" đã trở thành bài toán cốt lõi của thiết kế. Sự phân biệt cột của Zachman đáp ứng tự nhiên với thay đổi này, buộc topo phân tán và thời điểm sự kiện phải được xử lý như các chiều thiết kế tường minh riêng biệt. Ở khía cạnh này, vì các trục phân rã của khung dựa trên cấu trúc căn bản của sự giải thích chứ không dựa trên một trào lưu công nghệ cụ thể, nên chúng bền vững trước thay đổi công nghệ.

6. Cân nhắc và hàm ý (từ góc nhìn Kỹ sư chuyên nghiệp)

Chiến lược áp dụng — dùng như công cụ kiểm tra tính đầy đủ: Nếu tiếp nhận Zachman như "nghĩa vụ lấp đầy mọi ô," chi phí lập tài liệu sẽ bùng nổ. Yếu tố thành công then chốt là lấy 36 ô làm danh sách kiểm tra để chẩn đoán các góc nhìn bị thiếu (đặc biệt là Why, When, Who), và vận hành thích ứng bằng cách lấp đầy trước các ô ưu tiên cao phù hợp với độ trưởng thành của tổ chức.
Đánh đổi — tính đầy đủ đối với tính linh hoạt: Tính đầy đủ của khung mạnh cho quản trị/truy vết, nhưng sản xuất trước quá mức cản trở tốc độ agile. Phải giữ lược đồ phân loại nhưng lấy thời điểm và khối lượng sản xuất theo cách lean (lean), và bổ sung quy trình tạo sản phẩm bằng một phương pháp luận như TOGAF ADM.
Công nghệ liên quan — kết hợp với phương pháp luận và quản trị: Vì Zachman ("cái gì") không tự hoàn chỉnh, nó chỉ hiệu quả khi kết hợp với TOGAF ADM (quy trình), ArchiMate (ký pháp), quản trị EA (nguyên tắc/thẩm định) và quản lý siêu dữ liệu/cấu hình (lưu trữ/phiên bản sản phẩm). Đặc biệt, liên kết tọa độ sản phẩm với quản lý cấu hình và catalog dữ liệu sẽ trở thành nền tảng để tự động hóa phân tích tác động thay đổi.
Triển vọng — giá trị bền vững với tư cách bản thể luận phân loại: Các phương pháp luận phát triển đã thay đổi theo trào lưu, nhưng tư tưởng phân loại "phân rã một doanh nghiệp thành 6×6" trung lập với công cụ nên có tuổi thọ dài. Độ phức tạp của các sản phẩm chuyển đổi số càng lớn, giá trị của một hệ tọa độ quy định "đặt cái gì ở đâu" càng cao, và có khả năng phạm vi của nó mở rộng sang quản trị dữ liệu và quản lý tri thức AI.
Rủi ro — cảnh giác với sự hình thức hóa: Nếu EA biến chất thành "sản xuất hàng loạt tài liệu để báo cáo," nó trở thành giấy tờ chết tách rời khỏi thực tế. Phải định kỳ xác minh tính nhất quán với thực thể vận hành (hàng 6) và bảo đảm một vòng lặp quản trị thực sự dùng kiến trúc trong việc ra quyết định.
Năng lực tổ chức — bố trí chuyên môn theo từng góc nhìn: Vì sáu hàng đòi hỏi những chuyên môn khác nhau, các vai trò chịu trách nhiệm cho từng góc nhìn (lập kế hoạch kinh doanh, người dùng nghiệp vụ, kiến trúc sư, kỹ sư, v.v.) phải thực sự được bố trí trong tổ chức thì khung mới vận hành. Nếu nhân sự của một góc nhìn cụ thể bị khuyết, các ô của hàng đó chỉ được lấp đầy một cách hình thức, và điều này phải được tiếp cận như một vấn đề thiết kế tổ chức chứ không phải chất lượng sản phẩm.

Tài liệu tham khảo

John A. Zachman, "A Framework for Information Systems Architecture", IBM Systems Journal, 1987 — https://www.zachman.com/
Zachman International, "The Zachman Framework" (3.0) — https://www.zachman.com/about-the-zachman-framework
The Open Group, TOGAF Standard — https://www.opengroup.org/togaf

Tóm tắt một câu: Khung Zachman là một lược đồ phân loại chuẩn hóa phân rã các sản phẩm doanh nghiệp thành 36 ô — "sáu câu hỏi (cột) × góc nhìn các bên liên quan (hàng)" — và, khi kết hợp với một phương pháp luận (TOGAF) cung cấp quy trình soạn thảo, đóng vai trò hệ tọa độ của EA để chẩn đoán thiếu sót và trùng lặp.