title: "Catalog, Matrix, Diagram: 3 loại tài liệu EA cốt lõi và cách kết nối chúng"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 3 — Kỹ thuật thiết kế & Mô hình hóa (Modeling & Artifacts)"
order: 24
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• TOGAF
• Enterprise Architecture
• Catalog
• Matrix
• Diagram
• Architecture Artifacts
• ArchiMate

Catalog, Matrix, Diagram: 3 loại tài liệu EA cốt lõi và cách kết nối chúng

Một buổi trình bày kiến trúc thường kết thúc bằng tràng vỗ tay. Sơ đồ ArchiMate trên slide cuối cùng có màu sắc chuẩn, ký hiệu đúng notation, các lớp Business — Application — Technology xếp gọn gàng theo chiều dọc, mũi tên realization nối liền mạch từ năng lực kinh doanh xuống tận con server. Ban lãnh đạo gật đầu. Dự án được duyệt ngân sách. Sáu tháng sau, một sự cố bảo mật buộc CISO phải hỏi gấp: "Ứng dụng nào trong công ty đang chạy trên phiên bản TLS đã bị khai tử?" Đội kiến trúc lục lại toàn bộ kho sơ đồ đẹp đẽ đó — và không tìm ra câu trả lời trong vòng một ngày làm việc.

Đây không phải là lỗi của sơ đồ. Sơ đồ vẫn đúng, vẫn đẹp, vẫn đúng notation. Vấn đề là tổ chức đã nhầm lẫn giữa một khung nhìn (view) với nguồn dữ liệu (data source). Một sơ đồ kiến trúc, dù được vẽ công phu đến đâu, cũng chỉ hiển thị một lát cắt quan hệ đã được chọn lọc trước — nó không phải là nơi lưu trữ toàn bộ thuộc tính của từng thực thể kiến trúc. Khi câu hỏi đặt ra không phải "kiến trúc trông như thế nào" mà là "liệt kê cho tôi tất cả X thỏa điều kiện Y", sơ đồ bất lực, vì bản chất nó không được thiết kế để truy vấn.

TOGAF giải quyết đúng vấn đề này bằng cách phân loại Artifact (sản phẩm đầu ra kiến trúc) thành ba dạng có vai trò khác biệt rõ ràng: Catalog, Matrix, và Diagram. Đây không phải là ba lựa chọn thay thế cho nhau để EA chọn tùy sở thích trình bày — mà là ba tầng dữ liệu bổ trợ bắt buộc phải cùng tồn tại. Bài này đi thẳng vào bản chất của từng loại, khi nào dùng loại nào, và quan trọng nhất — nguyên tắc buộc chúng phải liên kết chặt với nhau thay vì tồn tại rời rạc.

Bản chất

TOGAF định nghĩa Artifact là bất kỳ sản phẩm kiến trúc nào mô tả một khía cạnh của kiến trúc — và phân loại toàn bộ Artifact theo ba dạng biểu diễn cơ bản, độc lập với lớp kiến trúc (Business/Data/Application/Technology) mà chúng mô tả:

Catalog là một danh sách kiểm kê (inventory) các thực thể kiến trúc thuộc cùng một loại, kèm thuộc tính chi tiết của từng thực thể. Catalog trả lời câu hỏi "chúng ta có những gì, và mỗi thứ có đặc điểm ra sao." Application Portfolio (đã bàn ở Bài 16) là một Catalog điển hình — mỗi dòng là một ứng dụng, mỗi cột là một thuộc tính (chủ sở hữu, công nghệ nền, tình trạng vendor support...). Catalog là tầng dữ liệu nền tảng nhất — không có Catalog, không có gì để đưa vào Matrix hay Diagram.

Matrix là một ma trận hai chiều thể hiện quan hệ giữa hai loại thực thể kiến trúc khác nhau. Matrix trả lời câu hỏi "thực thể A liên quan đến thực thể B như thế nào." Ma trận Application-to-Function (ứng dụng nào hỗ trợ chức năng nghiệp vụ nào) đã nhắc ở Bài 16 dưới dạng Application-to-Capability Mapping là ví dụ kinh điển. Matrix không mô tả bản thân từng thực thể (đó là việc của Catalog) — nó mô tả quan hệ giữa hai Catalog.

Diagram là một biểu diễn trực quan (visual representation) của một tập con dữ liệu đã chọn lọc từ Catalog và Matrix, dùng ký hiệu chuẩn hóa (như ngôn ngữ ArchiMate đã bàn ở Bài 23) để truyền đạt cho một nhóm stakeholder cụ thể. Diagram trả lời câu hỏi "kiến trúc trông như thế nào, và các phần liên kết với nhau ra sao trong một bức tranh tổng thể."

