Một nguồn sự thật cho mỗi thuộc tính
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 1 trong 6 của chương Dữ liệu chủ và danh tính, chương 6 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Tiếp theo: Bốn cách quản lý dữ liệu chủ
Câu hỏi mô-đun này trả lời: “Nguồn sự thật duy nhất” thực sự có nghĩa là gì?
Có một câu tôi nghe liên tục: “Chúng ta cần một nguồn sự thật duy nhất.” Được. Cho cái gì? Khách hàng? Như vậy chưa đủ cụ thể. Lấy một tài khoản. Ai sở hữu tên khách hàng, địa chỉ thanh toán, hạn mức tín dụng, giám đốc khách hàng, hạng hỗ trợ, lựa chọn marketing? Những câu trả lời đó không chỉ về cùng một hệ thống. ERP có thể kiểm soát tên pháp lý, địa chỉ thanh toán và tình trạng tín dụng; Salesforce kiểm soát người phụ trách quan hệ và các thuộc tính bán hàng; một nền tảng khác kiểm soát sự đồng ý. Vì vậy khi ai đó nói với tôi “Salesforce là nguồn sự thật duy nhất của chúng tôi về khách hàng”, câu hỏi tiếp theo của tôi là: sự thật nào?
Sự thật thuộc về một thuộc tính
Phần tiêu đề “Sự thật thuộc về một thuộc tính ”Nguyên tắc đầu tiên của dữ liệu chủ là thế này: thẩm quyền được giao theo từng thuộc tính, không theo từng bản ghi. Một tài khoản có thể sống trong Salesforce mà Salesforce không có thẩm quyền đối với mọi trường trên nó. Bảy trường trên một bản ghi, hai bên có thẩm quyền:
| Thuộc tính | Hệ thống có thẩm quyền |
|---|---|
| Tên pháp lý, địa chỉ thanh toán, ID khách hàng ERP, hạn mức tín dụng | ERP |
| Giám đốc khách hàng, cờ tài khoản chiến lược, hạng thành công | Salesforce |
Một bản ghi; sự thật được phân tán. Điều đó bình thường. “Hệ thống gốc = Salesforce” không mô tả được nó. Một mô hình thẩm quyền thì mô tả được.
Được tạo, được sửa, được tham chiếu, và nhanh đến đâu?
Phần tiêu đề “Được tạo, được sửa, được tham chiếu, và nhanh đến đâu? ”Khi dạy về dữ liệu chủ, tôi cứ quay lại cùng những câu hỏi cho mỗi mẩu dữ liệu quan trọng: nó được tạo ở đâu, được sửa ở đâu, được tham chiếu ở đâu, và độ trễ thay đổi của nó là bao nhiêu? Chúng phơi bày kiến trúc rất nhanh. (Bạn đã gặp ba câu hỏi đầu ở chương 4, khi phân loại các loại dữ liệu; đây là nơi chúng thực sự phát huy tác dụng.)
Lấy một tài sản làm ví dụ. Một khách hàng đặt mua ba chiếc xe đạp. Salesforce có cơ hội và các mục dòng của nó, và đơn hàng được chuyển sang ERP. ERP thực hiện đơn hàng, và đó là nơi các tài sản được tạo: ba chiếc xe đạp, ba số sê-ri, được gửi về Salesforce. Vài tháng sau, khách hàng gọi đến về một chiếc trong số đó, và bộ phận hỗ trợ tham chiếu tài sản đó trong một trường hợp. Giờ ai đó cần sửa một thuộc tính. Salesforce được sửa những thuộc tính nào, và những thuộc tính nào thuộc về ERP, nơi đã tạo ra chúng? Và khi ERP thay đổi một thuộc tính, Salesforce cần biết nhanh đến mức nào? Một tài sản, bốn câu hỏi, và câu trả lời không giống nhau cho mọi trường.
Giả sử tên pháp lý được tạo trong ERP và được tham chiếu trong Salesforce, và một nhân viên kinh doanh nhận ra nó sai. Họ có nên sửa nó trong Salesforce không? Nếu ERP sở hữu trường đó, sửa bản sao chẳng sửa được gì. Tốt nhất là lần đồng bộ tiếp theo ghi đè lên nó; tệ nhất là hai hệ thống giờ bất đồng và không ai biết nên tin bên nào. Nếu nghiệp vụ muốn nhân viên kinh doanh khởi động việc sửa, thì đó là chuyện khác: Salesforce cung cấp trải nghiệm, gửi một yêu cầu đến ERP, ERP thực hiện hoặc phê duyệt thay đổi, và giá trị có thẩm quyền quay về. Đó là một kiến trúc rất khác so với việc để Salesforce tự sửa trường.
Độ trễ cũng là một phần của sự thật. ERP thay đổi tình trạng tín dụng của một khách hàng lúc 10 giờ sáng; Salesforce đồng bộ hằng đêm; lúc 3 giờ chiều một nhân viên kinh doanh nhìn vào Salesforce. Giá trị đó có sai không? Nó đã cũ. Nếu giá trị thay đổi mỗi năm một lần và chậm một ngày chẳng tốn gì, đồng bộ hằng đêm là ổn. Nếu nó quyết định bạn có nhận một đơn hàng một triệu đô la hôm nay hay không, thì không ổn. Thẩm quyền cho biết sự thật đến từ đâu; độ trễ cho biết các bên khác phải biết nó thay đổi nhanh đến đâu. Hai quyết định riêng biệt.
Hệ thống gốc, tương tác, tham chiếu
Phần tiêu đề “Hệ thống gốc, tương tác, tham chiếu ”Từ vựng của chương 4 giúp ích ở đây. Một hệ thống gốc duy trì phiên bản có thẩm quyền. Một hệ thống tương tác là nơi con người làm việc với nó. Một hệ thống tham chiếu cung cấp dữ liệu mà hệ thống khác dùng nhưng không sở hữu. Salesforce có thể là hệ thống tương tác cho quan hệ khách hàng trong khi ERP vẫn là hệ thống gốc cho các thuộc tính pháp lý và tài chính của nó. Đó không phải là điểm yếu của kiến trúc; nó chính là kiến trúc. Sai lầm là giả vờ rằng một hệ thống phải sở hữu mọi thứ để sơ đồ trông đơn giản hơn.
Bản ghi vàng lai
Phần tiêu đề “Bản ghi vàng lai ”Điều đó thay đổi ý nghĩa của “bản ghi vàng”. Chương 5 đã giới thiệu ý tưởng này khi nói về việc ngăn dữ liệu xấu; ở đây nó là trái tim của thiết kế. Người ta hình dung một bản ghi thần kỳ với mọi trường được quản lý chủ ở một chỗ. Đôi khi đó là thiết kế. Trên Salesforce, tôi thường thấy hơn một bản ghi lai: một phần của tài khoản được quản lý chủ ở nơi khác và sao chép vào (tên pháp lý, mã khách hàng ERP, địa chỉ thanh toán, tình trạng tín dụng), và một phần chỉ tồn tại vì Salesforce cần nó (giám đốc khách hàng, chiến lược cơ hội, hạng thành công, ghi chú quan hệ). Các trường ERP đi vào để người ta dùng được. Các trường Salesforce không bao giờ quay về, vì ERP không quan tâm đến chúng. Hoàn toàn hợp lý, miễn là mọi người biết cái nào là cái nào.
Làm cho thẩm quyền hiện rõ
Phần tiêu đề “Làm cho thẩm quyền hiện rõ ”Vì vậy tôi làm cho thẩm quyền bên ngoài hiện rõ trong lược đồ. Nếu SAP kiểm soát một trường, nó có một tiền tố: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Cùng ý tưởng với tiền tố erp_ của chương 4. Hãy dùng tên hệ thống khi thẩm quyền đó cụ thể và ổn định, và một tiền tố chung khi ý nghĩa quan trọng hơn nhà cung cấp của hôm nay. Điểm mấu chốt là sáu tháng sau, ai đó đọc mô hình có thể thấy: đây không chỉ là một trường Salesforce nữa; một hệ thống khác sở hữu giá trị này. Đừng bắt người ta phải khám phá lại thẩm quyền bằng cách mổ xẻ ngược các tích hợp.
Xây một bản đồ thẩm quyền
Phần tiêu đề “Xây một bản đồ thẩm quyền ”Với dữ liệu chủ quan trọng, tôi muốn một bản đồ thẩm quyền: với mỗi thuộc tính then chốt, ai tạo ra nó, ai sở hữu quyết định nghiệp vụ, hệ thống nào có thẩm quyền, và ai hay cái gì được thay đổi nó. Bốn câu hỏi khác nhau:
| Thuộc tính | Được tạo bởi | Chủ sở hữu nghiệp vụ | Hệ thống có thẩm quyền | Được thay đổi bởi |
|---|---|---|---|---|
| Tên pháp lý | Tài chính | Tài chính | ERP | Quy trình tài chính |
| Hạn mức tín dụng | Tài chính | Tài chính | ERP | Đội tín dụng |
| Giám đốc khách hàng | Vận hành kinh doanh | Kinh doanh | Salesforce | Quản lý kinh doanh |
| Hạng hỗ trợ | Vận hành dịch vụ | Dịch vụ | Salesforce | Quản lý dịch vụ |
| Sự đồng ý | Khách hàng | Quyền riêng tư | Nền tảng đồng ý | Khách hàng, một quy trình đã phê duyệt |
Để ý rằng chủ sở hữu nghiệp vụ và hệ thống có thẩm quyền không phải là một. Một hệ thống không sở hữu chính sách; con người mới sở hữu. Hệ thống lưu trữ và thực thi kết quả. Đó lại là chương 5: chủ sở hữu đặt chính sách; kiến trúc sư thực thi nó.
Một khách hàng. Nhiều thuộc tính. Mỗi thuộc tính một thẩm quyền.
Thẩm quyền thay đổi theo vòng đời
Phần tiêu đề “Thẩm quyền thay đổi theo vòng đời ”Một nhân viên kinh doanh gặp một khách hàng tiềm năng mà ERP chưa từng nghe đến và tạo tài khoản trong Salesforce. Lúc đó Salesforce có thẩm quyền đối với tên, địa chỉ, liên hệ và việc đánh giá. Khách hàng tiềm năng trở thành khách hàng; ERP tạo khách hàng chính thức và cấp mã khách hàng, tên pháp lý, địa chỉ thanh toán và tín dụng. Thẩm quyền đã chuyển đi. Salesforce trước đó không sai; vòng đời đã thay đổi. Đó là khuôn mẫu từ tạm thời đến được quản trị của chương 5: trước khi chuyển đổi, Salesforce sở hữu khách hàng tiềm năng; sau đó, ERP sở hữu các thuộc tính được quản trị, và Salesforce tiếp tục sở hữu các thuộc tính của riêng nó. Vì vậy “hệ thống nào sở hữu tài khoản?” là một câu hỏi yếu. Hãy hỏi: hệ thống nào sở hữu thuộc tính này, ở thời điểm này trong vòng đời?
Một bản sao không phải là thẩm quyền
Phần tiêu đề “Một bản sao không phải là thẩm quyền ”Chúng ta sao chép dữ liệu ERP vào Salesforce vì người ta cần nó liên tục. Điều đó biến Salesforce thành một bản sao tại chỗ tiện lợi, không phải bên quản lý chủ, và kiến trúc nên hành xử tương ứng: chỉ đọc với người dùng, được tích hợp làm mới, ghi nhãn nguồn, chỉ thay đổi qua một yêu cầu, được kiểm tra bằng đối chiếu khi bản sao bị lệch. Bản sao có ích. Thẩm quyền thì không di chuyển.
Sự tin cậy cần nhiều hơn một giá trị
Phần tiêu đề “Sự tin cậy cần nhiều hơn một giá trị ”“Địa chỉ thanh toán: 123 Main Street.” Bạn có nên tin nó không? Tôi muốn có tín hiệu tin cậy: nó đến từ đâu, nó được xác nhận lần cuối khi nào, hệ thống nào cung cấp nó, và ai hay cái gì đã thay đổi nó lần cuối: một người, một tích hợp, một tác tử? Giờ ERP nói 123 Main Street, Salesforce nói 125, và một tệp đối tác nói “123 Main St., Suite 200”. Cái nào đúng? Đừng trả lời “dùng cái mới nhất”. Có thể. Nhưng “mới nhất” tự nó là một quy tắc giả định rằng bên thay đổi cuối cùng xứng đáng thắng. Điều đó có thể đúng, hoặc tệ hại. Mô-đun 3 sẽ giải quyết chuyện này. Sự tin cậy đến từ thẩm quyền và nguồn gốc, không phải từ việc tìm được một trường đã được điền.
Steve Trucking: sự thật của ai?
Phần tiêu đề “Steve Trucking: sự thật của ai? ”Một Đối tác bán lẻ gửi một lần giao hàng, và nhiều sự thật ẩn trong một giao dịch đó. Mã tham chiếu đơn hàng của đối tác là của đối tác; Steve Trucking giữ nó để khớp các bản cập nhật, nhưng không trở thành bên quản lý chủ của nó. Trạng thái giao hàng (đã đến, đã giao, đã lắp đặt, ngoại lệ) là của Steve Trucking; đối tác nhận nó, nhưng nhận một trạng thái không làm cho đối tác có thẩm quyền về những gì đã xảy ra trên xe tải. Và Người nhận là khách hàng của đối tác. Đối tác cung cấp tên, địa chỉ, điện thoại và ghi chú giao hàng vì Steve Trucking cần chúng để giao hàng. Điều đó không biến Steve Trucking thành bên quản lý chủ danh tính của người đó, và sự phân biệt đó quyết định thiết kế Người nhận ở điểm kiểm tra.
Một lần giao hàng, hai thẩm quyền.
Dữ liệu nằm ở đâu và ai sở hữu sự thật của nó là hai câu hỏi khác nhau. Salesforce có thể giữ mã khách hàng ERP mà không sở hữu nó; Snowflake có thể giữ trạng thái giao hàng mà không phải bên quản lý chủ vận hành của nó; một nền tảng dữ liệu khách hàng có thể hợp nhất danh tính mà không sở hữu mọi thuộc tính. Một tác tử có thể đọc cả ba, và điều đó chắc chắn không cho phép tác tử quyết định cái nào là đúng.
Ngoài kỳ thi: AI thay đổi điều gì. Tác tử biến thẩm quyền theo thuộc tính thành một quy tắc thực thi. Một người thấy địa chỉ thanh toán sai và biết “cái đó đến từ SAP; tôi không nên sửa nó ở đây”. Một tác tử được bảo “cập nhật địa chỉ thanh toán của khách hàng” sẽ không biết, trừ khi chúng ta thiết kế cho điều đó. Nó cần cùng bản đồ thẩm quyền mà kiến trúc sư có: có quyền truy cập một trường không biến trường đó thành đúng chỗ để ghi.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Hệ thống nào có thẩm quyền cho từng thuộc tính quan trọng, thay vì một hệ thống cho cả một bản ghi.
- Mỗi thuộc tính được tạo, sửa và tham chiếu ở đâu, và các thay đổi của nó phải đi nhanh đến đâu.
- Ai đặt chính sách cho từng thuộc tính, và những người, tích hợp hay tác tử nào được thay đổi nó.
- Thẩm quyền bên ngoài thể hiện trong mô hình thế nào: tiền tố đặt tên, quyền, hành vi tích hợp.
- Thẩm quyền dịch chuyển thế nào theo vòng đời, chẳng hạn một khách hàng tiềm năng trở thành khách hàng được ERP quản trị.
Một nguồn sự thật duy nhất không có nghĩa là một org, một ERP, một nền tảng MDM hay một bản ghi khổng lồ. Nó có nghĩa là với mỗi mẩu thông tin được quản trị, kiến trúc nói được giá trị có thẩm quyền nằm ở đâu, và mọi hệ thống khác biết cách hành xử nhờ điều đó. Đó không phải là một nguồn sự thật duy nhất. Đó là một kiến trúc của sự thật.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.