คิดแบบสถาปนิก

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

โมดูลที่ 1 จาก 7 ในบท คิดแบบสถาปนิกข้อมูล ซึ่งเป็นบทแรกของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ภาพรวมของบท · ถัดไป: โมเดลข้อมูลคือโครงกระดูก

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

ตลอดอาชีพส่วนใหญ่ของผม ผมเป็นผู้สร้าง

ผมเริ่มต้นจากการเป็นนักพัฒนา ผมทำงานกับ Java และ .NET ก่อนจะย้ายมาทำ Salesforce และใช้เวลาหลายปีในการออกแบบระบบ เขียนโค้ด เชื่อมต่อแพลตฟอร์ม สอนสถาปนิก และรีวิวสถาปัตยกรรม

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

ผู้สร้างถามว่า:

ฉันจะสร้างสิ่งนี้อย่างไร?

สถาปนิกต้องถามคำถามอีกชุดหนึ่ง:

เราควรสร้างสิ่งนี้ไหม?

ทำไมเราถึงสร้างมันแบบนี้?

มีทางเลือกอื่นอะไรบ้าง?

จะเกิดอะไรขึ้นเมื่อสิ่งนี้ใหญ่ขึ้น?

จะเกิดอะไรขึ้นเมื่อมันล้มเหลว?

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

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

การเปลี่ยนวิธีคิดแบบนั้นคือสิ่งที่หลักสูตรนี้ว่าด้วยจริงๆ

Click to enlarge

คนที่ถือพิมพ์เขียว

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

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

แต่ก็ต้องมีใครสักคนถือพิมพ์เขียวด้วย

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

นั่นคือสถาปัตยกรรม

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

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

นั่นเป็นทักษะที่ต่างออกไปมาก

อย่าแค่รับความต้องการมา

หนึ่งในนิสัยแรกที่ผมอยากให้สถาปนิกสร้างขึ้นนั้นเรียบง่าย:

ถามว่าทำไม

มีคนบอกคุณว่า:

เราต้องการออบเจกต์อีกตัว

ทำไม?

เราต้องการให้คัดลอกฟิลด์นี้ไปไว้ที่บัญชี

ทำไม?

เราต้องการเก็บข้อมูลทั้งหมดนี้ไว้ใน Salesforce

ทำไม?

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

ความต้องการมักมาในคราบของการออกแบบ

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

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

สถาปนิกต้องแยก สิ่งที่ธุรกิจต้องการ ออกจาก วิธีส่งมอบหนึ่งวิธีที่ถูกเสนอมา

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

คิดให้ไกลกว่าความต้องการ

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

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

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

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

Click to enlarge

ทำให้เหตุผลของคุณมองเห็นได้

สถาปนิกไม่ควรแค่เดินเข้าห้องแล้วประกาศว่า “นี่คือสิ่งที่เราจะทำ”

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

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

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

สถาปนิกไม่จำเป็นต้องสร้างทุกอย่างเอง

มีการเปลี่ยนผ่านอีกอย่างหนึ่งที่อาจยาก โดยเฉพาะสำหรับคนที่ก้าวเข้าสู่สถาปัตยกรรมจากสายการพัฒนา

คุณไม่จำเป็นต้องสร้างทุกอย่างด้วยตัวเอง

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

บางครั้งนั่นหมายถึงการลงลึกในคิวรี API หรือโมเดลข้อมูล

บางครั้งหมายถึงการถอยออกมาแล้วถามว่าเราควรทำสิ่งเหล่านี้ตั้งแต่แรกหรือเปล่า

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

นั่นคือส่วนหนึ่งของเส้นทางจากผู้สร้างสู่สถาปนิก

งานของคุณคือการตัดสินใจ

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

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

เลย์เอาต์หน้าเปลี่ยนได้ ป้ายชื่อเปลี่ยนชื่อได้

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

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

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

เทคโนโลยีมีความสำคัญ

แต่การรู้จักทุกฟีเจอร์ของ Salesforce ไม่ใช่เป้าหมาย

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

นั่นคือการคิดแบบสถาปนิก

และตอนนี้เราก็เริ่มคิดแบบ สถาปนิกข้อมูล ได้แล้ว

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

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