รู้จักเครื่องมือของคุณ: คำถามเก้าข้อ

🌐 มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 6 จาก 7 ในบท คิดแบบสถาปนิกข้อมูล ซึ่งเป็นบทแรกของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: สร้างเพื่อวันนี้ วางแผนเพื่อพรุ่งนี้ วางแผนรับความล้มเหลว · ถัดไป: สถาปนิกข้อมูลในยุค AI

คำถามที่โมดูลนี้ตอบ: จะประเมินเครื่องมือใดก็ตาม รวมถึงเครื่องมือที่ไม่เคยเห็นมาก่อน ได้อย่างไร?

สถาปนิกต้องมีวิจารณญาณ แต่วิจารณญาณที่ไม่มีความรู้ก็ไม่ค่อยมีประโยชน์ คุณยังต้องรู้จักเครื่องมือของคุณ

ผมสอนสถาปนิกมาหลายปี และกรอบคิดหนึ่งที่ผมใช้คือชุดคำถามที่คุณควรตอบได้เกี่ยวกับทุกเครื่องมือหรือความสามารถสำคัญในสถาปัตยกรรมของคุณ แต่เดิมผมสอนแปดคำถาม ผมเพิ่มข้อที่เก้าเข้ามา เทคโนโลยีเปลี่ยน Salesforce เปลี่ยน ผลิตภัณฑ์ใหม่ปรากฏ ความสามารถเดิมพัฒนาไป และ AI กำลังเร่งทั้งหมดนั้น แต่คำถามเหล่านี้ยังใช้ได้ต่อไป

คำถามเก้าข้อ

เมื่อใดก็ตามที่คุณเรียนรู้หรือประเมินเทคโนโลยี ให้ถามว่า:

1. มันคืออะไร?
2. ใช้ที่ไหน?
3. ใช้อย่างไร?
4. มีทางเลือกอื่นอะไรบ้าง?
5. จุดแข็งของมันคืออะไร?
6. จุดอ่อนของมันคืออะไร?
7. จะอธิบายมันให้นักพัฒนา ฝ่ายธุรกิจ และผู้บริหารเข้าใจอย่างไร?
8. จะดูแลรักษามันในระยะยาวอย่างไร?
9. มีต้นทุนเท่าไร ต้องใช้สิทธิ์การใช้งานแบบไหน และมีข้อจำกัดอะไร?

ถ้าคุณตอบได้ทั้งเก้าข้อ คุณก็เริ่มเข้าใจเครื่องมือแบบสถาปนิกแล้ว สังเกตสิ่งที่ไม่อยู่ในรายการ: “ฉันตั้งค่ามันได้ไหม?” เรื่องนั้นสำคัญ แต่เป็นเพียงส่วนหนึ่งของการรู้จักเครื่องมือ

Click to enlarge

1. มันคืออะไร?

เริ่มจากคำถามที่ชัดเจนที่สุด เพราะคนข้ามมันบ่อยอย่างน่าประหลาดใจ เราได้ยินชื่อผลิตภัณฑ์หรือฟีเจอร์ แล้วเริ่มพูดคุยทันทีว่าจะใช้มันไหม ชะลอลง มันทำอะไรจริงๆ? ถูกออกแบบมาเพื่อแก้ปัญหาอะไร? มันอยู่ตรงไหนในสถาปัตยกรรม และมันไม่ใช่อะไร? สถาปนิกควรอธิบายเทคโนโลยีได้โดยไม่ต้องท่องคำโฆษณา ถ้าผมอธิบายบางอย่างไม่ได้ในไม่กี่ประโยค ผมก็น่าจะยังไม่เข้าใจมันดีพอ

2. ใช้ที่ไหน?

การรู้ว่าบางอย่างทำอะไร ไม่เหมือนกับการรู้ว่ามันควรอยู่ในสถาปัตยกรรมเมื่อไร มันเก่งกับปัญหาแบบไหน? เงื่อนไขอะไรที่ทำให้มันเหมาะสม และเงื่อนไขอะไรที่ควรทำให้ผมสงสัยมัน? นี่คือก้าวจาก “ฉันรู้จักฟีเจอร์นี้” ไปสู่ “ฉันมองออกว่าฟีเจอร์นี้แก้ปัญหาอะไร” และเป็นก้าวที่ใหญ่ คุณไม่อยากเดินไปรอบๆ หาที่ใช้เทคโนโลยีที่ตัวเองชอบ คุณอยากมองปัญหาออก และรู้ว่าเครื่องมือไหนเหมาะกับมัน

