ระบบรอบ Salesforce

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

โมดูลที่ 3 จาก 6 ในบท ทำความเข้าใจข้อมูลองค์กร บทที่ 4 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ประเภทของข้อมูลองค์กร · ถัดไป: วาดภาพรวมระบบ

คำถามที่โมดูลนี้ตอบ: อะไรอยู่รอบ Salesforce และแต่ละระบบมีบทบาทอะไร?

โมดูลที่แล้วจัดประเภทข้อมูล ตอนนี้ผมอยากวางมันไว้ที่ไหนสักแห่ง และนี่คือจุดที่สถาปนิก Salesforce เจอปัญหา เรารู้จัก Salesforce ข้อมูลลูกค้าจึงหมายถึงบัญชี ข้อมูลคำสั่งซื้อหมายถึง Order เอกสารหมายถึง Files การวิเคราะห์หมายถึง Reports แต่องค์กรไม่ได้ซื้อ Salesforce มาแทนทุกอย่างที่มีอยู่ อาจมี ERP ที่ดูแลการเงินและการส่งมอบ คลังข้อมูลที่มีประวัติหลายปี แพลตฟอร์มการผสานรวม ผู้ให้บริการตัวตน ระบบของพันธมิตร แพลตฟอร์มเหตุการณ์ แพลตฟอร์ม MDM และ Data 360 ที่เชื่อมหลายระบบเข้าด้วยกัน งานไม่ใช่การท่องจำเทคโนโลยี มันคือการเข้าใจว่าแต่ละระบบมีงานอะไร

อย่าเริ่มจากชื่อผลิตภัณฑ์

“เรามี SAP” บอกผมได้ไม่พอ Snowflake, MuleSoft, Tableau หรือ Data 360 ก็เช่นกัน ผมอยากรู้ว่าระบบนั้นทำอะไรในสถาปัตยกรรมนี้: เป็นเจ้าของข้อมูลอะไร อ่านอะไร เปลี่ยนอะไร ใครใช้ อะไรพึ่งพามัน จะเกิดอะไรขึ้นเมื่อมันล่ม สองบริษัทอาจมีผลิตภัณฑ์เหมือนกันทุกตัวและมีสถาปัตยกรรมต่างกันโดยสิ้นเชิง

ผมจึงติดป้ายระบบตามบทบาท สี่บทบาทครอบคลุมเกือบทั้งหมด:

• ระบบต้นทางหลัก (system of record): ที่ที่เวอร์ชันที่มีอำนาจชี้ขาดของบางสิ่งถูกดูแล
• ระบบปฏิสัมพันธ์ (system of engagement): ที่ที่คนทำงาน
• ระบบอ้างอิง (system of reference): ที่ที่ระบบหนึ่งไปหาข้อมูลที่ต้องใช้แต่ไม่ได้เป็นเจ้าของ
• ระบบเชิงวิเคราะห์ (system of insight): ที่ที่ข้อมูลมารวมกันเพื่อวัด วิเคราะห์ และคาดการณ์

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

ERP: ระบบหลังบ้านมีแรงโน้มถ่วง

ERP คือระบบที่คุณจะเจออยู่ข้าง Salesforce บ่อยที่สุด ดูแลการเงิน สินค้าคงคลัง การจัดซื้อ การส่งมอบ และการเรียกเก็บเงิน รูปแบบของโมดูลที่ 1 (ลูกค้าและสินค้าเข้า คำสั่งซื้อออก) หมายความว่า ERP เป็นเจ้าของสินค้า แต่พนักงานขายยังต้องการมันใน Salesforce ก็ได้ นำเข้ามา แต่การคัดลอกข้อมูลไม่ได้โอนความเป็นเจ้าของ สำเนาไม่ใช่อำนาจชี้ขาด

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

คลังข้อมูล Data Lake และ Lakehouse

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

คุณจะเจอที่เก็บข้อมูลเชิงวิเคราะห์สามแบบ คลังข้อมูล (data warehouse) เก็บข้อมูลแบบมีโครงสร้างที่เตรียมไว้สำหรับการวิเคราะห์ Data lake เก็บข้อมูลมากกว่ามากในรูปแบบที่หลากหลายกว่า มักเป็นข้อมูลดิบ Lakehouse รวมสองอย่าง: การจัดเก็บแบบ lake กับการวิเคราะห์แบบคลังข้อมูล รู้จักมันไว้ เพราะมันปรากฏบนภาพรวมระบบ แต่ประสบการณ์ของผมคือ lakehouse และ data mesh ยังเป็นเรื่องเฉพาะกลุ่มในโปรเจกต์ Salesforce ภาพรวมระบบทั่วไปคือ CRM, ERP คลังข้อมูล และชั้นการผสานรวม พร้อมแพลตฟอร์มอื่นในที่ที่ธุรกิจต้องการจริงๆ เรียนรู้สถาปัตยกรรม อย่าไล่ตามคำศัพท์

การวิเคราะห์อยู่ที่ที่ข้อมูลอยู่

