การทดสอบความย้อนกลับได้

🌐 มีให้อ่านอีก 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 จาก 7 ในบท คิดแบบสถาปนิกข้อมูล ซึ่งเป็นบทแรกของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: โมเดลข้อมูลคือโครงกระดูก · ถัดไป: สถาปัตยกรรมคือศิลปะแห่งการแลกเปลี่ยนได้เสีย

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

สถาปนิกต้องตัดสินใจหลายเรื่อง

แต่ไม่ใช่ทุกการตัดสินใจจะเป็นการตัดสินใจเชิงสถาปัตยกรรม

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

แล้วเราจะแยกความแตกต่างได้อย่างไร?

ผมชอบถามคำถามง่ายๆ ข้อหนึ่ง:

การตัดสินใจนี้จะย้อนกลับยากแค่ไหนในภายหลัง?

ผมเรียกสิ่งนี้ว่าการทดสอบความย้อนกลับได้

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

การตัดสินใจบางอย่างเปลี่ยนได้ในราคาถูก

เริ่มจากเรื่องง่ายๆ

เราตั้งชื่อฟิลด์ว่า Customer Category หกเดือนต่อมา ฝ่ายธุรกิจบอกว่าจริงๆ แล้วทุกคนเรียกมันว่า Customer Segment เราเปลี่ยนป้ายชื่อ อาจมีเอกสารต้องอัปเดตและต้องอบรมผู้ใช้เล็กน้อย แต่นี่ไม่ใช่เหตุการณ์ใหญ่ทางสถาปัตยกรรม อย่างไรก็ตาม เราต้องอยู่กับ API name เดิม เพราะการเปลี่ยนสิ่งนั้นมีผลตามมาที่ใหญ่กว่ามาก ดังนั้นนี่อาจหมายถึงการรับมือกับการเปลี่ยนป้ายชื่อ และความสับสนที่อาจมาพร้อมกัน

เราตัดสินใจ เราเปลี่ยนใจ แล้วเราก็เดินหน้าต่อ

ทีนี้ลองเปรียบเทียบกับการตัดสินใจอีกแบบ

เรากำลังสร้างตัวระบุสำหรับลูกค้า เราตัดสินใจว่ามันหมายถึงอะไร ใช้รูปแบบไหน และระบบใดเป็นผู้สร้าง แล้วเราก็เผยแพร่มัน

Salesforce ใช้มัน คลังข้อมูลใช้มัน แพลตฟอร์มการผสานรวมใช้มัน พอร์ทัลลูกค้าใช้มัน แอปพลิเคชันอื่นอีกห้าตัวเริ่มเก็บมัน รายงานและ data pipeline ใช้มัน บางทีในที่สุดลูกค้าก็เห็นมัน

สามปีต่อมา มีคนพูดว่า:

เราไม่น่าออกแบบตัวระบุแบบนั้นเลย

นั่นเป็นบทสนทนาที่ต่างออกไปมาก

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

ความต่างอยู่ที่ความย้อนกลับได้

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

สถาปัตยกรรมสร้างแรงโน้มถ่วง

การตัดสินใจเชิงสถาปัตยกรรมมักดึงสิ่งต่างๆ เข้ามาสะสมรอบตัว ผมมองว่านั่นคือแรงโน้มถ่วง

เลือกโมเดลออบเจกต์ แล้วระบบอัตโนมัติก็ถูกสร้างขึ้นรอบมัน

เลือกคีย์ แล้วระบบอื่นก็เริ่มเก็บมัน

เลือกว่าข้อมูลหลักอยู่ที่ไหน แล้วการผสานรวมก็เริ่มไหลเข้าและออกจากที่นั่น

เลือกโมเดลการแชร์ แล้วกระบวนการธุรกิจก็เริ่มพึ่งพาว่าใครเห็นอะไรได้

เลือกรูปแบบการผสานรวม แล้วระบบต่างๆ ก็เริ่มพึ่งพาจังหวะเวลาและพฤติกรรมของมัน