Điểm mấu chốt về mặt triết lý framework: TOGAF không xếp Diagram ở vị trí cao hơn Catalog và Matrix. Ngược lại — theo đúng tinh thần Architecture Content Framework của TOGAF, Diagram luôn là một khung nhìn (view) được sinh ra từ dữ liệu nằm trong Catalog và Matrix, chứ không phải là nguồn sự thật (source of truth) độc lập. Một sơ đồ không đi kèm Catalog/Matrix đứng sau nó về bản chất là một hình minh họa (illustration), không phải một Artifact kiến trúc theo đúng nghĩa TOGAF — vì nó không thể truy vấn, không thể đối chiếu chéo, và không đảm bảo tính nhất quán khi có nhiều sơ đồ cùng mô tả một thực thể.

Sai lầm phổ biến nhất mà bài này muốn chỉ thẳng: nhiều đội kiến trúc, đặc biệt khi mới tiếp cận ArchiMate, bị cuốn vào việc vẽ Diagram vì đó là phần "nhìn thấy được" và tạo ấn tượng nhanh với stakeholder. Nhưng nếu bỏ qua Catalog/Matrix, đội kiến trúc đang xây nhà từ nóc — có mái đẹp nhưng không có móng để tra cứu, đối chiếu, hay tự động cập nhật khi thực tế thay đổi.

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

Bảng phân biệt khi nào dùng loại nào

Nguyên tắc liên kết ba lớp Artifact

Ba loại Artifact này không nên được tạo ra và duy trì độc lập. Nguyên tắc vận hành đúng:

1. Catalog là lớp nền, luôn được xây trước. Mọi Diagram và Matrix đều phải truy xuất được về ít nhất một Catalog gốc. Nếu một thực thể xuất hiện trên sơ đồ nhưng không có dòng tương ứng trong Catalog nào, đó là dấu hiệu dữ liệu kiến trúc đang "trôi nổi" — không kiểm soát được.

2. Matrix là cầu nối giữa hai Catalog, không phải dữ liệu độc lập. Một Application/Technology Matrix chỉ có giá trị khi cả Application Catalog và Technology Standards Catalog đều tồn tại và được cập nhật đồng bộ — nếu không, ma trận nhanh chóng lỗi thời so với thực tế.

3. Diagram là view sinh ra từ Catalog + Matrix cho một mục đích cụ thể, không phải nơi nhập liệu gốc. Về mặt thực hành công cụ (tool-based EA repository như các nền tảng hỗ trợ ArchiMate có repository trung tâm), đây chính là lý do các công cụ EA trưởng thành luôn tách biệt "model repository" (chứa Catalog/Matrix dạng dữ liệu có cấu trúc) khỏi "diagram/view" (chỉ là cách trình bày một phần dữ liệu đó) — sửa một thuộc tính trong repository sẽ tự động phản ánh trên mọi sơ đồ có chứa thực thể đó, thay vì phải sửa tay từng file vẽ.

4. Mỗi lần một Diagram mới được tạo, phải tự hỏi: dữ liệu trong sơ đồ này đã có trong Catalog/Matrix nào chưa? Nếu chưa, việc đầu tiên là bổ sung Catalog/Matrix, sau đó mới vẽ Diagram như một khung nhìn phái sinh — không làm ngược lại.

5. Không phải mọi thực thể đều cần cả ba dạng. TOGAF không yêu cầu máy móc "mỗi Catalog phải có Matrix và Diagram tương ứng." Nguyên tắc là: Catalog gần như luôn cần cho mọi loại thực thể quan trọng cần quản trị lâu dài; Matrix chỉ cần khi có nhu cầu phân tích quan hệ/tác động cụ thể (ví dụ đánh giá ảnh hưởng khi thay đổi một chuẩn công nghệ); Diagram chỉ cần khi có nhu cầu truyền đạt cho một nhóm stakeholder cụ thể trong một bối cảnh cụ thể (Architecture Vision cho ban lãnh đạo, Solution Overview cho đội triển khai...).

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 EA, 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ỳ số liệu nào trong phần này là thống kê chính xác.)

Một tổ chức trong lĩnh vực tài chính đầu tư đáng kể vào việc chuẩn hóa mô hình hóa kiến trúc — thuê tư vấn ArchiMate, tổ chức đào tạo nội bộ, và trong vòng một năm, đội kiến trúc sản xuất được một bộ sơ đồ chất lượng cao: Business Architecture Overview, Application Cooperation Diagram, Technology Infrastructure Diagram, tất cả đúng notation, được lưu trong một thư mục trình bày có tổ chức và thường xuyên được đưa ra trong các buổi họp Architecture Review Board.

