Salesforce là một hệ thống giữa nhiều hệ thống

🌐 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 1 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. Tiếp theo: Các loại dữ liệu doanh nghiệp

Câu hỏi mô-đun này trả lời: Vì sao một kiến trúc sư dữ liệu vẽ những gì bao quanh org trước khi thiết kế org?

Khi tôi dạy các ứng viên CTA, bài tập về nhà sau ngày đầu tiên luôn giống nhau. Đọc tình huống. Bắt đầu vẽ bản đồ hệ thống từ một trang trắng. Chỉ sau đó mới thử phác mô hình dữ liệu. Không phải các đối tượng, không phải chi tiết các tích hợp: mà là bản đồ hệ thống. Tôi muốn thấy những gì bao quanh Salesforce trước khi chúng ta quyết định cái gì thuộc về bên trong nó.

Đó là một sự thay đổi góc nhìn với nhiều người làm Salesforce. Nếu bạn đã dành cả sự nghiệp làm quản trị viên hay lập trình viên, Salesforce tự nhiên là trung tâm thế giới của bạn. Bạn mở Thiết lập, tạo đối tượng, xây flow, viết Apex, và tích hợp các hệ thống khác vào Salesforce. Mọi thứ dường như bắt đầu từ org. Một kiến trúc sư phải kéo máy quay lùi lại, vì trong một doanh nghiệp Salesforce là một hệ thống giữa nhiều hệ thống, và khá thường xuyên nó không phải là hệ thống sở hữu dữ liệu.

Vẽ bản đồ hệ thống trước

Chương 2 đã xây mô hình logic, và chương 3 hỏi nó sống trên Salesforce thế nào. Giờ tôi sẽ làm bài toán lớn hơn. Trước khi quyết định Salesforce nên sở hữu gì, tôi muốn hiểu doanh nghiệp xung quanh nó. Những hệ thống nào đã tồn tại? Khách hàng được tạo ở đâu, sản phẩm được định nghĩa ở đâu, đơn hàng bắt đầu ở đâu, hóa đơn được phát hành ở đâu? Danh tính nằm ở đâu? Phân tích diễn ra ở đâu, tài liệu được giữ ở đâu, lịch sử nằm ở đâu? Những hệ thống nào cần dữ liệu của Salesforce, và Salesforce phụ thuộc vào những hệ thống nào?

Những câu hỏi đó thay đổi kiến trúc. Vì vậy tôi bắt đầu từ một trang trắng, đặt Salesforce ở giữa, và vẽ mọi thứ xung quanh nó. Mô-đun 4 cho thấy chính xác cách tôi bố trí. Hiện tại, bài học đơn giản là: đừng thiết kế org trước khi bạn hiểu thế giới mà nó phải sống trong đó.

Salesforce thường không phải là hệ thống gốc

Lấy một doanh nghiệp rất phổ biến: Salesforce cộng một ERP, hệ thống hoạch định nguồn lực doanh nghiệp như SAP hay Oracle, vận hành tài chính, sản phẩm, tồn kho, mua hàng và thực hiện đơn hàng. Giờ hãy hỏi một câu đơn giản: khách hàng nằm ở đâu?

Có thể là Salesforce, ERP, hoặc cả hai, và đó là chỗ trở nên thú vị. Nhân viên kinh doanh có thể làm việc với khách hàng tiềm năng như các Tài khoản trong Salesforce, trong khi ERP cấp mã khách hàng chính thức khi họ trở thành khách hàng trả tiền. Sản phẩm và giá? Có lẽ là ERP. Tồn kho? Gần như không bao giờ là Salesforce. Đơn hàng có thể được ghi nhận trong Salesforce và thực hiện trong ERP; hóa đơn đến từ ERP; dịch vụ nằm trong Salesforce; phân tích được chia giữa báo cáo Salesforce và một kho dữ liệu. Bỗng nhiên mô hình dữ liệu Salesforce xinh đẹp của chúng ta không phải là mô hình dữ liệu doanh nghiệp. Nó chỉ là một phần trong đó.

Kiểu tích hợp tôi gặp đi gặp lại

