Hiểu công cụ của bạn: Chín câu hỏi

🌐 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 6 trong 7 của chương Tư duy như một kiến trúc sư dữ liệu, chương đầu tiên của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Xây cho hôm nay. Lên kế hoạch cho ngày mai. Lên kế hoạch cho thất bại. · Tiếp theo: Kiến trúc sư dữ liệu trong thời đại AI

Câu hỏi mô-đun này trả lời: Bạn đánh giá bất kỳ công cụ nào thế nào, kể cả một công cụ bạn chưa từng thấy?

Kiến trúc sư cần óc phán đoán. Nhưng phán đoán mà không có hiểu biết thì chẳng đi được xa. Bạn vẫn cần hiểu công cụ của mình.

Tôi đã dạy kiến trúc sư nhiều năm, và một trong những khung tôi dùng là một bộ câu hỏi bạn phải trả lời được về mọi công cụ hay khả năng quan trọng trong kiến trúc của bạn. Ban đầu tôi dạy tám câu hỏi. Rồi tôi thêm câu thứ chín. Công nghệ thay đổi, Salesforce thay đổi, sản phẩm mới ra đời, khả năng cũ tiến hóa, và AI đang đẩy nhanh tất cả. Những câu hỏi này vẫn tiếp tục hữu dụng.

Chín câu hỏi

Khi học hay đánh giá một công nghệ, hãy hỏi:

1. Nó là gì?
2. Nó được dùng ở đâu?
3. Tôi dùng nó thế nào?
4. Tôi có những phương án thay thế nào?
5. Điểm mạnh của nó là gì?
6. Điểm yếu của nó là gì?
7. Tôi giải thích nó cho lập trình viên, phía nghiệp vụ và lãnh đạo thế nào?
8. Nó được bảo trì lâu dài thế nào?
9. Nó tốn bao nhiêu, cần giấy phép gì, và giới hạn của nó là gì?

Nếu trả lời được cả chín câu, bạn đang bắt đầu hiểu công cụ theo cách của một kiến trúc sư. Hãy để ý điều không có trong danh sách: “Tôi có cấu hình được nó không?” Điều đó quan trọng, nhưng chỉ là một phần của việc hiểu công cụ.

Click to enlarge

1. Nó là gì?

Hãy bắt đầu bằng câu hỏi hiển nhiên, vì người ta bỏ qua nó thường xuyên đến bất ngờ. Chúng ta nghe tên một sản phẩm hay tính năng và lập tức bắt đầu tranh luận có nên dùng nó không. Hãy chậm lại. Nó thực sự làm gì? Nó được thiết kế để giải quyết vấn đề gì? Nó nằm ở đâu trong kiến trúc, và nó không phải là gì? Một kiến trúc sư nên mô tả được một công nghệ mà không lặp lại lời mô tả tiếp thị. Nếu tôi không giải thích được một thứ trong vài câu, có lẽ tôi chưa hiểu nó đủ rõ.

2. Nó được dùng ở đâu?

Biết một thứ làm gì không giống với biết khi nào nó thuộc về một kiến trúc. Nó giỏi với loại vấn đề nào? Điều kiện nào khiến nó phù hợp, điều kiện nào nên khiến tôi nghi ngờ nó? Đây là bước chuyển từ “tôi biết tính năng này” sang “tôi nhận ra vấn đề mà tính năng này giải quyết”, và đó là một bước lớn. Bạn không muốn đi lòng vòng tìm chỗ để dùng công nghệ yêu thích của mình. Bạn muốn nhận ra vấn đề và biết công cụ nào phù hợp với chúng.

3. Tôi dùng nó thế nào?

Đúng vậy, kiến trúc sư nên hiểu việc triển khai. Bạn không phải tự xây mọi thành phần, nhưng bạn phải hiểu đủ để biết mình đang yêu cầu người khác xây gì. Hãy biết nó được cấu hình ra sao, lập trình viên làm việc với nó thế nào, dữ liệu chảy vào và ra khỏi nó thế nào, nó được triển khai và bảo mật ra sao, và nó trông thế nào khi đang chạy. Tôi không muốn một kiến trúc sư thiết kế quanh một công nghệ mà họ mới chỉ thấy trong một buổi giới thiệu sản phẩm. Hãy bắt tay vào làm: xây một thứ, làm hỏng một thứ, xem nó thực sự hoạt động thế nào. Kiến trúc tốt hơn khi nó dựa trên thực tế.

