วาดภาพรวมระบบก่อนออกแบบ org

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

บทที่ 4 ของ Data Architect ส่วนที่ 1: การเป็นสถาปนิกข้อมูล ก่อนหน้า: สถาปัตยกรรมข้อมูล Salesforce

เมื่อผมสอนผู้สมัคร CTA การบ้านหลังวันแรกเหมือนเดิมเสมอ อ่านสถานการณ์ เริ่มวาดภาพรวมระบบจากผ้าใบว่างเปล่า แล้วจากนั้นเท่านั้น จึงลองร่างโมเดลข้อมูล

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

บทที่ 2 และ 3 ออกแบบ org: โมเดลควรเป็นอะไร และอยู่บน Salesforce อย่างไร บทนี้ถอยกล้องออกมาแล้ววาดสิ่งที่อยู่รอบ org ก่อนที่ org จะถูกออกแบบ Salesforce เป็นหนึ่งในหลายระบบ และบ่อยครั้งมันไม่ใช่ระบบที่เป็นเจ้าของข้อมูล

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

แนวคิดในบทนี้

• ภาพรวมระบบมาก่อน หาระบบ แล้วหาข้อมูลที่เคลื่อนที่ระหว่างระบบ แล้วหาว่าใครเป็นเจ้าของแต่ละชิ้น จากนั้นเท่านั้นจึงตัดสินว่างานของ Salesforce คืออะไร
• ลูกศรหนึ่งพึ่งพาลูกศรอื่น คำสั่งซื้อที่ส่งออกไป ERP ต้องมีลูกค้า สินค้า และราคาเข้ามาก่อน เมื่อไรก็ตามที่ผมเห็นการผสานรวมที่มีโฟลว์เดียว ผมเริ่มกังวล
• ข้อมูลมีหลายประเภท และหลายภาระงาน ข้อมูลหลัก ข้อมูลอ้างอิง ข้อมูลธุรกรรม เมทาดาทา ข้อมูลเชิงวิเคราะห์ และข้อมูลไม่มีโครงสร้าง เปลี่ยนแปลง เติบโต และถูกใช้ต่างกัน ภาระงานเชิงปฏิบัติการ (OLTP) เชิงวิเคราะห์ (OLAP) และสตรีมมิงต้องการบ้านที่ต่างกัน org ขับเคลื่อนธุรกิจ คลังข้อมูลและ data lake วิเคราะห์มัน
• ระบบมีบทบาท ไม่ใช่แค่โลโก้ ระบบต้นทางหลัก ระบบปฏิสัมพันธ์ ระบบอ้างอิง ระบบเชิงวิเคราะห์ “Salesforce เป็นระบบต้นทางหลักของเรา”: สำหรับอะไร?
• การวิเคราะห์อยู่ที่ไหนก็ตามข้อมูลอยู่ที่นั่น ทั้งหมดอยู่บน core: ใช้รายงานมาตรฐาน ข้อมูลอยู่ในที่เก็บอื่น: ใช้แพลตฟอร์มการวิเคราะห์ และใช้คลังข้อมูลเมื่อข้อมูล Salesforce ถูกรวมเข้ากับมัน
• Data 360 เป็น near-core (ใกล้ core): จัดการบน core โฮสต์นอก core ผู้ใช้ไม่เคยเชื่อมต่อกับมัน มันจึงอยู่กับระบบท่อข้อมูล
• ข้อมูลที่ ERP เป็นเจ้าของถูกอ่านในเครื่องและเขียนภายใต้การควบคุม โดยมีคำนำหน้า erp_ เพื่อให้สคีมาแสดงว่าใครเป็นเจ้าของแต่ละฟิลด์
• บนภาพรวมระบบ ลูกศรเริ่มที่ระบบที่เปิดการเชื่อมต่อ และป้ายกำกับบอกว่าอะไรเคลื่อนที่และไปทางไหน สองโฟลว์คือลูกศรสองเส้น ลูกศรสองหัวใช้เฉพาะกับตัวเชื่อมต่อ (connector)
• ทุกลูกศรมีไคลเอนต์และเซิร์ฟเวอร์ และแต่ละฝั่งเป็นเจ้าของครึ่งของตัวเอง ไม่มีอะไรในนั้นอยู่บนภาพรวมระบบ แต่ทุกลูกศรมีมัน
• นับก่อนวาดลูกศร เลขศูนย์ไปอยู่ในบัญชีรายการ และมันเป็นตัวเลือกกลไก: batch, synchronous หรือเหตุการณ์
• กลยุทธ์ org คือการตัดสินใจระดับภาพรวมระบบ ทำในไม่กี่นาทีแรก: org เดียวหรือหลาย org และรันที่ไหน
• สถานะปัจจุบันแสดงว่าอะไรผิด สีแดงสำหรับกระบวนการที่แย่ เส้นประสำหรับงานที่ทำด้วยมือ จุดสีแดงสำหรับสิ่งที่ขาดหายไป