Kiểu tích hợp phổ biến nhất tôi gặp là thế này: khách hàng, sản phẩm và giá chảy vào Salesforce từ ERP, và đơn hàng chảy ra. Thay bằng SAP, Oracle hay bất kỳ ERP nào khác; hình dạng vẫn vậy. ERP nắm bản ghi vàng cho khách hàng và sản phẩm, nên các luồng đó đến từ bên phải, đi vào Salesforce. Bộ phận kinh doanh chốt giao dịch trong Salesforce, nên đơn hàng bắt đầu ở đó và quay về ERP để được thực hiện, lập hóa đơn và hạch toán.

Những luồng đó không chỉ là tích hợp. Chúng cho tôi biết doanh nghiệp tin rằng sự thật nằm ở đâu.

Mũi tên một chiều làm tôi lo lắng

Bất cứ khi nào thấy một tích hợp chỉ có một luồng, tôi bắt đầu lo ngại. Ở mức tổng quan, ai đó vẽ một mũi tên duy nhất: đơn hàng từ Salesforce đến ERP. Được. Giờ hãy nhìn sâu hơn. Làm sao tôi gửi một đơn hàng đến ERP nếu tôi không biết khách hàng, sản phẩm hay giá của nó? Đơn hàng phải gắn với một khách hàng mà ERP đã có, và mỗi dòng phải là một SKU mà ERP đã bán. Tôi không thể gửi một mục dòng cho một sản phẩm không tồn tại ở phía bên kia. Vì vậy trước khi mũi tên đơn hàng đó hoạt động được, các luồng ngược phải tồn tại, chạy theo chiều kia.

Đó là câu hỏi tôi đặt ra cho mọi mũi tên: luồng này phụ thuộc vào cái gì? Mũi tên tổng quan mà bạn nhìn thấy thường cần những luồng ngược mà bạn chưa vẽ.

Nhìn sâu thêm nữa thì bạn sẽ thấy chiều về. Salesforce gửi một đơn hàng. Rồi sao? Nó được chấp nhận hay bị từ chối? Nó đã giao, giao một phần, hay bị hủy? Đã lập hóa đơn chưa? Có ai trong Salesforce cần biết không? Có thể họ không cần. Nhưng lẽ ra phải có ai đó hỏi. Nếu không có gì quay về, cũng được. Hãy cho tôi biết tại sao.

Doanh nghiệp không đến cùng một lúc

Bản đồ hệ thống trở nên phức tạp một phần vì không ai xây tất cả cùng một lúc. Dữ liệu đã đến theo từng làn sóng. Đầu tiên là tệp: bản ghi định dạng cố định, rồi tệp có dấu phân cách như CSV. Rồi cơ sở dữ liệu quan hệ cho dữ liệu vận hành. Rồi kho dữ liệu để gom chúng lại cho phân tích. Rồi cơ sở dữ liệu NoSQL cho tài liệu, cặp khóa-giá trị và đồ thị không nằm gọn trong bảng. Rồi hồ dữ liệu cho khối lượng khổng lồ dữ liệu thô và bán cấu trúc, và lakehouse kết hợp cả hai. Luồng sự kiện, như Kafka hay event bus của Salesforce, di chuyển dữ liệu ngay khi nó xảy ra thay vì theo lô hằng đêm. Và giờ là liên kết dữ liệu (federation), nơi dữ liệu không cần được sao chép vào một chỗ trước khi nền tảng khác dùng được nó.

Công nghệ chưa phải là điểm chính. Điểm chính là: làn sóng mới hiếm khi làm làn sóng cũ biến mất. Bước vào một doanh nghiệp lớn và bạn sẽ thấy tất cả cùng lúc: cơ sở dữ liệu quan hệ, ERP, Salesforce, một kho dữ liệu, một hồ dữ liệu, các tệp thả qua SFTP, API, luồng sự kiện, bảng tính mà ai đó vẫn gửi email mỗi thứ Sáu, và một hệ thống mà ai cũng sợ chạm vào vì người xây nó đã nghỉ hưu sáu năm trước. Đó là doanh nghiệp bạn đang thiết kế kiến trúc, không phải doanh nghiệp trong tờ quảng cáo sản phẩm.

Các hệ thống khác nhau tồn tại vì những lý do khác nhau

Đó cũng là lý do tôi không bao giờ bắt đầu với “làm sao đưa hết dữ liệu vào Salesforce?” Tại sao tôi lại muốn tất cả ở đó? Salesforce có thể là nơi tốt nhất để nhân viên kinh doanh và dịch vụ làm việc với khách hàng. Điều đó không biến nó thành hệ thống tài chính, kho dữ liệu doanh nghiệp, kho dữ liệu đo xa, kho lưu tài liệu, hay ngôi nhà của mọi cú nhấp chuột, mọi lần đọc GPS và mọi giao dịch lịch sử mà công ty từng tạo ra.