4. Tôi có những phương án thay thế nào?

Đây có thể là câu hỏi quan trọng nhất trong danh sách. Nếu bạn chỉ biết một cách để giải một vấn đề, thứ bạn có là một mặc định, không phải một quyết định kiến trúc. Khi ai đó đề xuất một công nghệ, tôi muốn biết chúng ta còn làm được gì khác. Một khả năng Salesforce khác? Thứ gì đó khai báo (declarative), hay viết mã? Khả năng đó có thể nằm ngoài Salesforce không? Chúng ta có thể để dữ liệu ở nguyên chỗ thay vì sao chép, dùng một sự kiện thay vì một lời gọi API, hay tránh xây bất cứ thứ gì không? Các phương án thay thế tạo ra đánh đổi, và đánh đổi là trái tim của kiến trúc.

5. Điểm mạnh của nó là gì?

Mọi công cụ đều có lý do tồn tại. Hãy hiểu nó thực sự giỏi ở điểm nào: nó làm cho điều gì dễ dàng, nó mở rộng tốt ở đâu, nó loại bỏ độ phức tạp nào, nó giải quyết vấn đề nào một cách thanh lịch. Hãy dùng công nghệ ở nơi điểm mạnh của nó khớp với vấn đề. Nghe thì hiển nhiên, nhưng rất dễ chọn một công cụ vì chúng ta đã có nó, vì nhóm biết nó, vì nó mới, hoặc vì ai đó đã xem một bản demo. Đó có thể là những yếu tố. Nhưng chúng không giống với sự phù hợp về kiến trúc.

6. Điểm yếu của nó là gì?

Điều này cũng quan trọng không kém. Mọi công nghệ đều có điểm yếu, không trừ công nghệ nào. Nếu ai đó chỉ kể cho bạn điểm mạnh của một công nghệ, các bạn vẫn chưa có một cuộc thảo luận kiến trúc. Nó không làm tốt điều gì? Độ phức tạp xuất hiện ở đâu, và điều gì xảy ra ở quy mô lớn? Nó mang đến gánh nặng vận hành và sự phụ thuộc nào? Những yêu cầu nào đẩy nó ra khỏi vùng lý tưởng của nó? Một điểm yếu không phải lúc nào cũng có nghĩa là chúng ta không nên dùng công nghệ đó. Nó có nghĩa là chúng ta cần biết mình đang chấp nhận điều gì. Một đánh đổi bạn hiểu có thể là một quyết định kiến trúc. Một đánh đổi bạn không hiểu có thể trở thành một bất ngờ.

7. Tôi giải thích nó cho các đối tượng khác nhau thế nào?

Đây là một trong những câu hỏi phân biệt hiểu biết kỹ thuật với kỹ năng kiến trúc. Bạn có giải thích được cùng một công nghệ cho một lập trình viên, cho phía nghiệp vụ và cho một lãnh đạo không? Đó không nên là cùng một lời giải thích. Lập trình viên cần API, hành vi giao dịch, bảo mật, xử lý lỗi và các mẫu triển khai. Phía nghiệp vụ quan tâm nó cho phép làm gì và quy trình của họ thay đổi ra sao. Lãnh đạo quan tâm chi phí, rủi ro, thời gian, tác động lên tổ chức, và quyết định này mở ra hay đóng lại những lựa chọn nào. Bạn không thay đổi sự thật; bạn thay đổi mức độ trừu tượng. Nếu bạn chỉ giải thích được một công nghệ bằng đúng lời lẽ trong tài liệu của nó, hãy tiếp tục tìm hiểu nó.

8. Nó được bảo trì lâu dài thế nào?

Dự án thì kết thúc. Hệ thống thì không, ít nhất là chúng ta hy vọng vậy. Sau khi nhóm dự án rời đi, phải có ai đó sở hữu thứ chúng ta đã xây. Điều đó có nghĩa là biết nó được giám sát, nâng cấp và xử lý sự cố thế nào, ai cần kỹ năng để hỗ trợ nó, các thay đổi được triển khai và kiểm thử ra sao, và điều gì xảy ra khi công nghệ tiến hóa hoặc Salesforce thay đổi thứ gì đó bên dưới chúng ta. Hãy hình dung ba năm sau. Tôi đã thấy những kiến trúc rất thông minh vào ngày go-live nhưng sau đó vận hành thì khổ sở. Đó không phải là thành công. Khả năng bảo trì là một phần của kiến trúc.

