วาดภาพรวมระบบ

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

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

คำถามที่โมดูลนี้ตอบ: ผมจะวาดภาพรวมระบบที่แสดงว่าข้อมูลไปที่ไหนได้อย่างไร?

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

เริ่มจากผ้าใบว่างเปล่า

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

เริ่มจากภาพสูง แล้วค่อยเจาะลึก: ทั้งองค์กรก่อน แล้วจึงรายละเอียดในจุดที่สำคัญ

Click to enlarge

ขั้นที่ 1 จาก 6: ผ้าใบว่างเปล่า มีแค่โซน

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

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

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

Click to enlarge

ขั้นที่ 2 จาก 6: ใครกำลังพยายามเข้าถึงสถาปัตยกรรมนี้?

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

คอมมูนิตี้อยู่ใต้มันพอดี ติดกัน คอมมูนิตี้พันธมิตรและคอมมูนิตี้ลูกค้าเป็น endpoint แยกกัน จึงได้กล่องของตัวเอง แต่มันวางชิด Salesforce เพราะไม่ต้องผสานรวมอะไรเพื่อเข้าถึงมัน: มันรันอยู่ใน org เดียวกัน

Click to enlarge

ขั้นที่ 3 จาก 6: Salesforce อยู่ตรงกลาง คอมมูนิตี้อยู่ใต้มันพอดี

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

Click to enlarge

ขั้นที่ 4 จาก 6: ตัวตนอยู่ด้านบน กล่องที่นักพัฒนาลืม

การผสานรวม แล้วจึงระบบหลังบ้าน อยู่ทางขวา ชั้นการผสานรวม ESB หรือ iPaaS (หรือ MuleSoft เมื่อระบุชื่อ) เป็นแท่งสูงอยู่ถัดจาก Salesforce ทางขวา ระบบภายในอยู่ด้านหลังมัน: ERP การเงิน การจัดการคำสั่งซื้อ ระบบเก่า คลังข้อมูล ตอนนี้หน้ากระดาษอ่านจากซ้ายไปขวา: คน Salesforce การผสานรวม ระบบหลังบ้าน

Click to enlarge

ขั้นที่ 5 จาก 6: การผสานรวม แล้วจึงระบบหลังบ้าน

ช่องทางอยู่ด้านล่าง อะไรก็ตามที่มีเส้นตรงไปถึงลูกค้า: email-to-case, web-to-lead, โทรศัพท์ การส่งข้อความ

ข้อมูลเข้าและออก ที่มุมขวาล่าง แหล่งข้อมูลภายนอก ที่เก็บถาวร การโหลดข้อมูล

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

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

Click to enlarge

ขั้นที่ 6 จาก 6: รูปแบบทั้งหมด ยังไม่มีลูกศร ภาพรวมระบบทุกภาพหลังจากนี้คงตำแหน่งเหล่านี้ไว้

การ์ดในโซน

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

อย่าใส่อะไรไว้ในกล่องมากเกินไป เฉพาะภาพรวมระบบที่ซับซ้อนมากๆ เท่านั้นที่ผมจะเปิด Salesforce ออกเป็นส่วนย่อย (Sales Cloud และ Service Cloud ภายใน org พร้อมลูกศรระหว่างกัน) และอย่าประดิษฐ์รูปทรงสิบห้าแบบ เว้นแต่แต่ละแบบจะบอกอะไรบางอย่างแก่ผู้อ่าน ผมอยากให้ใครสักคนมองภาพรวมระบบสามสิบวินาทีแล้วเริ่มเข้าใจสถาปัตยกรรม ความหรูหราไม่ได้ช่วย ความชัดเจนช่วย

ใส่เลขศูนย์ลงในบัญชีรายการ

อย่ารอถึงการออกแบบรายละเอียดแล้วค่อยคิดเรื่องปริมาณ ลูกศรที่ขนสินค้า 500 รายการต่อคืน กับลูกศรที่ขนค่า GPS 200,000 ค่าต่อวัน อาจดูเหมือนกันทุกประการบนภาพรวมระบบ แต่มันไม่ใช่ปัญหาเดียวกัน ดังนั้นก่อนที่คุณจะวาดลูกศรสักเส้น ให้นับสิ่งที่เคลื่อนย้าย เริ่มบัญชีรายการเบื้องหลังภาพด้วยตัวเลขเหล่านั้น: หนึ่งแถวต่อชุดข้อมูลสำคัญ พร้อมปริมาณของมัน เลขศูนย์อาจไม่เคยปรากฏบนลูกศร แต่คุณต้องรู้ว่าเมื่อไรคุณข้ามเข้าสู่ตัวเลขสูง: หลักพันหรือหลักล้านในหนึ่งชั่วโมง ธุรกรรมหลักแสน หรือแม้แต่หลายสิบถึงหลายร้อยธุรกรรมต่อวินาที

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