3. ใช้อย่างไร?

ใช่ สถาปนิกควรเข้าใจการ implement คุณไม่ต้องสร้างทุกคอมโพเนนต์เอง แต่ควรเข้าใจพอที่จะรู้ว่ากำลังขอให้คนอื่นสร้างอะไร รู้ว่ามันถูกตั้งค่าอย่างไร นักพัฒนาทำงานกับมันอย่างไร ข้อมูลเข้าออกอย่างไร deploy และรักษาความปลอดภัยอย่างไร และหน้าตาเมื่อใช้งานจริงเป็นอย่างไร ผมไม่อยากให้สถาปนิกออกแบบรอบเทคโนโลยีที่เคยเห็นแค่บนสไลด์ผลิตภัณฑ์ ลงมือทำให้มือเลอะบ้าง: สร้างอะไรสักอย่าง ทำพังสักอย่าง ดูว่ามันทำงานจริงอย่างไร สถาปัตยกรรมจะดีขึ้นเมื่อยืนอยู่บนความเป็นจริง

4. มีทางเลือกอื่นอะไรบ้าง?

นี่อาจเป็นคำถามที่สำคัญที่สุดในรายการ ถ้าคุณรู้วิธีแก้ปัญหาแค่วิธีเดียว คุณไม่ได้มีการตัดสินใจเชิงสถาปัตยกรรม คุณมีแค่ค่าเริ่มต้น เมื่อใดที่มีคนเสนอเทคโนโลยี ผมอยากรู้ว่าเราทำอย่างอื่นได้ไหม ความสามารถอื่นของ Salesforce? แบบ declarative หรือเขียนโค้ด? ความสามารถนั้นอยู่นอก Salesforce ได้ไหม? เราปล่อยข้อมูลไว้ที่เดิมแทนการคัดลอกได้ไหม ใช้ event แทนการเรียก API ได้ไหม หรือไม่ต้องสร้างอะไรเลยได้ไหม? ทางเลือกสร้างการแลกเปลี่ยนได้เสีย และการแลกเปลี่ยนได้เสียคือหัวใจของสถาปัตยกรรม

5. จุดแข็งของมันคืออะไร?

ทุกเครื่องมือมีอยู่ด้วยเหตุผล เข้าใจว่ามันเก่งอะไรจริงๆ: ทำให้อะไรง่ายขึ้น ขยายได้ดีตรงไหน ลดความซับซ้อนอะไร และแก้ปัญหาอะไรได้อย่างสง่างาม ใช้เทคโนโลยีในที่ที่จุดแข็งของมันตรงกับปัญหา ฟังดูชัดเจน แต่มันง่ายมากที่จะเลือกเครื่องมือเพราะเรามีอยู่แล้ว ทีมรู้จักมัน มันใหม่ หรือมีคนเห็นเดโม สิ่งเหล่านั้นอาจเป็นปัจจัยได้ แต่ไม่ใช่สิ่งเดียวกับความเหมาะสมเชิงสถาปัตยกรรม

6. จุดอ่อนของมันคืออะไร?

ข้อนี้สำคัญไม่แพ้กัน ทุกเทคโนโลยีมีจุดอ่อน ทุกตัว ถ้ามีคนบอกคุณได้แค่จุดแข็งของเทคโนโลยี คุณยังไม่ได้อยู่ในการพูดคุยเชิงสถาปัตยกรรม มันทำอะไรได้ไม่ดี? ความซับซ้อนโผล่ที่ไหน และจะเกิดอะไรขึ้นเมื่อขยายขนาด? มันนำภาระการดูแลและการพึ่งพาอะไรมาด้วย? ความต้องการแบบไหนที่ดันมันออกจากจุดที่มันถนัด? จุดอ่อนไม่ได้แปลว่าเราไม่ควรใช้เทคโนโลยีนั้นเสมอไป แต่หมายความว่าเราต้องรู้ว่ากำลังยอมรับอะไร การแลกเปลี่ยนที่คุณเข้าใจอาจเป็นการตัดสินใจเชิงสถาปัตยกรรม การแลกเปลี่ยนที่คุณไม่เข้าใจอาจกลายเป็นเรื่องเซอร์ไพรส์

7. จะอธิบายมันให้ผู้ฟังต่างกลุ่มเข้าใจอย่างไร?

