Các hệ thống quanh Salesforce

🌐 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)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 3 trong 6 của chương Hiểu dữ liệu doanh nghiệp, chương 4 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Các loại dữ liệu doanh nghiệp · Tiếp theo: Vẽ bản đồ hệ thống

Câu hỏi mô-đun này trả lời: Những gì bao quanh Salesforce, và mỗi hệ thống đóng vai trò gì?

Mô-đun trước đã phân loại dữ liệu. Giờ tôi muốn đặt nó vào đâu đó, và đây là chỗ các kiến trúc sư Salesforce gặp rắc rối. Chúng ta biết Salesforce, nên dữ liệu khách hàng nghĩa là Tài khoản, dữ liệu đơn hàng nghĩa là Order, tài liệu nghĩa là Files, phân tích nghĩa là Reports. Nhưng doanh nghiệp không mua Salesforce để thay thế mọi thứ khác họ sở hữu. Có thể có một ERP vận hành tài chính và thực hiện đơn hàng, một kho dữ liệu với nhiều năm lịch sử, một nền tảng tích hợp, một nhà cung cấp danh tính, các hệ thống đối tác, một nền tảng sự kiện, một nền tảng MDM, và Data 360 kết nối nhiều hệ thống trong số đó. Công việc không phải là thuộc lòng các công nghệ. Mà là hiểu mỗi hệ thống có nhiệm vụ gì.

Đừng bắt đầu từ tên sản phẩm

“Chúng tôi có SAP” không cho tôi biết đủ. Snowflake, MuleSoft, Tableau hay Data 360 cũng vậy. Tôi muốn biết hệ thống đó làm gì trong kiến trúc này: nó sở hữu dữ liệu gì, nó đọc gì, nó thay đổi gì, ai dùng nó, cái gì phụ thuộc vào nó, chuyện gì xảy ra khi nó ngừng hoạt động. Hai công ty có thể sở hữu chính xác cùng các sản phẩm mà có kiến trúc hoàn toàn khác nhau.

Vì vậy tôi gán nhãn hệ thống theo vai trò. Bốn vai trò bao quát gần hết:

• Hệ thống gốc: nơi duy trì phiên bản có thẩm quyền của một thứ.
• Hệ thống tương tác: nơi con người làm việc.
• Hệ thống tham chiếu: nơi một hệ thống tìm đến thông tin nó cần nhưng không sở hữu.
• Hệ thống phân tích: nơi dữ liệu được gom lại để đo lường, phân tích và dự đoán.

Một nền tảng có thể đóng nhiều vai trò, và vai trò khác nhau theo dữ liệu. Salesforce có thể là hệ thống gốc cho các trường hợp, hệ thống tương tác cho nhân viên dịch vụ, và là bên tiêu thụ dữ liệu sản phẩm mà ERP sở hữu. Vì vậy khi ai đó nói “Salesforce là hệ thống gốc của chúng tôi”, hãy hoàn thành câu đó: hệ thống gốc cho cái gì?

ERP: bộ phận hậu cần có lực hấp dẫn

ERP là hệ thống bạn sẽ thấy cạnh Salesforce thường xuyên nhất, vận hành tài chính, tồn kho, mua hàng, thực hiện đơn hàng và lập hóa đơn. Khuôn mẫu của mô-đun 1 (khách hàng và sản phẩm vào, đơn hàng ra) nghĩa là ERP sở hữu sản phẩm, nhưng nhân viên kinh doanh vẫn cần chúng trong Salesforce. Được thôi: đưa chúng vào. Nhưng sao chép dữ liệu không chuyển giao quyền sở hữu. Một bản sao không phải là thẩm quyền.