กลไกเปลี่ยนทิศทางของลูกศรได้ด้วยซ้ำ ส่งเรกคอร์ดสองสามรายการต่อนาที Salesforce ก็แค่เรียกออกไป: ลูกศรเริ่มที่ Salesforce ส่งมากกว่านั้นมาก Salesforce อาจเผยแพร่ event บน event bus แทน ระบบภายนอกสมัครรับและเรียกเข้ามาเพื่อดึงมัน ตอนนี้ลูกศรจึงเริ่มที่อีกฝั่ง ใหญ่ขึ้นอีก สมมติการซิงก์เรกคอร์ดหลายล้านรายการทุกคืน มันก็เป็นกระบวนการ batch ดังนั้นรู้ตัวเลขของคุณตั้งแต่เนิ่นๆ เมื่อคุณเริ่มออกแบบกลไก เพราะตัวเลขวาดลูกศรใหม่ได้

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

ทีนี้วาดลูกศร

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

กฎนั้นใช้กับภาพรวมระบบ ที่ซึ่งระบบคุยกับระบบ บนไดอะแกรมการไหลของข้อมูล (data-flow) ลูกศรตามข้อมูลไป อย่างที่คุณคาดไว้ อย่าพากฎของภาพรวมระบบไปใช้กับไดอะแกรมอื่น มันมีแต่จะเพิ่มความสับสน

Click to enlarge

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

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

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

ทุกลูกศรต้องมีกลไก

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

• ยืนยันตัวตนอย่างไร? OAuth ใบรับรอง named credential หรืออย่างอื่น?
• เป็นแบบ synchronous หรือ asynchronous? Salesforce รอ ERP หรือเผยแพร่แล้วทำงานต่อ? ธุรกิจต้องการผลลัพธ์เร็วแค่ไหน?
• กลไกคืออะไร? การเรียก REST เหตุการณ์ ไฟล์ คิวข้อความ ผ่าน MuleSoft หรือตรง?

แล้วก็: จะเกิดอะไรขึ้นเมื่ออีกฝั่งล่ม? ทุกลูกศรต้องมีกลไก ถ้าคุณอธิบายไม่ได้ เส้นนั้นก็เป็นแค่ของตกแต่ง

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

ซูมเข้าไปที่ลูกศรเส้นใดเส้นหนึ่ง แล้วจะมี client และ server และแต่ละฝั่งเป็นเจ้าของครึ่งของตัวเอง client เปิดการเชื่อมต่อ: มันต้องรู้ endpoint และพอร์ต ขอ token จาก authentication server ก่อน เรียกโปรโตคอลและสัญญา (contract) ที่ server กำหนด และเลือกว่าจะรอหรือไม่ มีแต่ client ที่เห็นการเดินทางไปกลับทั้งหมด จึงมีแต่ client ที่ลองใหม่ (retry) ได้ server รอฟัง กำหนดโปรโตคอล สัญญา และ payload ตรวจสอบสิ่งที่เข้ามา และเห็นแค่ส่วนของตัวเอง เมื่อผมวาดลูกศร ผมรู้อยู่แล้วว่าปลายไหนเป็นอะไร และนั่นบอกผมว่าใครเป็นเจ้าของคำถามแต่ละข้อเหล่านี้

Click to enlarge

ลูกศรหนึ่งเส้น ซูมเข้าไป: client จัดการ server กำหนด ไม่มีสิ่งใดในนี้อยู่บนภาพรวมระบบ แต่ลูกศรทุกเส้นมีมัน

ทีนี้กลับลูกศร เมื่อ ERP เรียก Salesforce, Salesforce คือ server: มันกำหนด API รัน authorization server ของตัวเอง และตัดสินผ่าน External Client App และผู้ใช้สำหรับการผสานรวมว่าผู้เรียกทำอะไรได้บ้าง คำถามเดิม อีกฝั่ง

Click to enlarge

Salesforce ในฐานะ server: คำถามเดิม โดย Salesforce ตอบครึ่งของฝั่ง server

ลูกศรบนภาพรวมระบบ บทสนทนาใน swim lane

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

เมื่อผมต้องอธิบายปฏิสัมพันธ์ ผมวาดไดอะแกรมที่สอง แต่ไม่ใช่สำหรับทุกการผสานรวม ถ้าระบบ A ส่งบางอย่างไปยัง B หรือแม้แต่ถามแล้วได้คำตอบ ลูกศรที่มีป้ายก็พอ ผมต้องการ swim lane เมื่อกระบวนการกลายเป็นบทสนทนา: A เรียก B, B ตรวจกับ C, C ตอบ B สร้างบางอย่างแล้วเรียก A กลับ คนอนุมัติ อีกระบบทำงานต่อ หลักง่ายๆ ของผม: โต้ตอบไปมามากกว่าหนึ่งหรือสองครั้ง ลำดับนั้นก็ได้ swim lane ของตัวเอง ลูกศรอยู่บนภาพรวมระบบ บทสนทนาอยู่ใน swim lane

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

Click to enlarge

ลูกศรสามเส้นบนภาพรวมระบบ หกขั้นใน swim lane บนภาพรวมระบบ ลูกศรคือการเชื่อมต่อ ใน swim lane ลูกศรแต่ละเส้นคือหนึ่งข้อความ ตามลำดับ