Chương 3 hỏi dữ liệu này nên nằm ở đâu? cho một org. Ở cấp doanh nghiệp, cùng câu hỏi đó trở nên lớn hơn: đôi khi Salesforce sở hữu dữ liệu, đôi khi nó giữ một bản sao, đôi khi chỉ một tham chiếu, và đôi khi nó hoàn toàn không nên có dữ liệu đó.

Lõi, ngoài lõi và Hyperforce

Còn một ranh giới khác cần hiểu: ngay cả “Salesforce” cũng không phải là một môi trường chạy và một cơ sở dữ liệu. Ở chương 3, trên lõi (on core) nghĩa là nơi dữ liệu nằm: trên bàn làm việc của bạn, trong chính các đối tượng của org. Ở đây cùng những từ đó mô tả nơi một sản phẩm chạy. Bạn sẽ nghe các kiến trúc sư dùng cả hai nghĩa.

Trước đây môi trường chạy Core lưu trữ phần lớn nền tảng. Ngày nay Salesforce mô tả một nền tảng gồm hàng trăm dịch vụ độc lập, hướng siêu dữ liệu, với Core vẫn là hệ thống gốc duy nhất cho siêu dữ liệu ứng dụng (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), tiếng Anh). Đó là lý do bạn sẽ nghe các kiến trúc sư nói một năng lực chạy trên lõi hay ngoài lõi.

Điều này đã quan trọng từ lâu trước khi nền tảng tách thành các dịch vụ. Khi tôi hỏi một lớp học vì sao Salesforce mua SteelBrick cho báo giá thay vì Apttus, câu trả lời tôi muốn nghe rất đơn giản: SteelBrick được xây 100% trên lõi. Flow và trigger nằm trong lõi, nên một sản phẩm xây ở đó nhận được luôn siêu dữ liệu, tùy chỉnh và tự động hóa của nền tảng. Sản phẩm báo giá đó từ đó đã nhường chỗ cho Revenue Cloud, nhưng bài học thì vẫn còn. Rồi đến gần lõi (near-core), và Data 360 là ví dụ tôi dùng. Data 360 không phải là lõi. Tenant của nó nằm ngoài lõi: dữ liệu và các cơ chế xử lý dữ liệu chạy trong lakehouse riêng, bên cạnh cơ sở dữ liệu quan hệ của org chứ không nằm trong đó (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), tiếng Anh). Nhưng các màn hình bạn dùng để thiết lập và điều khiển nó được hiển thị trên lõi, trong org. Vì vậy cách nói chính xác nhất tôi có thể đưa ra là: quản lý trên lõi, lưu trữ ngoài lõi. Không phần dữ liệu hay xử lý nào thực sự chạy trong Core; giao diện trên Core điều khiển tenant ngoài lõi. Và rồi, dĩ nhiên, còn mọi thứ nằm ngoài lõi vì chúng hoàn toàn không phải Salesforce.

Tôi ít quan tâm đến việc thuộc lòng năm nay sản phẩm nào chạy ở đâu, vì điều đó thay đổi, mà quan tâm đến thói quen: một ranh giới có thể ảnh hưởng đến việc di chuyển dữ liệu, độ trễ, danh tính, tích hợp và nơi cư trú dữ liệu. Vì vậy đừng giả định rằng chỉ vì một sản phẩm mang tên Salesforce mà dữ liệu của nó nằm ngay cạnh các bản ghi Tài khoản của bạn. Hãy nhìn vào kiến trúc thực tế.

Rồi đến Hyperforce: hạ tầng của Salesforce được xây cho đám mây công cộng và được định nghĩa bằng code, thay vì các trung tâm dữ liệu truyền thống của chính họ, cho khách hàng nhiều lựa chọn hơn về nơi dữ liệu của họ cư trú (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), tiếng Anh). Điều đó quan trọng, và mô-đun 5 sẽ quay lại. Nhưng kiến trúc hạ tầng không phải là kiến trúc dữ liệu doanh nghiệp. Chuyển một org lên đám mây công cộng không cho bạn biết ai sở hữu khách hàng, tồn kho nằm ở đâu, phân tích chạy ở đâu, hay dữ liệu nào được phép vượt biên giới. Hyperforce có thể định hình một số quyết định đó, đặc biệt là nơi cư trú dữ liệu. Nó không thay thế việc hiểu bản đồ hệ thống.