Lập trường của tôi: dữ liệu do ERP sở hữu được đọc tại chỗ và ghi có kiểm soát. Người dùng Salesforce có dữ liệu ngay nơi họ làm việc, nhưng Salesforce không được thay đổi những gì ERP sở hữu. Và tôi làm cho điều đó hiện rõ trong lược đồ: các trường của ERP mang tiền tố erp_, như erp_Product_Number__c, để bất kỳ ai đọc đối tượng đều biết ai sở hữu từng trường và cẩn thận khi thay đổi nó. Tiền tố không thực thi gì cả; quyền, quy tắc xác thực và mẫu tích hợp mới làm việc đó. Nó truyền đạt ý định, và nó là bản đồ thẩm quyền được làm cho hiện rõ.

Kho dữ liệu, hồ dữ liệu và lakehouse

Hệ thống vận hành điều hành doanh nghiệp; hệ thống phân tích giúp hiểu doanh nghiệp. “Cho tôi xem các cơ hội đang mở của tôi” là một báo cáo Salesforce. “Cho tôi xem năm năm doanh số, thực hiện đơn hàng, hàng trả lại, trường hợp, tồn kho và tài chính trên mọi kênh” là một bài toán khác.

Bạn sẽ gặp ba loại kho phân tích. Một kho dữ liệu (data warehouse) giữ dữ liệu có cấu trúc đã được chuẩn bị cho phân tích. Một hồ dữ liệu (data lake) giữ nhiều dữ liệu hơn hẳn ở nhiều dạng hơn, thường là thô. Một lakehouse kết hợp cả hai: lưu trữ kiểu hồ với phân tích kiểu kho. Hãy biết chúng, vì chúng xuất hiện trên bản đồ hệ thống. Nhưng kinh nghiệm của tôi là lakehouse và data mesh vẫn còn hiếm trong các dự án Salesforce. Bản đồ điển hình là CRM, ERP, một kho dữ liệu và một tầng tích hợp, với các nền tảng khác ở nơi doanh nghiệp thực sự cần. Hãy học kiến trúc; đừng chạy theo từ vựng.

Phân tích nằm ở nơi dữ liệu nằm

Đây là một trong những lập trường vững chắc nhất của tôi: phân tích nằm ở đâu đi theo dữ liệu nằm ở đâu. Nếu báo cáo chỉ cần tài khoản, cơ hội và nhân viên kinh doanh, tất cả đều ở trên lõi: báo cáo và bảng điều khiển chuẩn. Rồi nghiệp vụ yêu cầu thêm hóa đơn từ ERP. Rồi giá vốn sản phẩm. Rồi năm năm đơn hàng từ kho dữ liệu. Rồi hoạt động trên website. Đến một lúc nào đó, kéo tất cả những thứ đó vào CRM vận hành chỉ để báo cáo không còn hợp lý nữa. Một khi có các kho dữ liệu khác tham gia, một nền tảng phân tích trở nên cần thiết: Tableau (bao gồm Tableau Next, xây trên Data 360), hoặc CRM Analytics ở nơi đã dùng sẵn. Nó là thiết yếu khi dữ liệu Salesforce được trộn với một kho dữ liệu. Yêu cầu không chỉ trở nên phức tạp hơn; bản đồ hệ thống đã thay đổi nơi câu hỏi nên được trả lời. Vì vậy tôi không bao giờ bắt đầu với “công cụ phân tích nào?” Tôi bắt đầu với dữ liệu ở đâu?

Tôi hỏi các ứng viên CTA cùng một điều: “Sơ đồ nào của tôi giải quyết chuyện này thật đẹp? Bản đồ hệ thống.” Nếu mọi thứ đều ở trên lõi, hãy dùng báo cáo. Nếu bạn có dữ liệu ở các kho khác, tôi muốn thấy một nền tảng phân tích. Bản đồ hệ thống trả lời câu hỏi báo cáo trước khi bất kỳ ai mở trình tạo báo cáo. (Tên sản phẩm thay đổi; chương Data 360 trình bày vị trí hiện nay của mảng phân tích của Salesforce.)

MDM: khách hàng này thực sự là ai?