ยิ่งการตัดสินใจเหล่านั้นอยู่นานเท่าไร มันก็ยิ่งมีแรงโน้มถ่วงมากขึ้น ในที่สุด การเปลี่ยนการตัดสินใจเดิมก็หมายถึงการเปลี่ยนทุกสิ่งที่สะสมอยู่รอบมัน

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

นั่นคือเหตุผลที่การที่โมเดลข้อมูลเป็น “โครงกระดูก” มีความสำคัญ เราไม่ได้ระมัดระวังเพราะการเปลี่ยนแปลงเป็นเรื่องไม่ดี เราระมัดระวังเพราะการพึ่งพาทำให้การเปลี่ยนแปลงมีราคาแพง

ถามคำถามสองข้อ

เวลาผมพิจารณาการตัดสินใจด้านการออกแบบ ผมถามคำถามสองข้อ:

สิ่งนี้ย้อนกลับยากแค่ไหน?

จะมีสิ่งต่างๆ พึ่งพามันมากเพียงใด?

สองข้อนี้เกี่ยวข้องกันแต่ไม่เหมือนกัน บางสิ่งอาจเปลี่ยนได้ง่ายในทางเทคนิคแต่มีผู้ใช้หลายร้อยราย คนเคยเปลี่ยนป้ายชื่อออบเจกต์มาตรฐานเพื่อความชัดเจน เช่น เปลี่ยน Account เป็น “Customer” ทำได้ง่าย แล้วระบบอื่นก็อยากใช้บัญชีสำหรับพันธมิตร แต่ทำไม่ได้ บางสิ่งอาจมีผู้ใช้เพียงไม่กี่รายแต่ต้องย้ายข้อมูลมหาศาลเพื่อเปลี่ยน เช่น API name ของออบเจกต์ที่ถูกอ้างถึงหลายที่ภายใน ไม่มีใครภายนอกเห็น แต่ถ้าผิดก็จะทำให้ทีมสับสนไม่จบ ไม่ว่าแบบไหนก็ควรได้รับความใส่ใจ

ลองนึกถึงการตัดสินใจด้านข้อมูลที่พบบ่อย:

• ออบเจกต์ Salesforce ตัวใดแทนแนวคิดทางธุรกิจนี้?
• ตัวระบุที่ไม่ซ้ำคืออะไร?
• ระบบใดเป็นระบบต้นทางหลัก (system of record)?
• ข้อมูลนี้ถูกคัดลอกเข้ามาใน Salesforce หรือเข้าถึงจากที่อื่น?
• นี่เป็นออบเจกต์เดียวหรือหลายออบเจกต์ที่สัมพันธ์กัน?
• ใครเป็นเจ้าของข้อมูล และเราเก็บมันไว้นานเท่าไร?
• ขอบเขตการเข้าถึงเริ่มต้นของเราคืออะไร?
• ข้อมูลนี้เคลื่อนย้ายระหว่างระบบอย่างไร?

สิ่งเหล่านี้ต่างอย่างมากจากการตัดสินใจว่าฟิลด์จะปรากฏตรงไหนบนหน้า Lightning การออกแบบหน้าก็สำคัญเช่นกัน แต่ราคาของการตัดสินใจผิดนั้นต่างกัน

Click to enlarge

คิดถึงรัศมีผลกระทบ

อีกวิธีในการคิดเรื่องความย้อนกลับได้คือรัศมีผลกระทบ: ถ้าผมเปลี่ยนการตัดสินใจนี้ มีอะไรอื่นขยับตามบ้าง?

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

ยิ่งรัศมีกว้าง เราก็ยิ่งควรตัดสินใจครั้งแรกอย่างระมัดระวัง

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

การตัดสินใจระดับองค์กรและการตัดสินใจใน Salesforce

สถาปนิกข้อมูลคิดในสองระดับ

ภายใน Salesforce เราตัดสินใจเรื่องออบเจกต์ ความสัมพันธ์ คีย์ ปริมาณ การเข้าถึง ระบบอัตโนมัติ และพฤติกรรมของข้อมูลบนแพลตฟอร์ม

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

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

