Mục tiêu
- Xác định rõ app nguồn (source of truth) cho từng loại dữ liệu
- Chọn cách chia sẻ phù hợp: publish/consume hoặc Data Connection
- Biết khi nào dùng one-way và khi nào (hiếm) cần two-way
- Tránh các lỗi phổ biến: vòng lặp đồng bộ, dữ liệu mâu thuẫn, trách nhiệm không rõ
Ownership dữ liệu là gì?
Ownership trả lời câu hỏi: “Ai chịu trách nhiệm tính đúng, đủ, và vòng đời của dữ liệu này?” Trong hệ thống nhiều app, ownership thường được gắn với:- một đơn vị chịu trách nhiệm (Procurement, Finance, HR…)
- một app nguồn (nơi dữ liệu được tạo/cập nhật chính)
- các app tiêu thụ (chỉ đọc hoặc cập nhật phần được uỷ quyền)
Ownership rõ ràng giúp đơn giản hoá phân quyền, giảm tranh chấp dữ liệu và giảm chi phí thay đổi.
Nguyên tắc Source of truth (nguồn dữ liệu chuẩn)
Mỗi loại dữ liệu nên có một nguồn chính:- Dữ liệu “yêu cầu” → thường thuộc app nơi yêu cầu được tạo và theo dõi
- Dữ liệu “xử lý nghiệp vụ chuyên môn” → thường thuộc app của bộ phận xử lý (ví dụ Procurement xử lý PO)
- Dữ liệu “danh mục chuẩn” → thường thuộc app master/reference (nếu có)
- phiên bản không nhất quán (conflicting truth)
- khó audit (không biết ai đổi)
- khó thiết kế workflow và permissions
Cách chia sẻ dữ liệu giữa các app
1) Publish / Consume (khuyến nghị mặc định)
Cơ chế chia sẻ theo hướng:- App nguồn publish dữ liệu (một tập field/record được phép chia sẻ)
- App khác consume dữ liệu để sử dụng trong UI/workflow của mình
- Làm rõ ownership (ai publish là nguồn)
- Giảm coupling (consumer không cần “chạm” vào toàn bộ mô hình dữ liệu nguồn)
- Dễ kiểm soát quyền và phạm vi chia sẻ
- Kết nối giữa các app theo kiểu handoff (bàn giao)
- Các app có ownership khác nhau
- Cần chia sẻ đọc (read-mostly) hoặc chia sẻ có kiểm soát
2) Data Connection fields (liên kết dữ liệu)
Liên kết record giữa entity/app để tham chiếu dữ liệu. Ưu điểm- Thao tác liên kết trực tiếp theo record
- Phù hợp cho các quan hệ dữ liệu rõ ràng
- Dễ tạo coupling nếu dùng không kiểm soát
- Dễ “đẩy” người dùng sang app khác để sửa dữ liệu nguồn
- Kết nối dữ liệu một chiều (Data Connection one-way)
- Kết nối dữ liệu hai chiều (Data Connection two-way)
One-way vs Two-way: quy tắc quyết định
One-way (khuyến nghị)
Một chiều nghĩa là:- dữ liệu chảy theo một hướng: nguồn → tiêu thụ
- consumer không sửa dữ liệu nguồn (hoặc chỉ sửa phần được uỷ quyền thông qua cơ chế rõ ràng)
- Hầu hết trường hợp handoff giữa bộ phận
- Trạng thái/thuộc tính thuộc ownership của app nguồn
- Mục tiêu là “xem để làm việc tiếp” hoặc “xem để theo dõi”
Two-way (chỉ dùng khi cần, có điều kiện)
Hai chiều nghĩa là:- cả hai phía có thể cập nhật một phần dữ liệu và cần phản chiếu lẫn nhau
- ownership được định nghĩa theo “phân vùng field” (field ownership rõ)
- quy tắc đồng bộ và xử lý xung đột đã rõ
- có lý do nghiệp vụ thực sự (không chỉ vì tiện)
- “Ai cũng có thể sửa mọi thứ”
- “Cứ đồng bộ cho chắc”
- “Chưa rõ ai chịu trách nhiệm khi dữ liệu sai”
Thiết kế chia sẻ dữ liệu theo từng câu hỏi
- Dữ liệu thuộc về ai? (đơn vị chịu trách nhiệm)
- Nguồn được tạo/cập nhật ở đâu? (app nguồn)
- App khác cần dùng dữ liệu để làm gì? (chỉ đọc, tham chiếu, hay cập nhật phần được uỷ quyền)
- Chỉ số và audit cần theo dõi gì? (ai đổi, đổi khi nào, theo bước nào)
- Độ nhạy dữ liệu và policy truy cập (ai được xem/sửa)
Ví dụ: Purchase Request và Procurement
Mô hình ownership đề xuất
- App Purchase Request (nguồn): sở hữu dữ liệu yêu cầu (mục đích, mô tả, chi phí dự kiến, trạng thái phê duyệt)
- App Procurement (nguồn): sở hữu dữ liệu xử lý mua sắm (PO, nhà cung cấp, trạng thái đặt hàng/nhận hàng)
Chia sẻ theo publish/consume (đề xuất)
- Purchase Request publish các yêu cầu đã được phê duyệt (các field cần cho procurement)
- Procurement consume để tạo/điều phối công việc mua sắm
- Procurement publish trạng thái xử lý (read-only cho requester theo dõi)
- Purchase Request consume để hiển thị tiến độ cho người yêu cầu
- ownership rõ, mỗi app tập trung đúng “phần việc”
- dữ liệu không bị sửa chéo
- UI của mỗi nhóm người dùng đơn giản hơn
Anti-patterns cần tránh
- Nhập lại dữ liệu giữa các app thay vì kết nối qua publish/consume + connected app (kết nối ứng dụng) (dẫn đến lệch dữ liệu)
- Two-way mặc định cho mọi liên kết
- Không có app nguồn: nhiều app cùng sửa cùng record
- Chia sẻ quá rộng: publish “tất cả mọi thứ” thay vì publish đủ dùng
- Không có policy: ai cũng xem/sửa dữ liệu nhạy cảm
Bước tiếp theo
- Ra quyết định controls: Controls trong hệ thống (workflow vs validation vs roles)
- Áp dụng trong delivery loop: Inner loop: delivery cycle (chu kỳ triển khai)
- Cấu hình tính năng: Cổng dữ liệu (Data source)