Giờ giả sử thông tin khách hàng nằm trong Salesforce, ERP, thương mại điện tử, một nền tảng khách hàng thân thiết và một hệ thống đối tác, và mỗi hệ thống đều nghĩ nó biết khách hàng là ai. Đó là lúc quản lý dữ liệu chủ (MDM) xuất hiện: thiết lập và quản trị danh tính có thẩm quyền của dữ liệu then chốt giữa các hệ thống. Nhưng MDM không phải là “một cơ sở dữ liệu khách hàng chủ”. Những câu hỏi khó là hệ thống nào được tạo khách hàng, mỗi hệ thống sở hữu thuộc tính nào, bản trùng được tìm ra thế nào, mã định danh nào được giữ lại, và chuyện gì xảy ra khi các hệ thống bất đồng. Chương 6 dành trọn cho điều đó. Ở đây, hãy nhận ra vai trò: nếu có một nền tảng MDM, nó có thể là một bên có thẩm quyền then chốt giữa Salesforce và phần còn lại của doanh nghiệp.

Tầng tích hợp và các sự kiện

Nối trực tiếp mọi hệ thống với mọi hệ thống khác, và bản đồ hệ thống nhanh chóng biến thành mì spaghetti. Đó là lý do các doanh nghiệp có một tầng tích hợp: một ESB (enterprise service bus) hoặc iPaaS (integration platform as a service). MuleSoft là cái bạn sẽ gặp nhiều nhất trong bản đồ Salesforce. Nó làm trung gian, để mỗi ứng dụng không phải hiểu mọi ứng dụng khác.

Nhưng một hộp MuleSoft ở giữa không làm cho tích hợp trở nên tốt. Tôi vẫn muốn biết cái gì đi qua nó và cái gì không, ai chuyển đổi dữ liệu, ai sở hữu hợp đồng, chuyện gì xảy ra khi đích đến ngừng hoạt động, nó đồng bộ hay bất đồng bộ, và làm sao biết một thông điệp đã thành công. Khóa Integration Architect đi sâu; ở đây, hãy nhận ra nó là một vai trò riêng.

Và không phải tích hợp nào cũng là hệ thống A gọi hệ thống B. Đôi khi có điều gì đó xảy ra (một đơn hàng được tạo, một lần giao hàng đổi trạng thái, một xe tải đi vào một khu vực), một sự kiện được phát đi, và bên nào quan tâm sẽ phản hồi. Sự kiện đang chuyển động cũng có hạ tầng: năng lực sự kiện của chính Salesforce, một bus sự kiện doanh nghiệp, các hệ thống nhắn tin khác. Hãy vẽ các cơ chế mang dữ liệu, không chỉ các cơ sở dữ liệu.

Hệ thống mà lập trình viên hay quên: danh tính

Có một hộp tôi luôn muốn có trên bản đồ hệ thống mà lập trình viên hiếm khi nghĩ tới: nhà cung cấp danh tính. Lập trình viên đăng nhập thẳng vào sandbox bằng tên người dùng và mật khẩu, nên danh tính vô hình trong lúc xây dựng. Rồi đến UAT hay môi trường thật, và bỗng nhiên có đăng nhập một lần (single sign-on) của công ty cho nhân viên, có thể một nhà cung cấp thứ hai cho đối tác, đăng nhập bằng mạng xã hội cho khách hàng. Danh tính luôn là một phần của kiến trúc. Chỉ là lập trình viên chưa thấy nó.

Một nhà cung cấp danh tính (IdP) là hệ thống xác thực người dùng và thiết lập danh tính mà Salesforce tin tưởng. Nó thuộc về bản đồ hệ thống từ ngày đầu tiên, dù nó được cấu hình muộn hơn trong quy trình phát hành, vì ai vào được quyết định ai tiếp cận được dữ liệu.

Còn một chi tiết thực tế nữa: cấu hình danh tính triển khai được, nhưng không hoàn toàn. Cấu hình đăng nhập một lần SAML và các nhà cung cấp xác thực là các kiểu Metadata API, nên chúng đi qua quy trình triển khai (SamlSsoConfig (opens in a new tab), tiếng Anh). Nhưng consumer secret của nhà cung cấp xác thực không còn được trả về trong phản hồi Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), tiếng Anh), và chứng chỉ thường khác nhau theo môi trường. Hãy lên kế hoạch cho những phần di chuyển được và những phần không.

