โมเดลข้อมูล: อาวุธลับที่สร้างความได้เปรียบเหนือคู่แข่ง

ทีมชุมชน BigGo
โมเดลข้อมูล: อาวุธลับที่สร้างความได้เปรียบเหนือคู่แข่ง

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

มุมมองด้านวิศวกรรมต่อกลยุทธ์ผลิตภัณฑ์

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

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

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

ความจริงอันเจ็บปวดของการวิวัฒนาการของโมเดลข้อมูล

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

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

แหล่งข้อมูลเกี่ยวกับการเพิ่มประสิทธิภาพที่กล่าวถึง:

  • การบรรยายเรื่องประสิทธิภาพของ Mike Acton เกี่ยวกับ Data-Oriented Design
  • การใช้งาน Data-Oriented Design ในตัวคอมไพเลอร์ Zig
  • หนังสือ Data-Oriented Design (dataorienteddesign.com/dodbook.pdf)

การเชื่อมช่องว่างระหว่างวิศวกรรมและผลิตภัณฑ์

มีการถกเถียงกันอย่างต่อเนื่องว่าเรากำลังพูดถึงโมเดลข้อมูล (data models) โมเดลโดเมน (domain models) หรือสิ่งอื่นทั้งหมดหรือไม่ ผู้แสดงความคิดเห็นหนึ่งชี้ให้เห็นว่า data model เป็นคำศัพท์ทางวิศวกรรมที่นำไปใช้กับแนวคิดระดับผลิตภัณฑ์ ในขณะที่ domain model อาจเหมาะสมกว่าในภาษาของผลิตภัณฑ์ อย่างไรก็ตาม คำศัพท์ทางวิศวกรรมสามารถจับภาพผลกระทบที่แพร่กระจายไปทั่วระบบได้ดีกว่า

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

ปัจจัย AI: โมเดลข้อมูลในฐานะกำแพงป้องกัน

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

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

ตัวอย่างโมเดลข้อมูลสำคัญจากการสนทนาในชุมชน:

  • Slack: ช่องทางแบบถาวรเป็นหน่วยพื้นฐาน เทียบกับข้อความที่เป็นชั่วคราว
  • Toast: สถาปัตยกรรมที่เน้นรายการเมนูเป็นหลัก เทียบกับ SKU ของ POS แบบทั่วไป
  • Notion: บล็อกเป็นหน่วยที่ประกอบได้ เทียบกับโมเดลที่เน้นเอกสารเป็นหลัก
  • Rippling: ข้อมูลพนักงานเป็นวัตถุหลัก เทียบกับเครื่องมือที่แยกส่วนกัน
  • Klaviyo: โมเดลข้อมูลที่เน้นคำสั่งซื้อเป็นหลัก เทียบกับเครื่องมือที่เน้นอีเมลเป็นหลัก

หนทางต่อไป: การตรวจสอบและทำซ้ำ

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

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

คำถามสำหรับการตรวจสอบโมเดลข้อมูล:

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

สรุป

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

อ้างอิง: Your data model is your destiny