สถาปัตยกรรมคือศิลปะแห่งการแลกเปลี่ยนได้เสีย

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

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

ถ้าสถาปัตยกรรมเป็นแค่เรื่องของการหาคำตอบที่ถูก มันคงง่ายกว่านี้มาก เรียนรู้แพลตฟอร์ม เรียนรู้รูปแบบ เรียนรู้ข้อจำกัด เลือกอันที่ถูก จบ

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

ปัญหาหนึ่งแก้ได้หลายวิธี

ผมใช้ตัวอย่างนี้ในหลายรูปแบบมาแล้วหลายครั้งเวลาสอนสถาปนิก

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

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

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

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

Click to enlarge

เหมาะที่สุดไม่ได้แปลว่าสมบูรณ์แบบ

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

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

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

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

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

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

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

รู้ว่าคุณกำลังแลกอะไรไป

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

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

ความต้องการไม่ได้มีน้ำหนักเท่ากันทั้งหมด

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

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

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

ข้อจำกัดเปลี่ยนคำตอบ

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

สถาปัตยกรรมที่ยอดเยี่ยมทางเทคนิคแต่ต้องการทีมปฏิบัติการที่บริษัทไม่มี ไม่ใช่สถาปัตยกรรมที่ดี ความสามารถที่แก้ปัญหาได้อย่างสง่างามแต่ต้องใช้สิทธิ์การใช้งานที่ลูกค้าไม่ซื้อ ก็ไม่ใช่โซลูชันเช่นกัน และการปฏิรูปสามปีที่สมบูรณ์แบบก็ไม่ช่วยบริษัทที่ต้องเปิดตัวในแปดสัปดาห์

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

สถาปนิกต้องมีภาพของ “ความเหมาะที่สุด”

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

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

วาดมันออกมา

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

ไดอะแกรมบังคับให้ความคลุมเครือเผยตัวออกมา และให้ทุกคนมีภาพเดียวกันไว้ชี้

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

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

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

อธิบายการแลกเปลี่ยนได้เสีย

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

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

Think Correct. Think Fast.

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

ผมใช้วลี Think Correct. Think Fast. (คิดให้ถูก คิดให้เร็ว) ความเร็วไม่ได้มาจากการข้ามขั้นตอนการคิด แต่มาจากการคิดมาพอแล้วก่อนช่วงเวลานั้นจะมาถึง: คุณเรียนรู้รูปแบบ รู้จักแพลตฟอร์ม เคยเห็นความล้มเหลว รู้ว่าควรถามอะไร และการตัดสินใจใดย้อนกลับยาก นั่นคือเหตุผลที่เราฝึกกับสถานการณ์จำลองตลอดหลักสูตรนี้ ยิ่งคุณวิเคราะห์การตัดสินใจมากเท่าไร คุณก็จะจำรูปร่างของการตัดสินใจครั้งถัดไปได้เร็วขึ้น

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

สถาปัตยกรรมคือเรื่องของความสมดุล

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

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

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

นั่นไม่ใช่ความลังเล นั่นคือสถาปัตยกรรม

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

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