เดินตามทุกลูกศร

เมื่อภาพรวมระบบดูเกือบเสร็จ ให้เดินตามมันทีละลูกศร ERP ไป Salesforce: อะไรเคลื่อนที่ ใครเป็นเจ้าของ ยืนยันตัวตนอย่างไร กลไกคืออะไร sync หรือ async ต้องใหม่แค่ไหน? แล้วลูกศรถัดไป และถัดไป นี่คือจุดที่ช่องโหว่ปรากฏ “อ้อ เราไม่เคยคิดว่าพันธมิตรส่งสิ่งนั้นมาจริงๆ อย่างไร” “เราส่งคำสั่งซื้อไปยัง ERP แต่ยังไม่ได้ออกแบบว่าคำสั่งที่ถูกปฏิเสธจะกลับมาอย่างไร” ดีแล้ว คุณเจอมันบนไวต์บอร์ดแทนที่จะเจอใน production

วางบัญชีรายการไว้เบื้องหลังภาพ

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

คอลัมน์	สิ่งที่ผมอยากรู้
ชุดข้อมูล	ลูกค้า สินค้า คำสั่งซื้อ การจัดส่ง ใบแจ้งหนี้
ประเภท	ข้อมูลหลัก ข้อมูลอ้างอิง ข้อมูลธุรกรรม ข้อมูลเชิงวิเคราะห์ ข้อมูลไม่มีโครงสร้าง
เจ้าของ	ใครเป็นเจ้าของความหมายและวงจรชีวิตของมัน?
ระบบต้นทางหลัก	เวอร์ชันที่มีอำนาจชี้ขาดอยู่ที่ไหน?
ภาระงาน	เชิงปฏิบัติการ เชิงวิเคราะห์ สตรีมมิง
ปริมาณ	จำนวนเลขศูนย์
Org	org Salesforce ตัวไหน ถ้ามีหลายตัว?
การยืนยันตัวตน	การเชื่อมต่อสร้างความไว้วางใจอย่างไร?
กลไกและจังหวะเวลา	API เหตุการณ์ ไฟล์ federation; sync, async, batch
แนวทาง	คัดลอก อ้างอิง หรือ federate?

ตอนนี้มีสองสิ่ง: ภาพรวมระบบให้ผมเห็นสถาปัตยกรรม และบัญชีรายการให้ผมซักถามมัน

Click to enlarge

บัญชีรายการเบื้องหลัง ED-D42 ลูกศรดูเหมือนกันบนภาพรวมระบบ ปริมาณเป็นตัวตัดสินว่าอะไรขนแต่ละเส้น

ภาพรวมระบบตอบคำถาม

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

วาดสถานะปัจจุบันก่อนแก้มัน

อีกวินัยหนึ่ง ในองค์กรที่มีอยู่แล้ว ให้วาดสิ่งที่มีอยู่ ไม่ใช่สิ่งที่คุณอยากให้มี สเปรดชีตที่ส่งอีเมลทุกวันศุกร์: วาดมัน CSV ของพันธมิตรบนเซิร์ฟเวอร์ SFTP: วาดมัน การผสานรวมที่ข้าม ESB ด้วยเหตุผลทางประวัติศาสตร์: วาดมัน คนที่กรอกข้อมูลซ้ำระหว่างสองระบบ: แสดงมัน อย่าทำความสะอาดความจริงขณะที่คุณกำลังบันทึกมัน คุณต้องมีภาพรวมระบบปัจจุบันก่อนออกแบบภาพเป้าหมาย และนั่นคือสิ่งที่เราทำสำหรับ Steve Trucking ในโมดูลที่ 6

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

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

• ระบบและกลุ่มผู้ใช้ใดควรอยู่บนภาพรวมระบบ และตำแหน่งของมันแสดงบทบาทอย่างไร
• โฟลว์ใดข้ามขอบเขตของระบบ ไปทางไหน และอะไรส่งกลับมา
• ทุกการเชื่อมต่อยืนยันตัวตนอย่างไร กลไกใดนำมันไป และเป็นแบบ synchronous, asynchronous, batch หรือ federated
• เมื่อไรลูกศรที่มีป้ายก็พอ และเมื่อไรปฏิสัมพันธ์ต้องมี swim lane ของตัวเอง
• บัญชีรายการเบื้องหลังภาพบันทึกอะไร: เจ้าของ ภาระงาน ปริมาณ org จังหวะเวลา การยืนยันตัวตน และคัดลอก อ้างอิง หรือ federate

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

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

• อ่านเพิ่มเติม: Salesforce Architects เผยแพร่แนวทางการวาดไดอะแกรมของตัวเอง How to Build Salesforce Diagrams (opens in a new tab) และ System Landscape (opens in a new tab) (ภาษาอังกฤษ) ควรรู้ไว้ถ้าคุณกำลังมุ่งหน้าสู่คณะกรรมการรีวิว CTA