9. Nó tốn bao nhiêu, cần giấy phép gì, và giới hạn của nó là gì?

Đây là câu hỏi tôi thêm vào tám câu ban đầu, và hôm nay tôi nghĩ không thể bỏ nó ra được. Một công nghệ có thể là giải pháp kỹ thuật hoàn hảo mà vẫn là giải pháp kiến trúc sai nếu bài toán kinh tế không ổn. Nó có nằm trong giấy phép chúng ta đã có không, hay là một tiện ích bổ sung? Nó được cấp phép theo người dùng, theo mức sử dụng, theo lượng tiêu thụ, theo dung lượng lưu trữ hay theo giao dịch? Chi phí thay đổi ra sao khi chúng ta mở rộng?

Rồi đến các giới hạn, và nền tảng nào cũng có: giới hạn API, lưu trữ, truy vấn, giao dịch, đồng thời, thông lượng và giấy phép. Có giới hạn cứng, có giới hạn mềm; có giới hạn nâng được, có giới hạn không; có giới hạn không đáng kể cho đến khi quy mô của chúng ta thêm một chữ số 0. Bạn không phải thuộc lòng mọi giới hạn của Salesforce; làm vậy là dùng thời gian của bạn rất tệ. Điều bạn cần biết là giới hạn tồn tại, giới hạn nào quan trọng với kiến trúc của bạn, và khi nào bạn cần kiểm chứng con số hiện hành. Các con số sẽ thay đổi. Câu hỏi kiến trúc sẽ còn đó.

Một ví dụ minh họa: Apex Sharing

Đây là một trong những ví dụ quen thuộc nhất của tôi về các câu hỏi khi được đưa vào thực tế. Chúng ta nhận một yêu cầu chia sẻ phức tạp mà cả quy tắc chia sẻ dựa trên chủ sở hữu lẫn dựa trên tiêu chí đều không đáp ứng được. Điều đó dẫn chúng ta đến Apex sharing: mã tự ghi các bản ghi chia sẻ. Giờ chúng ta cần biết Apex sharing là gì, được dùng ở đâu, dùng thế nào và phần còn lại. Đó là một bước leo thang: Apex sharing là phương án thay thế (câu hỏi 4) khi các quy tắc chúng ta cần vượt quá những gì chia sẻ dựa trên chủ sở hữu và tiêu chí có thể diễn đạt.

Giờ đến điểm yếu (câu hỏi 6). Giả sử chúng ta có một cộng đồng khách hàng 10 hay 20 triệu thành viên, và đang dùng giấy phép Customer Community, không phải Customer Community Plus. Đó là những người dùng khối lượng lớn. Họ không có vai trò và hoàn toàn không dùng mô hình chia sẻ: quyền truy cập của họ đến từ các bộ chia sẻ (sharing set) và nhóm chia sẻ (share group) khớp qua tài khoản và liên hệ của họ. Không có bản ghi chia sẻ nào để Apex ghi cho họ, nên Apex sharing không dùng được cho họ. Và chính câu hỏi chi phí và giấy phép (câu hỏi 9) đã đưa chúng ta đến đây: lựa chọn giấy phép đã quyết định những công cụ chia sẻ nào tồn tại.

Vậy là cũng như Apex sharing là phương án thay thế cho các quy tắc dựa trên chủ sở hữu và tiêu chí, bạn có thể gặp tình huống phải tìm một phương án thay thế cho chính Apex sharing. Và đến lúc đó thực sự không còn lựa chọn dựa trên cấu hình nào cho các quy tắc chia sẻ phức tạp. Cuối cùng bạn đặt đối tượng ở chế độ chỉ đọc và kiểm soát truy cập qua Apex. Đó là lý do bạn hỏi cả chín câu trước khi chọn, chứ không phải sau.

Đừng học thuộc nền tảng

Điều này quan trọng nhất khi bạn đang học kiến trúc Salesforce. Đừng cố học thuộc Salesforce. Bạn không làm được: nền tảng quá lớn và thay đổi quá nhanh. Tôi đã làm việc với Salesforce rất lâu và vẫn đang học. Điều đó là bình thường.

Điều tôi muốn bạn phát triển là một khung học tập. Khi ngày mai Salesforce phát hành một khả năng mới, tôi không cần phải đã từng thấy nó. Tôi biết cần hỏi gì: nó là gì, nó hợp với chỗ nào, tôi dùng nó thế nào, tôi còn dùng được gì khác, nó giỏi ở điểm nào, nó chật vật ở đâu, tôi giải thích nó thế nào, tôi vận hành nó ra sao, nó tốn bao nhiêu và giới hạn của nó ở đâu? Giờ tôi có thể bắt đầu đánh giá nó. Điều đó giá trị hơn nhiều so với học thuộc thêm một bảng so sánh tính năng.