Click to enlarge

Đọc bản đồ hệ thống theo vai trò, không theo logo: mỗi hệ thống sở hữu gì, đọc gì, hay quyết định gì.

Data 360 nằm ở đâu?

Data 360 đặt ra một câu hỏi vẽ thú vị. Tôi đặt nó ở bên phải, bên dưới ESB hay MuleSoft. Lý do là các kết nối của nó: người dùng không bao giờ kết nối trực tiếp với nó, trong khi nó kết nối trực tiếp với nhiều hệ thống phía sau. Vì vậy nó thuộc về hệ thống đường ống dữ liệu, nơi những đường nối đó giữ được ngắn, không phải ở ngoài cùng với người dùng. Vẽ nó như một màn hình khác mà người ta đăng nhập vào, và bạn đang kể sai câu chuyện.

Quản trị viên và nhóm dữ liệu có mở các màn hình của Data 360, nhưng những màn hình đó nằm trong org, trên lõi. Tenant làm công việc, dữ liệu và việc xử lý của nó, chạy ngoài lõi. Đó là lý do tôi gọi nó là gần lõi (near-core): quản lý trên lõi, lưu trữ ngoài lõi (mô-đun 1 giải thích các thuật ngữ). Bản vẽ đi theo tenant: nó nằm cùng hệ thống đường ống, với một đường nối quay về org quản lý nó.

Những gì nó làm, theo lời của Salesforce, bao gồm zero copy: một công nghệ liên kết dữ liệu cho phép doanh nghiệp truy cập và truy vấn dữ liệu mà không cần sao chép (Zero Copy (opens in a new tab), tiếng Anh). Các năng lực và trình kết nối thay đổi nhanh, nên chương Data 360 sẽ trình bày chúng đầy đủ thay vì biến mô-đun này thành một chuyến tham quan sản phẩm.

Đọc bản đồ hệ thống như các trách nhiệm

Khi nhìn vào một bản đồ hệ thống, đừng đọc các logo; hãy đọc các trách nhiệm. ERP: nó sở hữu gì? Kho dữ liệu: nó trả lời những câu hỏi nào? Nền tảng tích hợp: nó di chuyển gì? IdP: nó xác thực ai? MDM: nó quản trị danh tính nào? Data 360: nó kết nối gì, và để làm gì? Salesforce: nó thực sự chịu trách nhiệm cho cái gì? Khi trả lời được những câu đó, các hộp trở nên có ý nghĩa, và các mũi tên giữa chúng thú vị hơn nhiều. Tiếp theo, chúng ta vẽ chúng một cách có chủ ý.

Kiến trúc sư quyết định gì ở đây

• Mỗi hệ thống đóng vai trò gì, vượt ra ngoài tên sản phẩm của nó.
• Hệ thống nào có thẩm quyền cho từng tập dữ liệu quan trọng, và ở đâu Salesforce chỉ giữ một bản sao tại chỗ.
• Dữ liệu do ERP sở hữu có sẵn trong Salesforce với việc ghi được kiểm soát không, và quyền sở hữu đó thể hiện trong lược đồ thế nào.
• Phân tích thuộc về đâu, dựa trên nơi dữ liệu nằm.
• Danh tính, tích hợp, sự kiện và thẩm quyền dữ liệu chủ nằm ở đâu trên bản đồ hệ thống.

Một bản đồ hệ thống với mười hình chữ nhật không phải là kiến trúc; đó là bảng kiểm kê. Kiến trúc bắt đầu khi bạn có thể chỉ vào mọi hình chữ nhật và nói vì sao nó ở đó, nó sở hữu gì, ai dùng nó, Salesforce cần gì từ nó, và cái gì hỏng nếu bạn hiểu sai vai trò của nó.

Tìm hiểu thêm

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (trang sản phẩm, tiếng Anh), kiểm tra ngày 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (tiếng Anh).