Sự cố xảy ra khi một lỗ hổng bảo mật nghiêm trọng được công bố công khai trên một phiên bản thư viện mã hóa phổ biến. Đội bảo mật cần câu trả lời trong vòng 24 giờ: có bao nhiêu ứng dụng đang sử dụng phiên bản thư viện đó, ứng dụng nào xử lý dữ liệu nhạy cảm, và mức độ ưu tiên vá lỗi nên sắp xếp ra sao. Đội kiến trúc mở bộ sơ đồ ArchiMate ra tra cứu — và phát hiện ra vấn đề căn bản: các sơ đồ Application Cooperation chỉ thể hiện ứng dụng nào giao tiếp với ứng dụng nào, không có thuộc tính "phiên bản thư viện đang dùng" gắn kèm từng node trên sơ đồ, vì thuộc tính này chưa từng được đưa vào Catalog nào cả — nó chỉ tồn tại rải rác trong tài liệu triển khai riêng lẻ của từng team phát triển.

Không có Application Catalog đủ chi tiết (với cột thuộc tính công nghệ nền/thư viện phụ thuộc), và không có Technology Standards Matrix nối ứng dụng với chuẩn công nghệ đang dùng, đội kiến trúc buộc phải quay lại phương án thủ công — gửi khảo sát tới từng team phát triển và chờ phản hồi, đúng quy trình mà một danh mục kiến trúc được duy trì tốt lẽ ra đã loại bỏ được từ đầu. Câu trả lời đầy đủ chỉ có được sau vài ngày, chậm hơn nhiều so với mốc 24 giờ đội bảo mật yêu cầu.

Sau sự cố, tổ chức không từ bỏ các sơ đồ ArchiMate đã đầu tư — chúng vẫn hữu ích cho việc trình bày và giao tiếp. Thay vào đó, đội kiến trúc bổ sung phần còn thiếu: một Application Portfolio Catalog đầy đủ thuộc tính công nghệ nền, và một Application/Technology Standards Matrix map từng ứng dụng với các chuẩn/thư viện đang sử dụng, được đồng bộ định kỳ với dữ liệu từ hệ thống quản lý cấu hình. Từ đó, các sơ đồ ArchiMate được vẽ lại theo đúng nguyên tắc: là khung nhìn phái sinh từ Catalog/Matrix, không phải nguồn dữ liệu độc lập — và khi câu hỏi tương tự xuất hiện lần sau, câu trả lời có thể truy vấn ra trong vài phút thay vì vài ngày.

📐 Template/Artifact áp dụng ngay

Bảng kiểm Catalog/Matrix/Diagram cho mỗi vùng kiến trúc — dùng để tự đánh giá xem một domain kiến trúc (ví dụ: Application, Technology, Data) đã có đủ nền tảng ba lớp hay chưa, trước khi phê duyệt bất kỳ sơ đồ trình bày nào:

Quy tắc sử dụng:

• Cột "Diagram có trace được về Catalog/Matrix nguồn không?" là cột quan trọng nhất — bất kỳ dòng nào trả lời "Không" là dấu hiệu sơ đồ đó đang là hình minh họa rời rạc, cần bổ sung Catalog/Matrix nền trước khi tiếp tục dùng sơ đồ trong ra quyết định chính thức.
• Trước khi Architecture Review Board (Bài 31) phê duyệt bất kỳ Diagram nào làm căn cứ quyết định đầu tư, yêu cầu người trình bày chỉ ra Catalog/Matrix nguồn tương ứng.
• Bảng này nên được rà soát lại mỗi khi tổ chức mở rộng một domain kiến trúc mới hoặc sau mỗi sự cố cho thấy khoảng trống dữ liệu (như case minh họa ở trên).

🎯 Góc nhìn Chief EA

Nếu ngay bây giờ một stakeholder hỏi "liệt kê cho tôi tất cả X thỏa điều kiện Y" về bất kỳ domain kiến trúc nào, đội tôi có trả lời được bằng một truy vấn trong vài phút, hay phải mở từng sơ đồ ra đếm bằng mắt?

Trong kho Artifact hiện tại, bao nhiêu phần trăm là Diagram không có Catalog/Matrix nào đứng sau — tức là những hình minh họa đẹp nhưng không thể tra cứu?

Khi một thực thể kiến trúc thay đổi (ứng dụng nghỉ hưu, chuẩn công nghệ cập nhật), có cơ chế nào đảm bảo mọi sơ đồ liên quan tự động phản ánh thay đổi đó, hay tôi đang phụ thuộc vào việc ai đó nhớ sửa tay từng file?

Tôi có đang đánh giá năng lực một EA/kiến trúc sư trong đội qua chất lượng sơ đồ họ vẽ, hay qua chất lượng và độ đầy đủ của Catalog/Matrix họ duy trì phía sau?

🔗 Bài viết liên quan

• Bài 23: Ngôn ngữ ArchiMate
• Bài 16: Giai đoạn C (Application Portfolio)

Bài trước: Ngôn ngữ ArchiMate · Bài tiếp theo: Kiến trúc dữ liệu (Data Architecture)