นี่คือหนึ่งในจุดยืนที่หนักแน่นที่สุดของผม: การวิเคราะห์อยู่ที่ไหนขึ้นกับว่าข้อมูลอยู่ที่ไหน ถ้ารายงานต้องการแค่บัญชี โอกาสทางการขาย และพนักงานขาย ทั้งหมดอยู่บน core: รายงานและแดชบอร์ดมาตรฐาน แล้วธุรกิจขอเพิ่มใบแจ้งหนี้จาก ERP แล้วต้นทุนสินค้า แล้วคำสั่งซื้อห้าปีจากคลังข้อมูล แล้วกิจกรรมบนเว็บไซต์ ถึงจุดหนึ่ง การลากทั้งหมดนั้นเข้า CRM เชิงปฏิบัติการเพียงเพื่อทำรายงานก็ไม่สมเหตุสมผลอีกต่อไป เมื่อที่เก็บข้อมูลอื่นเข้ามาเกี่ยว แพลตฟอร์มการวิเคราะห์ก็จำเป็น: Tableau (รวมถึง Tableau Next ที่สร้างบน Data 360) หรือ CRM Analytics ในที่ที่ใช้อยู่แล้ว และขาดไม่ได้เมื่อข้อมูล Salesforce ถูกรวมเข้ากับคลังข้อมูล ความต้องการไม่ได้แค่ซับซ้อนขึ้น ภาพรวมระบบเปลี่ยนที่ที่คำถามควรถูกตอบ ดังนั้นผมไม่เคยเริ่มด้วย “เครื่องมือวิเคราะห์ตัวไหน?” ผมเริ่มด้วย ข้อมูลอยู่ที่ไหน?

ผมถามผู้สมัคร CTA แบบเดียวกัน: “ไดอะแกรมไหนของผมแก้ปัญหานี้ได้สวยงาม? ภาพรวมระบบ” ถ้าทุกอย่างอยู่บน core ใช้รายงาน ถ้าคุณมีข้อมูลในที่เก็บอื่น ผมอยากเห็นแพลตฟอร์มการวิเคราะห์ ภาพรวมระบบตอบคำถามเรื่องรายงานได้ก่อนที่ใครจะเปิดตัวสร้างรายงานเสียอีก (ชื่อผลิตภัณฑ์เปลี่ยนไปเรื่อยๆ บท Data 360 ครอบคลุมว่าการวิเคราะห์ของ Salesforce อยู่ตรงไหนในวันนี้)

MDM: ลูกค้ารายนี้คือใครกันแน่?

ทีนี้สมมติว่าข้อมูลลูกค้าอยู่ใน Salesforce, ERP อีคอมเมิร์ซ แพลตฟอร์มสะสมแต้ม และระบบของพันธมิตร และแต่ละระบบคิดว่ามันรู้ว่าลูกค้าคือใคร นั่นคือที่ที่ การจัดการข้อมูลหลัก (master data management) เข้ามา: การสร้างและกำกับดูแลตัวตนที่มีอำนาจชี้ขาดของข้อมูลสำคัญข้ามระบบ แต่ MDM ไม่ใช่ “ฐานข้อมูลลูกค้าหลัก” คำถามยากคือระบบใดสร้างลูกค้าได้ แต่ละระบบเป็นเจ้าของแอตทริบิวต์ใด หาข้อมูลซ้ำอย่างไร ตัวระบุใดคงอยู่ และจะเกิดอะไรขึ้นเมื่อระบบไม่ตรงกัน บทที่ 6 พูดถึงเรื่องนั้นทั้งบท ตรงนี้ให้จำบทบาทได้: ถ้ามีแพลตฟอร์ม MDM อยู่ มันอาจเป็นผู้มีอำนาจชี้ขาดสำคัญระหว่าง Salesforce กับส่วนที่เหลือขององค์กร

ชั้นการผสานรวมและเหตุการณ์

เชื่อมทุกระบบเข้ากับทุกระบบโดยตรง แล้วภาพรวมระบบจะกลายเป็นสปาเกตตีอย่างรวดเร็ว นั่นคือเหตุผลที่องค์กรมีชั้นการผสานรวม: ESB (enterprise service bus) หรือ iPaaS (integration platform as a service) MuleSoft คือตัวที่คุณจะเจอบ่อยที่สุดในภาพรวมระบบ Salesforce มันเป็นตัวกลาง เพื่อที่แต่ละแอปพลิเคชันจะไม่ต้องเข้าใจทุกแอปพลิเคชันอื่น

แต่กล่อง MuleSoft ตรงกลางไม่ได้ทำให้การผสานรวมดี ผมยังอยากรู้ว่าอะไรผ่านมันและอะไรไม่ผ่าน ใครแปลงข้อมูล ใครเป็นเจ้าของสัญญา จะเกิดอะไรขึ้นเมื่อปลายทางล่ม เป็นแบบ synchronous หรือ asynchronous และเรารู้ได้อย่างไรว่าข้อความสำเร็จ หลักสูตร Integration Architect ลงลึก ตรงนี้ให้จำได้ว่ามันเป็นบทบาทของตัวเอง