Bản đồ hệ thống đến trước chiếc hộp

Vậy đây là thói quen. Ai đó đưa cho bạn một tình huống. Đừng bắt đầu xây giải pháp Salesforce. Trước tiên hãy tìm các hệ thống: ERP, nhà cung cấp danh tính, kho dữ liệu, nền tảng tích hợp, hệ thống đối tác, kênh khách hàng, kho tài liệu. Rồi tìm dữ liệu di chuyển giữa chúng: khách hàng, sản phẩm, đơn hàng, hóa đơn, tài liệu, sự kiện, danh tính. Rồi hỏi ai sở hữu từng thứ. Chỉ sau đó mới quyết định cái gì thuộc về Salesforce. Nếu không, bạn đang thiết kế một chiếc hộp mà không biết nó nối với cái gì.

Click to enlarge

Bước 1 trên 3: org mà ta thiết kế, đứng một mình. Nhìn từ đây, nó trông như cả thế giới.

Click to enlarge

Bước 2 trên 3: lùi ra xa. Salesforce là một hệ thống giữa nhiều hệ thống (mô-đun 4 dạy cách bố trí này).

Click to enlarge

Bước 3 trên 3: những mũi tên đầu tiên. Khách hàng, sản phẩm và giá vào từ ERP, đơn hàng ra: chúng cho biết doanh nghiệp tin sự thật nằm ở đâu.

Bản đồ hệ thống thay đổi mô hình dữ liệu

Đây là lý do nó quan trọng với một kiến trúc sư dữ liệu. Chương 2 nói khách hàng là một thực thể quan trọng. Được. Rồi bản đồ hệ thống nói ERP có thẩm quyền đối với khách hàng. Điều đó thay đổi mô hình vật lý. Salesforce có thể vẫn giữ một Tài khoản tại chỗ, vì người ta dùng nó hằng ngày, nhưng giờ chúng ta cần mã định danh của ERP làm ID bên ngoài; chúng ta cần biết Salesforce được phép thay đổi những trường nào (tôi đánh dấu các trường của ERP bằng tiền tố erp_, như sẽ thấy ở mô-đun 3); thay đổi từ ERP đến nhanh đến đâu; Salesforce có thể tạo một khách hàng trước khi ERP biết về nó không; và chuyện gì xảy ra khi hai bên không khớp nhau. Đó không phải là những câu hỏi tích hợp để sau này. Đó là những câu hỏi kiến trúc dữ liệu, và bản đồ hệ thống đã phơi bày chúng.

Đây là cách một trong số đó gây hại. Một nhân viên kinh doanh chuyển đổi một khách hàng tiềm năng là một công ty đồ uống lớn, tạo Tài khoản, thắng giao dịch, và khách hàng được chuyển sang ERP. Nhưng công ty đã làm ăn với hãng đồ uống đó nhiều năm, và ERP đã có họ rồi. Giờ thì có hai bản. Lẽ ra nhân viên kinh doanh có nên được phép tạo Tài khoản đó không? Chương 5 và 6 sẽ quay lại chuyện này; bản đồ hệ thống là nơi bạn thấy nó sắp xảy ra.

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

• Những hệ thống nào bao quanh Salesforce, và mỗi hệ thống đóng vai trò gì.
• Hệ thống nào sở hữu từng loại dữ liệu quan trọng, trước khi quyết định Salesforce giữ bao nhiêu phần trong đó.
• Cái gì chảy vào Salesforce, cái gì chảy ra, và cái gì quay trở lại.
• Salesforce nên sở hữu, sao chép, tham chiếu, liên kết, lưu trữ hay để yên dữ liệu nào.
• Những ranh giới nền tảng và hạ tầng nào quan trọng, thay vì giả định mọi thứ mang thương hiệu Salesforce đều nằm ở một chỗ.

Bước chuyển từ lập trình viên sang kiến trúc sư thường không phải là học thêm một tính năng. Mà là học khi nào thôi nhìn vào Salesforce: kéo máy quay lùi lại, đi theo dữ liệu, tìm ai sở hữu sự thật, rồi quay lại và quyết định việc của Salesforce nên là gì.

Tìm hiểu thêm

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.