title: "Giai đoạn C (Information Systems Architecture): Chiến lược thiết kế kiến trúc dữ liệu tập trung"
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: 15
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• ADM
• Data Architecture
• Information Systems Architecture
• Master Data Management
• Enterprise Architecture

Giai đoạn C (Information Systems Architecture): Chiến lược thiết kế kiến trúc dữ liệu tập trung

Có một câu hỏi tưởng đơn giản nhưng làm bối rối không ít CEO: "Công ty mình có bao nhiêu khách hàng?" Team Sales nói 12.400, dựa trên CRM. Team Marketing nói 18.700, tính theo database email marketing (bao gồm cả lead chưa mua). Team Kế toán nói 9.100, chỉ đếm khách hàng có hợp đồng active trong ERP. Cả ba đều đúng — theo cách hệ thống của họ định nghĩa "khách hàng". Và cả ba đều sai — theo nghĩa không ai trong công ty biết con số thật.

Đây không phải lỗi của một cá nhân hay một phòng ban. Đây là hậu quả tất yếu của việc để mỗi hệ thống tự phát triển mô hình dữ liệu riêng, không có một tầng kiến trúc nào đứng ra định nghĩa "khách hàng là gì" ở cấp doanh nghiệp. Nhiều tổ chức coi dữ liệu là sản phẩm phụ của ứng dụng — cứ xây app trước, dữ liệu tự nhiên sinh ra sau — và chỉ nhận ra vấn đề khi báo cáo tài chính, báo cáo vận hành và dashboard điều hành lệch nhau đến mức không ai còn tin số liệu nào cả.

TOGAF ADM giải quyết đúng lỗ hổng này ở Giai đoạn C, phần Data Architecture — một trong hai nhánh của Information Systems Architecture (nhánh còn lại là Application Architecture, sẽ nói ở bài 16). Đây là giai đoạn EA phải tạm gác câu chuyện "app nào chạy trên nền tảng nào" để trả lời câu hỏi nền tảng hơn: dữ liệu nào là tài sản chung của doanh nghiệp, ai sở hữu nó, và nó phải được tạo ra — lưu trữ — chia sẻ theo nguyên tắc gì để không tái diễn tình trạng "mỗi hệ thống một phiên bản sự thật".

Bản chất

Giai đoạn C trong ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình lặp của TOGAF) tách thành hai luồng công việc song song: Data Architecture và Application Architecture. Bài này tập trung vào Data Architecture — phần thường bị đánh giá thấp hơn Application Architecture vì nó ít "nhìn thấy được" hơn, nhưng lại là phần quyết định liệu toàn bộ portfolio ứng dụng có nói cùng một ngôn ngữ hay không.

Bản chất của Data Architecture ở Giai đoạn C không phải là thiết kế schema database — đó là việc của kỹ sư dữ liệu, không phải EA. Bản chất của nó là ba câu hỏi ở tầng doanh nghiệp:

Thứ nhất, đâu là các thực thể dữ liệu cốt lõi (core data entities) mà toàn doanh nghiệp cùng cần đến, và chúng quan hệ với nhau ra sao? Đây chính là Conceptual Data Model — mô hình dữ liệu khái niệm, mô tả các khái niệm nghiệp vụ (Customer, Product, Order, Contract...) và mối quan hệ giữa chúng, độc lập hoàn toàn với bất kỳ hệ thống hay công nghệ cụ thể nào. Nó khác Logical Data Model (chi tiết attribute, kiểu dữ liệu, chuẩn hoá) và càng khác Physical Data Model (bảng, cột, index trong một DBMS cụ thể) — hai tầng sau thuộc về công việc thiết kế hệ thống, không phải EA.

Thứ hai, trong số các thực thể đó, đâu là Master Data — dữ liệu chủ cần một nguồn sự thật duy nhất (Single Source of Truth) được toàn doanh nghiệp công nhận, thay vì để mỗi hệ thống tự lưu bản sao riêng rồi lệch pha dần theo thời gian? Không phải dữ liệu nào cũng cần quản trị tập trung — dữ liệu giao dịch (transactional data) như đơn hàng, log truy cập có thể sống phân tán trong nhiều hệ thống. Nhưng dữ liệu chủ — Customer, Product, Employee, Chart of Accounts — nếu không được xác lập rõ "hệ thống nào là nguồn phát hành, hệ thống nào chỉ được đọc/đồng bộ" thì sớm muộn cũng phân rã thành nhiều phiên bản sự thật.

Thứ ba, ai chịu trách nhiệm về chất lượng và vòng đời của từng loại dữ liệu? Đây là nguyên tắc data ownership (đôi khi gọi là data stewardship) — gán một business owner (không nhất thiết là IT) chịu trách nhiệm định nghĩa, phê duyệt thay đổi cấu trúc, và giám sát chất lượng cho từng domain dữ liệu. Không có ownership rõ ràng, mọi nguyên tắc kiến trúc dữ liệu đẹp trên giấy đều sẽ mục ruỗng trong vận hành thực tế vì không ai chịu trách nhiệm khi dữ liệu trôi lệch.