นี่คือหนึ่งในคำถามที่แยกความรู้ทางเทคนิคออกจากทักษะของสถาปนิก คุณอธิบายเทคโนโลยีเดียวกันให้นักพัฒนา ฝ่ายธุรกิจ และผู้บริหารเข้าใจได้ไหม? นั่นไม่ควรเป็นคำอธิบายเดียวกัน นักพัฒนาต้องการ API พฤติกรรมของทรานแซกชัน ความปลอดภัย การจัดการความล้มเหลว และรูปแบบการ implement ฝ่ายธุรกิจสนใจว่ามันทำให้อะไรเป็นไปได้ และกระบวนการของพวกเขาเปลี่ยนอย่างไร ผู้บริหารสนใจต้นทุน ความเสี่ยง เวลา ผลกระทบต่อองค์กร และการตัดสินใจนี้เปิดหรือปิดทางเลือกใด คุณไม่ได้เปลี่ยนความจริง คุณเปลี่ยนระดับของนามธรรม ถ้าวิธีเดียวที่คุณอธิบายเทคโนโลยีได้คือใช้คำศัพท์จากเอกสารของมัน ก็ให้ทำความเข้าใจต่อไป

8. จะดูแลรักษามันในระยะยาวอย่างไร?

โปรเจกต์จบลง แต่ระบบไม่จบ หรืออย่างน้อยเราก็หวังว่าจะไม่จบ ต้องมีใครสักคนเป็นเจ้าของสิ่งที่เราสร้างหลังจากทีมโปรเจกต์จากไป นั่นหมายถึงการรู้ว่ามันถูกเฝ้าติดตาม อัปเกรด และแก้ไขปัญหาอย่างไร ใครต้องมีทักษะในการซัพพอร์ต การเปลี่ยนแปลงถูก deploy และทดสอบอย่างไร และจะเกิดอะไรขึ้นเมื่อเทคโนโลยีพัฒนาไปหรือ Salesforce เปลี่ยนบางอย่างข้างใต้เรา ลองนึกภาพอีกสามปีข้างหน้า ผมเคยเห็นสถาปัตยกรรมที่ฉลาดมากในวันเปิดตัวแต่ทรมานในการดูแลหลังจากนั้น นั่นไม่ใช่ความสำเร็จ ความสามารถในการดูแลรักษาเป็นส่วนหนึ่งของสถาปัตยกรรม

9. มีต้นทุนเท่าไร ต้องใช้สิทธิ์การใช้งานแบบไหน และมีข้อจำกัดอะไร?

นี่คือคำถามที่ผมเพิ่มเข้าไปในแปดข้อเดิม และทุกวันนี้ผมคิดว่าไม่สามารถตัดมันออกได้ เทคโนโลยีอาจเป็นโซลูชันทางเทคนิคที่สมบูรณ์แบบแต่ยังเป็นโซลูชันเชิงสถาปัตยกรรมที่ผิด ถ้าเรื่องเศรษฐศาสตร์ไม่ลงตัว มันรวมอยู่ในสิทธิ์การใช้งานที่เรามี หรือเป็นส่วนเสริม? คิดสิทธิ์ตามผู้ใช้ การใช้งาน การบริโภค พื้นที่จัดเก็บ หรือทรานแซกชัน? ต้นทุนจะเป็นอย่างไรเมื่อเราขยายขนาด?

แล้วก็มีข้อจำกัด ซึ่งทุกแพลตฟอร์มมี: ข้อจำกัดของ API พื้นที่จัดเก็บ คิวรี ทรานแซกชัน การทำงานพร้อมกัน ปริมาณงาน และสิทธิ์การใช้งาน บางข้อตายตัว บางข้อยืดหยุ่น บางข้อขยายได้และบางข้อไม่ได้ บางข้อไม่สำคัญที่ขนาดของเราจนกว่าจะเพิ่มเลขศูนย์อีกตัว คุณไม่ต้องท่องจำทุกข้อจำกัดของ Salesforce และการทำเช่นนั้นเป็นการใช้เวลาที่แย่มาก คุณต้องรู้ว่ามีข้อจำกัดอยู่ ข้อไหนสำคัญต่อสถาปัตยกรรมของคุณ และเมื่อไรควรไปตรวจสอบตัวเลขปัจจุบัน ตัวเลขจะเปลี่ยน แต่คำถามเชิงสถาปัตยกรรมยังคงอยู่

ตัวอย่างจริง: Apex sharing