สถาปัตยกรรมคือการจราจรสองทาง

Click to enlarge

ชะลอการตัดสินใจที่มีราคาแพง

อันตรายอย่างหนึ่งในเทคโนโลยีคือ การตัดสินใจที่ลงมือทำได้ง่ายที่สุดอาจดูเหมือนการตัดสินใจที่ตัดสินได้ง่ายที่สุด สองอย่างนี้ไม่ใช่สิ่งเดียวกัน

การสร้างออบเจกต์ที่กำหนดเองเพิ่มอีกตัวนั้นง่าย การสร้างฟิลด์เพิ่มก็ง่าย การเชื่อมต่อ API อีกตัวก็ง่ายขึ้นเรื่อยๆ และ AI ก็ทำให้ทั้งหมดง่ายขึ้นไปอีก

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

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

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

จดบันทึกว่าทำไม

ยังมีปัญหาอีกข้อหนึ่งกับการตัดสินใจที่สำคัญ: ผู้คนลืมว่าทำไมจึงตัดสินใจเช่นนั้น

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

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

สำหรับการตัดสินใจที่สำคัญ ให้จดบันทึกไว้ ไม่จำเป็นต้องเป็นเอกสาร 50 หน้า บันทึกการตัดสินใจที่มีประโยชน์อาจสั้นมาก:

บริบท: เรากำลังแก้ปัญหาอะไร?

ทางเลือก: เราพิจารณาทางเลือกที่เป็นไปได้จริงอะไรบ้าง?

การตัดสินใจ: เราเลือกอะไร?

ผลที่ตามมา: เราได้อะไร และกำลังสละอะไรไป?

เจ้าของ: ใครรับผิดชอบการตัดสินใจนี้?

การทบทวน: เหตุผลหรือวันที่ใดที่ควรทำให้เรากลับมาทบทวนมัน?

คุณค่าไม่ได้อยู่ที่เอกสาร คุณค่าอยู่ที่การเก็บรักษาเหตุผล

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

Click to enlarge

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

รู้ว่าการตัดสินใจใดสำคัญ

หนึ่งในทักษะที่ผมอยากให้คุณพัฒนาคือการรู้ว่าควรใช้ความใส่ใจไปที่ไหน

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

แต่ก็อย่าตัดสินใจอย่างง่ายๆ ในเรื่องที่องค์กรจะต้องอยู่กับมันไปอีกสิบปี

ให้ถามว่า:

สิ่งนี้จะย้อนกลับยากแค่ไหน?

จะมีสิ่งต่างๆ พึ่งพามันมากเพียงใด?

ถ้าคำตอบคือยากมากและมาก คุณน่าจะเจอการตัดสินใจเชิงสถาปัตยกรรมแล้ว

Click to enlarge

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

เป้าหมายของสถาปัตยกรรมไม่ใช่การตัดสินใจที่ไม่มีวันเปลี่ยนได้

เป้าหมายคือการรู้ทันการตัดสินใจที่การเปลี่ยนใจจะมีราคาแพง

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

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

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

• Object Relationships Overview (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ในความสัมพันธ์แบบ master-detail การเข้าถึงและความเป็นเจ้าของของ detail จะตาม master และการลบ master จะลบ detail ของมันด้วย
• Considerations for Object Relationships (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): lookup จะแปลงเป็น master-detail ได้ก็ต่อเมื่อทุกเรกคอร์ดมีค่าในฟิลด์นั้น การแปลงจะเปลี่ยนโมเดลการแชร์ (เป็น Controlled by Parent) และประเภทความสัมพันธ์เป็นตัวกำหนดว่ามีประเภทรายงานมาตรฐานใดให้ใช้
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ฟิลด์สรุปยอดมีได้เฉพาะในความสัมพันธ์แบบ master-detail และต้องลบออกก่อนที่ master-detail จะเปลี่ยนเป็น lookup ได้