Ngoài kỳ thi: AI giúp trả lời chín câu hỏi nhanh hơn, và cũng dễ trả lời sai hơn. Gặp một công nghệ lạ, bạn có thể nhờ AI giải thích nó, so sánh ba cách tiếp cận, liệt kê giới hạn và các kiểu thất bại thường gặp, hoặc lập luận chống lại việc dùng nó. Đó là một trợ lý nghiên cứu phi thường. Nhưng nó có thể sai, có thể lỗi thời, hoặc tự tin nhầm lẫn hai sản phẩm hay hai phiên bản có tên tương tự. Với bất cứ điều gì ảnh hưởng đến một quyết định, hãy kiểm chứng: lần theo nguồn và kiểm tra tài liệu, giới hạn và giấy phép hiện hành. Tin nhưng phải kiểm chứng (mô-đun 7).

Học các câu hỏi, không chỉ các câu trả lời

Trong khóa học này chúng ta sẽ gặp rất nhiều công nghệ. Tôi không muốn bạn tích trữ câu trả lời; tôi muốn bạn luyện các câu hỏi. Hãy hỏi cùng chín câu đó khi chúng ta nói về đối tượng lớn, dữ liệu bên ngoài, Data 360, các mẫu tích hợp, hay một khả năng AI mà Salesforce phát hành sáu tháng sau khi chương này được viết.

Các câu trả lời sẽ thay đổi. Các câu hỏi thì bền vững. Đó là điều biến chúng thành một khung kiến trúc chứ không phải một tài liệu ôn thi.

Hãy hiểu công cụ của bạn: chúng giỏi ở đâu, kém ở đâu, bạn còn dùng được gì khác, chúng tốn bao nhiêu và chúng gãy ở đâu. Và hiểu đủ để giải thích quyết định cho những người phải sống cùng nó. Đó là cách một kiến trúc sư học công nghệ.

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

• Một công cụ có phù hợp với vấn đề không, được đánh giá theo cả chín câu hỏi, không chỉ theo việc nó có cấu hình được hay không.
• Các phương án thay thế là gì, và chi phí, giấy phép và giới hạn của công cụ có ý nghĩa gì ở quy mô của bạn.
• Ai sẽ bảo trì nó sau ba năm, và bảo trì thế nào.
• Những dữ kiện nào về công cụ cần được kiểm chứng trước khi dựa vào chúng.

Tìm hiểu thêm

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-09; kiểm tra lại ngày 2026-10-12): người dùng khối lượng lớn (các giấy phép External Apps, Customer Community, High Volume Customer Portal và Authenticated Website) không có vai trò; quyền truy cập của họ đến từ bộ chia sẻ và nhóm chia sẻ; họ không thể được đưa vào quy tắc chia sẻ dựa trên chủ sở hữu, và các bản ghi họ sở hữu không thể được chia sẻ thủ công.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (tiếng Anh, kiểm tra ngày 2026-10-09; kiểm tra lại ngày 2026-10-12): người dùng khối lượng lớn (các giấy phép Customer Community, High Volume Customer Portal, Authenticated Website) không dùng mô hình chia sẻ vì giấy phép của họ không hỗ trợ vai trò; quyền truy cập vận hành qua bộ chia sẻ hoặc nhóm chia sẻ, bằng cách khớp với các trường tra cứu Tài khoản và Liên hệ của người dùng. Cùng trang đó cũng liệt kê khi nào chia sẻ do Apex quản lý là công cụ đúng.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), câu hỏi trên Trailblazer Community, tháng 11 năm 2024 (tiếng Anh, kiểm tra ngày 2026-10-09; kiểm tra lại ngày 2026-10-12): một người làm thực tế báo rằng thêm bản ghi chia sẻ cho người dùng khối lượng lớn bị lỗi. Đây là báo cáo từ thực tế, không phải tài liệu chính thức. (Trailblazer Community trực tuyến chuyển sang chế độ chỉ đọc vào ngày 30 tháng 10 năm 2026; liên kết có thể thay đổi.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-09): một bộ chia sẻ cấp quyền truy cập vào các bản ghi liên quan đến tài khoản hoặc liên hệ của người dùng.