Điều quan trọng cần nhấn mạnh với các Solutions Architect đang chuyển hướng EA: Giai đoạn C Data Architecture không sinh ra từ chân không. Nó phải bắt nguồn trực tiếp từ những gì đã xác lập ở Giai đoạn B (Business Architecture) — cụ thể là Value Stream nào cần dữ liệu gì, Business Capability nào tiêu thụ và sản sinh dữ liệu gì. Nếu bỏ qua bước liên kết này, EA rất dễ rơi vào bẫy thiết kế mô hình dữ liệu "đẹp về mặt kỹ thuật" nhưng không phục vụ được nghiệp vụ thực.

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

TOGAF không áp đặt một phương pháp mô hình hóa dữ liệu duy nhất, nhưng cung cấp một bộ khung quyết định mà EA nên đi qua tuần tự khi thực hiện Data Architecture ở Giai đoạn C.

1. Xây dựng Conceptual Data Model từ Business Capability Model. Lấy đầu ra của bài 14 (Business Capability Model) làm điểm xuất phát: mỗi Capability tiêu thụ/tạo ra những "đối tượng thông tin" (information object) nào? Gom các đối tượng thông tin này lại, loại trùng lặp, ta có bộ thực thể dữ liệu khái niệm cấp doanh nghiệp.

2. Phân loại thực thể theo mức độ cần quản trị tập trung. Không phải entity nào cũng cần Master Data Management (MDM — chiến lược và công nghệ quản trị dữ liệu chủ tập trung, đảm bảo một nguồn sự thật duy nhất được đồng bộ ra các hệ thống tiêu thụ). Bảng phân loại tham khảo:

3. Gán data ownership theo domain. Với mỗi nhóm dữ liệu chủ, xác định: business owner (người chịu trách nhiệm định nghĩa nghiệp vụ), system of record (hệ thống lưu bản ghi gốc), và các system of reference (hệ thống chỉ tiêu thụ bản sao đồng bộ). Đây chính là nền tảng cho Data Governance sau này — nhưng ở Giai đoạn C, EA chỉ cần xác lập nguyên tắc, chưa cần vận hành quy trình governance đầy đủ (việc đó thuộc Giai đoạn G, sẽ bàn ở bài 20).

4. Thực hiện Gap Analysis giữa Baseline và Target Data Architecture. Baseline: khảo sát các hệ thống hiện tại đang lưu bản sao của thực thể nào, có bao nhiêu "phiên bản sự thật" đang tồn tại song song. Target: mô hình dữ liệu khái niệm tập trung đã thiết kế ở bước 1-3. Gap chính là danh sách các điểm phân mảnh cần xử lý — thường trở thành input trực tiếp cho Giai đoạn E (Migration Planning) dưới dạng các work package hợp nhất dữ liệu.

5. Đánh giá tác động đến Application Portfolio. Xác định ứng dụng nào cần được chỉ định là system of record, ứng dụng nào cần bổ sung cơ chế đồng bộ (API, event, batch ETL) để tiêu thụ dữ liệu chủ thay vì tự quản lý bản sao riêng. Đây là điểm giao thoa trực tiếp với nhánh Application Architecture của Giai đoạn C (bài 16).

Case thực tế minh hoạ

Lưu ý: đây là tình huống minh hoạ điển hình được tổng hợp từ các mẫu hình phổ biến trong doanh nghiệp vừa và lớn, không phải case của một công ty cụ thể có thật, không có số liệu định lượng cụ thể.

Một doanh nghiệp kinh doanh đa kênh (bán hàng trực tiếp, sàn thương mại điện tử, và đại lý) phát hiện ra rằng thông tin "khách hàng" tồn tại độc lập ở năm hệ thống: CRM (bộ phận Sales quản lý), hệ thống bán hàng tại cửa hàng POS, nền tảng thương mại điện tử, hệ thống kế toán/ERP, và công cụ email marketing. Mỗi hệ thống được triển khai ở một thời điểm khác nhau, bởi một đội khác nhau, với một mô hình "khách hàng" khác nhau — CRM định nghĩa khách hàng theo cơ hội bán hàng, ERP định nghĩa theo hợp đồng có hiệu lực, nền tảng email định nghĩa theo địa chỉ email đã đăng ký (kể cả chưa từng mua hàng).