นี่คือหนึ่งในตัวอย่างที่ผมใช้บ่อยที่สุดของคำถามเหล่านี้ในการทำงาน เราได้รับความต้องการการแชร์ที่ซับซ้อน ซึ่งไม่สามารถทำได้ด้วยกฎการแชร์แบบอิงเจ้าของหรือแบบอิงเกณฑ์ใดๆ นั่นนำเราไปสู่ Apex sharing: โค้ดที่เขียนเรกคอร์ดการแชร์เอง ตอนนี้เราจึงต้องรู้ว่า Apex sharing คืออะไร ใช้ที่ไหน ใช้อย่างไร และข้ออื่นๆ มันคือการยกระดับ: Apex sharing คือทางเลือก (คำถามที่ 4) เมื่อกฎที่เราต้องการเกินกว่าที่การแชร์แบบอิงเจ้าของและอิงเกณฑ์จะแสดงออกได้

ทีนี้มาดูจุดอ่อน (คำถามที่ 6) สมมติว่าเรามี customer community ที่มีสมาชิก 10 หรือ 20 ล้านคน และเราใช้สิทธิ์ Customer Community ไม่ใช่ Customer Community Plus ผู้ใช้เหล่านั้นเป็นผู้ใช้ปริมาณสูง (high-volume) พวกเขาไม่มีบทบาท และไม่ได้ใช้โมเดลการแชร์เลย: การเข้าถึงของพวกเขามาจาก sharing set และ share group ซึ่งจับคู่ผ่านบัญชีและผู้ติดต่อของพวกเขา ไม่มีเรกคอร์ดการแชร์ให้ Apex เขียนให้พวกเขา Apex sharing จึงใช้ไม่ได้กับพวกเขา และคำถามเรื่องต้นทุนและสิทธิ์การใช้งาน (คำถามที่ 9) ก็คือสิ่งที่พาเรามาถึงจุดนั้น: การเลือกสิทธิ์การใช้งานเป็นตัวตัดสินว่ามีเครื่องมือการแชร์อะไรให้ใช้บ้าง

ดังนั้นเช่นเดียวกับที่ Apex sharing เป็นทางเลือกแทนกฎแบบอิงเจ้าของและอิงเกณฑ์ คุณอาจเจอกรณีที่ต้องหาทางเลือกแทน Apex sharing และ ณ จุดนั้นแทบไม่มีตัวเลือกแบบตั้งค่าสำหรับกฎการแชร์ที่ซับซ้อนเลย สุดท้ายคุณต้องทำให้ออบเจกต์เป็นแบบอ่านอย่างเดียว และควบคุมการเข้าถึงผ่าน Apex นั่นคือเหตุผลที่คุณต้องถามทั้งเก้าข้อก่อนเลือก ไม่ใช่หลังเลือก

อย่าท่องจำแพลตฟอร์ม

เรื่องนี้สำคัญที่สุดเมื่อคุณกำลังเรียนสถาปัตยกรรม Salesforce อย่าพยายามท่องจำ Salesforce คุณทำไม่ได้: แพลตฟอร์มใหญ่เกินไปและเปลี่ยนเร็วเกินไป ผมทำงานกับ Salesforce มานาน และผมยังเรียนรู้อยู่ นั่นเป็นเรื่องปกติ

สิ่งที่ผมอยากให้คุณพัฒนาคือกรอบคิดสำหรับการเรียนรู้ เมื่อ Salesforce ออกความสามารถใหม่พรุ่งนี้ ผมไม่จำเป็นต้องเคยเห็นมันมาก่อน ผมรู้ว่าควรถามอะไร: มันคืออะไร เข้ากับตรงไหน ใช้อย่างไร ใช้อะไรแทนได้บ้าง เก่งอะไร ติดขัดตรงไหน อธิบายอย่างไร ดูแลอย่างไร และมีต้นทุนเท่าไรกับข้อจำกัดอยู่ที่ไหน? ตอนนี้ผมเริ่มประเมินมันได้แล้ว นั่นมีค่ากว่าการท่องตารางฟีเจอร์อีกชุดมาก