และไม่ใช่ทุกการผสานรวมจะเป็นระบบ A เรียกระบบ B บางครั้งบางอย่างเกิดขึ้น (คำสั่งซื้อถูกสร้าง การจัดส่งเปลี่ยนสถานะ รถบรรทุกข้ามเข้าภูมิภาคหนึ่ง) เหตุการณ์ (event) ถูกเผยแพร่ และใครที่สนใจก็ตอบสนอง เหตุการณ์ที่กำลังเคลื่อนที่ก็มีโครงสร้างพื้นฐานเช่นกัน: ความสามารถด้านเหตุการณ์ของ Salesforce เอง event bus ระดับองค์กร ระบบส่งข้อความอื่นๆ วาดกลไกที่นำข้อมูลไป ไม่ใช่แค่ฐานข้อมูล

ระบบที่นักพัฒนาลืม: ตัวตน

มีกล่องหนึ่งที่ผมอยากให้อยู่บนภาพรวมระบบเสมอซึ่งนักพัฒนาแทบไม่เคยนึกถึง: ผู้ให้บริการตัวตน นักพัฒนาล็อกอินเข้า sandbox ตรงๆ ด้วยชื่อผู้ใช้และรหัสผ่าน ตัวตนจึงมองไม่เห็นระหว่างการสร้าง แล้ว UAT หรือ production ก็มาถึง และทันใดนั้นก็มี single sign-on ของบริษัทสำหรับพนักงาน อาจมีผู้ให้บริการรายที่สองสำหรับพันธมิตร การล็อกอินผ่านโซเชียลสำหรับลูกค้า ตัวตนเป็นส่วนหนึ่งของสถาปัตยกรรมมาตลอด นักพัฒนาแค่ยังไม่เห็นมัน

ผู้ให้บริการตัวตน (IdP) คือระบบที่ยืนยันตัวตนผู้ใช้และกำหนดตัวตนที่ Salesforce ไว้วางใจ มันควรอยู่บนภาพรวมระบบตั้งแต่วันแรก แม้จะถูกตั้งค่าทีหลังใน release pipeline เพราะใครเข้ามาได้เป็นตัวกำหนดว่าใครเข้าถึงข้อมูลได้

ยังมีรายละเอียดเชิงปฏิบัติอีกข้อ: การตั้งค่าตัวตน deploy ได้ แต่ไม่ทั้งหมด การตั้งค่า SAML single sign-on และ authentication provider เป็นประเภทของ Metadata API จึงเดินทางผ่าน pipeline ได้ (SamlSsoConfig (opens in a new tab) ภาษาอังกฤษ) แต่ consumer secret ของ authentication provider ไม่ถูกส่งกลับมาในการตอบกลับของ Metadata API อีกต่อไป (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) ภาษาอังกฤษ) และใบรับรองมักต่างกันในแต่ละสภาพแวดล้อม วางแผนสำหรับส่วนที่เดินทางได้และส่วนที่เดินทางไม่ได้

Click to enlarge

อ่านภาพรวมระบบเป็นบทบาท ไม่ใช่โลโก้: แต่ละระบบเป็นเจ้าของอะไร อ่านอะไร หรือตัดสินใจอะไร

Data 360 อยู่ตรงไหน?

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

ผู้ดูแลระบบและทีมข้อมูลเปิดหน้าจอของ Data 360 ก็จริง แต่หน้าจอเหล่านั้นอยู่ใน org บน core tenant ที่ทำงานจริง ทั้งข้อมูลและการประมวลผลของมัน รันอยู่นอก core นั่นคือเหตุผลที่ผมเรียกมันว่า near-core (ใกล้ core): จัดการบน core โฮสต์นอก core (โมดูลที่ 1 อธิบายคำเหล่านี้) การวาดยึดตาม tenant: มันอยู่กับท่อข้อมูล โดยมีเส้นหนึ่งเส้นกลับไปยัง org ที่จัดการมัน

สิ่งที่มันทำ ตามคำของ Salesforce รวมถึง zero copy: เทคโนโลยี data federation ที่ให้องค์กรเข้าถึงและ query ข้อมูลโดยไม่ต้องคัดลอก (Zero Copy (opens in a new tab) ภาษาอังกฤษ) ความสามารถและตัวเชื่อมต่อเปลี่ยนเร็ว บท Data 360 จึงครอบคลุมมันอย่างเหมาะสม แทนที่จะทำให้โมดูลนี้เป็นทัวร์ผลิตภัณฑ์

อ่านภาพรวมระบบเป็นความรับผิดชอบ

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

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

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

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

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

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce, Zero Copy (opens in a new tab) (หน้าผลิตภัณฑ์ ภาษาอังกฤษ ตรวจสอบเมื่อ 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 (ภาษาอังกฤษ)