Hậu quả không dừng ở việc đếm sai số lượng khách hàng. Một khách hàng đổi số điện thoại ở CRM nhưng thông tin cũ vẫn còn trong ERP khiến bộ phận thu hồi công nợ liên hệ nhầm; chương trình khuyến mãi sinh nhật gửi trùng ba lần vì ba hệ thống marketing lấy dữ liệu từ ba nguồn khác nhau; và nghiêm trọng nhất, báo cáo doanh thu theo khách hàng ở buổi họp ban điều hành liên tục bị chất vấn vì con số không khớp giữa phòng Kinh doanh và phòng Tài chính, làm giảm niềm tin vào toàn bộ hệ thống báo cáo.

Khi EA vào cuộc ở Giai đoạn C, việc đầu tiên không phải là chọn công nghệ MDM, mà là hội thảo với các business owner để thống nhất một Conceptual Data Model cho thực thể "Customer" — bao gồm định nghĩa nghiệp vụ chung (khách hàng là ai, một khách hàng có thể có nhiều liên hệ/địa chỉ giao hàng ra sao, thế nào là "khách hàng active"), rồi mới đến quyết định kiến trúc: hệ thống CRM được chỉ định là system of record cho hồ sơ khách hàng gốc; các hệ thống còn lại chuyển sang mô hình đồng bộ một chiều từ CRM thông qua một tầng tích hợp trung tâm, thay vì tự nhập liệu độc lập. Kết quả kiến trúc là một chiến lược dữ liệu tập trung có phân tầng rõ ràng: một nguồn sự thật cho dữ liệu chủ, các hệ thống vệ tinh chỉ tiêu thụ, và một cơ chế đối soát định kỳ để phát hiện lệch pha sớm — thay vì chờ đến khi báo cáo sai mới phát hiện.

📐 Template/Artifact áp dụng ngay

Master Data Entity Catalog — artifact chuẩn TOGAF cho Giai đoạn C, dùng để chốt quyết định kiến trúc dữ liệu với các business owner trong một buổi làm việc:

Cách dùng: điền một dòng cho mỗi thực thể dữ liệu chủ đã xác định ở bước Conceptual Data Model; cột "Ghi chú Gap" chính là input trực tiếp cho Gap Analysis và sau đó chuyển thành work package ở Giai đoạn E.

🎯 Góc nhìn Chief EA

Nếu ngày mai có ba báo cáo khác nhau về cùng một con số kinh doanh cốt lõi, tôi có thể chỉ ra ngay hệ thống nào là system of record hay không? Danh sách Master Data Entity của tổ chức tôi có được business owner (không phải IT) ký xác nhận, hay chỉ tồn tại trong đầu một vài kỹ sư? Khi một hệ thống mới được đề xuất mua/xây, quy trình kiến trúc có bắt buộc kiểm tra "entity nào trong hệ thống này trùng với Master Data đã có" trước khi phê duyệt không? Và nếu phải chọn một entity duy nhất để dọn dẹp trong quý này, đó có phải là entity đang gây thiệt hại kinh doanh lớn nhất — hay chỉ là entity dễ làm nhất?

🔄 Vị trí trong chu trình ADM

Giai đoạn C (Data Architecture) không đứng độc lập — nó là một mắt xích trong chu trình ADM tuần hoàn, nhận đầu vào có kiểm soát và tạo đầu ra có kiểm soát:

• Nhận đầu vào từ: Business Architecture (Giai đoạn B, bài 13-14) — dữ liệu nào cần thiết được xác định từ Value Stream/Capability. EA không được phép thiết kế mô hình dữ liệu trước khi biết nghiệp vụ nào tiêu thụ nó; làm ngược thứ tự này là nguyên nhân phổ biến nhất khiến kiến trúc dữ liệu trở thành bài tập lý thuyết xa rời thực tế vận hành.
• Cho đầu ra sang: Giai đoạn D (Technology Architecture, bài 17) — kiến trúc dữ liệu quyết định yêu cầu hạ tầng lưu trữ/xử lý. Khối lượng dữ liệu chủ cần đồng bộ real-time hay batch, mức độ nhạy cảm cần mã hoá/phân quyền ra sao, quy mô tăng trưởng dự kiến — tất cả trở thành ràng buộc thiết kế cho tầng công nghệ ở Giai đoạn D.

Ngoài ra, Data Architecture ở Giai đoạn C còn song hành chặt chẽ với Application Architecture (cũng thuộc Giai đoạn C, bài 16) — vì quyết định "hệ thống nào là system of record" thực chất là một quyết định kiến trúc ứng dụng, không thể tách rời khỏi quyết định kiến trúc dữ liệu.

🔗 Bài viết liên quan

• Giai đoạn B (Business Capability) — nguồn xác định thực thể dữ liệu nào thực sự cần thiết cho nghiệp vụ, tránh mô hình hoá dữ liệu tách rời khỏi Capability.
• Giai đoạn C (Application) — nhánh song song của Giai đoạn C, nơi quyết định system of record được hiện thực hoá thành kiến trúc ứng dụng cụ thể.

Bài trước: Giai đoạn B (Business Capability) · Bài tiếp theo: Giai đoạn C (Application)