นอกเหนือจากการสอบ: AI ทำให้ตอบคำถามเก้าข้อได้เร็วขึ้น และผิดได้ง่ายขึ้น เมื่อเจอเทคโนโลยีที่คุณไม่รู้จัก คุณขอให้ AI อธิบาย เปรียบเทียบสามแนวทาง ไล่ข้อจำกัดและรูปแบบความล้มเหลวที่พบบ่อย หรือโต้แย้งว่าไม่ควรใช้ได้ นั่นเป็นผู้ช่วยวิจัยที่น่าทึ่ง แต่มันอาจผิด ล้าสมัย หรือสับสนระหว่างผลิตภัณฑ์หรือรุ่นที่ชื่อคล้ายกันอย่างมั่นใจ สำหรับอะไรก็ตามที่ส่งผลต่อการตัดสินใจ ให้ตรวจสอบ: ตามไปดูแหล่งที่มา และเช็กเอกสาร ข้อจำกัด และสิทธิ์การใช้งานปัจจุบัน เชื่อใจแต่ตรวจสอบ (โมดูลที่ 7)

เรียนรู้คำถาม ไม่ใช่แค่คำตอบ

เราจะเจอเทคโนโลยีมากมายในหลักสูตรนี้ ผมไม่อยากให้คุณสะสมคำตอบ ผมอยากให้คุณฝึกถามคำถาม เมื่อเราพูดถึง big object ข้อมูลภายนอก Data 360 รูปแบบการผสานรวม หรือความสามารถด้าน AI ที่ Salesforce ออกมาหกเดือนหลังจากบทนี้ถูกเขียน ให้ถามคำถามเก้าข้อเดิม

คำตอบจะเปลี่ยน คำถามคงทน นั่นคือสิ่งที่ทำให้นี่เป็นกรอบคิดเชิงสถาปัตยกรรม ไม่ใช่คู่มือติวสอบ

รู้จักเครื่องมือของคุณ: มันเก่งอะไร ไม่เก่งอะไร ใช้อะไรแทนได้ มีต้นทุนเท่าไร และพังตรงไหน และรู้มากพอที่จะอธิบายการตัดสินใจให้คนที่ต้องอยู่กับมันเข้าใจ นั่นคือวิธีที่สถาปนิกเรียนรู้เทคโนโลยี

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• เครื่องมือหนึ่งเหมาะกับปัญหาหรือไม่ โดยตัดสินจากทั้งเก้าข้อ ไม่ใช่แค่ว่าตั้งค่าได้หรือไม่
• ทางเลือกอื่นคืออะไร และต้นทุน สิทธิ์การใช้งาน และข้อจำกัดของเครื่องมือมีความหมายอย่างไรที่ขนาดของคุณ
• ใครจะดูแลมัน และดูแลอย่างไร ในอีกสามปีข้างหน้า
• ข้อเท็จจริงใดเกี่ยวกับเครื่องมือที่ต้องตรวจสอบก่อนจะพึ่งพามัน

ศึกษาเพิ่มเติม

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ผู้ใช้ปริมาณสูง (สิทธิ์การใช้งาน External Apps, Customer Community, High Volume Customer Portal และ Authenticated Website) ไม่มีบทบาท การเข้าถึงของพวกเขามาจาก sharing set และ share group พวกเขาไม่สามารถถูกรวมในกฎการแชร์แบบอิงเจ้าของ และเรกคอร์ดที่พวกเขาเป็นเจ้าของไม่สามารถแชร์ด้วยตนเองได้
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ผู้ใช้ปริมาณสูง (Customer Community, High Volume Customer Portal, Authenticated Website) ไม่ใช้โมเดลการแชร์ เพราะสิทธิ์ของพวกเขาไม่รองรับบทบาท การเข้าถึงทำงานโดยจับคู่ผู้ใช้กับ lookup ของ Account และ Contact ผ่าน sharing set หรือ share group หน้าเดียวกันระบุว่าเมื่อไร Apex managed sharing จึงเป็นเครื่องมือที่ถูกต้อง
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), คำถามใน Trailblazer Community พฤศจิกายน 2024 (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ผู้ปฏิบัติงานรายหนึ่งรายงานว่าการแทรกเรกคอร์ดการแชร์ให้ผู้ใช้ปริมาณสูงล้มเหลวพร้อมข้อผิดพลาด เป็นรายงานจากภาคสนาม ไม่ใช่เอกสารทางการ (Trailblazer Community ออนไลน์จะกลายเป็นแบบอ่านอย่างเดียวในวันที่ 30 ตุลาคม 2026 ลิงก์อาจเปลี่ยน)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09): sharing set ให้สิทธิ์เข้าถึงเรกคอร์ดที่เกี่ยวข้องกับบัญชีหรือผู้ติดต่อของผู้ใช้