รูปแบบภาพรวมระบบของ Steve

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

ตำแหน่ง	อะไรอยู่ตรงนั้น
ซ้าย	คน จากบนลงล่าง: ผู้ใช้ภายใน พันธมิตร ลูกค้า
กลาง	Salesforce กล่องเรียบๆ หนึ่งกล่อง โดยมีชุมชน (community) ของมันแตะอยู่ด้านล่าง
บน	ผู้ให้บริการตัวตนอยู่เหนือ Salesforce AppExchange เลื่อนไปทางขวา เว็บไซต์สาธารณะอยู่มุมซ้ายบน
ขวา	ชั้นการผสานรวม แล้วจึงระบบภายใน: ERP การเงิน คลังสินค้า
ใต้ชั้นการผสานรวม	Data 360 ซึ่งเป็น near-core อยู่กับระบบท่อข้อมูล
ล่าง	ช่องทางลูกค้า: อีเมล เว็บฟอร์ม โทรศัพท์ การส่งข้อความ
มุมขวาล่าง	ข้อมูลเข้าและออก: การเก็บถาวร การโหลดข้อมูล แหล่งข้อมูลภายนอก พันธมิตร

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

Click to enlarge

ภาพรวมระบบของโมดูลที่ 4 พร้อมลูกศร

เส้นทางผ่านบทนี้

หกโมดูล แต่ละโมดูลอ่านแยกกันได้

1. Salesforce เป็นหนึ่งในหลายระบบ ทำไมภาพรวมระบบมาก่อนกล่อง การผสานรวมที่ผมเห็นซ้ำแล้วซ้ำเล่าและโฟลว์ย้อนกลับที่มันพึ่งพา ข้อมูลที่มาเป็นระลอก และ core, near-core และ Hyperforce
2. ประเภทของข้อมูลองค์กร หกประเภท ถูกสร้าง ถูกแก้ไข ถูกอ้างอิง OLTP และ OLAP เรียลไทม์ ใกล้เรียลไทม์ และ batch และคำถามสี่ข้อเบื้องหลังหมวดหมู่
3. ระบบรอบ Salesforce บทบาทของระบบ ERP คลังข้อมูล และ lakehouse การวิเคราะห์ตามข้อมูลไป MDM การผสานรวมและเหตุการณ์ ผู้ให้บริการตัวตนที่นักพัฒนาลืม และ Data 360 อยู่ตรงไหน
4. วาดภาพรวมระบบ รูปแบบของผม สร้างขึ้นจากผ้าใบว่างเปล่า เลขศูนย์ก่อนลูกศร ลูกศรที่เริ่มจากผู้เริ่มการเชื่อมต่อ ไคลเอนต์และเซิร์ฟเวอร์เบื้องหลังทุกลูกศร ทั้งสองทาง swim lane สำหรับการสนทนา และบัญชีรายการเบื้องหลังภาพ
5. กลยุทธ์ org คือการตัดสินใจระดับภาพรวมระบบ เริ่มจาก org เดียว อะไรทำให้มีอีก org สมเหตุสมผล ภูมิภาค ไม่ใช่ผู้ให้บริการ การแยกเป็น AMER และ EMEA เพราะ GDPR และ org ที่สองเพิ่มอะไรเข้ามา
6. ภาพรวมระบบของ Steve Trucking วันนี้ ก่อนการ implement อย่างเป็นเรื่องเป็นราว พร้อมเครื่องหมาย: ใบรายการสินค้าที่ไปลงใน RouteDesk เส้นทางที่ต้องพิมพ์ซ้ำเข้า Salesforce และกลับออกมาด้วยมือ เกาะข้อมูล GPS สเปรดชีตที่ป้อนฝ่ายการเงิน และสาย “การจัดส่งของฉันอยู่ไหน?” 108,000 สายต่อปี

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

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

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

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

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

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• อ่านเพิ่มเติมสำหรับผู้สมัคร CTA: Salesforce Architects เผยแพร่แนวทางการวาดไดอะแกรมของตัวเอง How to Build Salesforce Diagrams (opens in a new tab) (ภาษาอังกฤษ)

ถัดไป: คุณภาพและธรรมาภิบาลข้อมูล