Expectations of an Architect (สิ่งที่คาดหวังจากสถาปนิก)

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

• ทำการตัดสินใจด้าน architecture

• วิเคราะห์ architecture อย่างต่อเนื่อง

• ติดตามเทรนด์ล่าสุดอยู่เสมอ

• รับรองการปฏิบัติตามการตัดสินใจ

• เข้าใจเทคโนโลยี framework แพลตฟอร์ม และสภาพแวดล้อมที่หลากหลาย

• รู้จัก business domain

• นำทีมและมีทักษะด้านมนุษยสัมพันธ์

• เข้าใจและรับมือกับการเมืองในองค์กร

ความสำเร็จในฐานะ software architect ขึ้นอยู่กับการเข้าใจและทำตามความคาดหวังแต่ละข้อเหล่านี้ หัวข้อนี้จะพูดถึงทั้งแปดข้อทีละข้อ

Make Architecture Decisions (ทำการตัดสินใจด้าน Architecture)

สถาปนิกถูกคาดหวังให้กำหนด architecture decision และ design principle ที่ใช้ชี้นำการตัดสินใจด้านเทคโนโลยี ภายในทีม ภายในแผนก หรือทั่วทั้งองค์กร

Guide คือคำสำคัญของความคาดหวังข้อแรกนี้ สถาปนิกควร ชี้นำ ทางเลือกเทคโนโลยี มากกว่าจะ กำหนด มันเอง ตัวอย่างเช่น การตัดสินใจใช้ React.js สำหรับการพัฒนา frontend เป็น technical decision ไม่ใช่ architectural decision แทนที่จะตัดสินใจแบบนี้เอง สถาปนิกควรสั่งให้ทีมพัฒนาใช้ reactive-based framework สำหรับการพัฒนา frontend web โดยชี้นำให้พวกเขาเลือกระหว่าง Angular, Elm, React.js, Vue หรือ reactive-based web framework อื่นๆ กุญแจสำคัญคือการถามว่า architecture decision นั้นจะ ชี้นำ ทีมให้ตัดสินใจเทคนิคที่ถูกต้อง หรือตัดสินใจแทนพวกเขาไปเลย ถึงกระนั้น ก็มีบางโอกาสที่สถาปนิกต้องทำ การตัดสินใจด้านเทคโนโลยีที่เจาะจง เพื่อรักษา architectural characteristic บางอย่างไว้ เช่น scalability, performance หรือ availability สถาปนิกมักดิ้นรนหาจุดสมดุลนี้ ดังนั้น บทที่ 21 จึงพูดถึง architecture decision ทั้งบท

Continually Analyze the Architecture (วิเคราะห์ Architecture อย่างต่อเนื่อง)

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

Architecture vitality ประเมินว่า architecture ที่ถูกกำหนดไว้เมื่อสามปีก่อนหรือนานกว่านั้นยังใช้ได้จริงแค่ไหนใน วันนี้ เมื่อพิจารณาการเปลี่ยนแปลงทั้งด้านธุรกิจและเทคโนโลยี จากประสบการณ์ของเรา สถาปนิกจำนวนไม่น้อยไม่ได้ทุ่มเทพลังงาน มากพอกับการวิเคราะห์ architecture ที่มีอยู่แล้วอย่างต่อเนื่อง ผลก็คือ architecture ส่วนใหญ่ประสบกับ structural decay บางส่วน ซึ่งเกิดขึ้นเมื่อนักพัฒนาทำการเปลี่ยนแปลงโค้ดหรือ design ที่กระทบ architectural characteristic ที่จำเป็น เช่น performance, availability และ scalability

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

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

Keep Current with Latest Trends (ติดตามเทรนด์ล่าสุดอยู่เสมอ)

สถาปนิกถูกคาดหวังให้ติดตามเทคโนโลยีและเทรนด์ในอุตสาหกรรมล่าสุดอยู่เสมอ

นักพัฒนาต้องอัปเดตความรู้เรื่องเทคโนโลยีล่าสุด รวมถึงเทคโนโลยีที่ใช้งานอยู่ทุกวัน เพื่อให้ตัวเองยังคง มีความเกี่ยวข้อง (และรักษางานไว้ได้!) มันยิ่งสำคัญมากขึ้นไปอีกสำหรับสถาปนิกที่จะติดตามเทรนด์เทคนิคและ อุตสาหกรรมล่าสุด การตัดสินใจของสถาปนิกมักส่งผลยาวนานและเปลี่ยนแปลงยาก การเข้าใจเทรนด์ช่วยให้สถาปนิก ตัดสินใจในสิ่งที่จะยังคงมีความเกี่ยวข้องในอนาคต ตัวอย่างเช่น สถาปนิกในช่วงหลายปีที่ผ่านมาต้องเรียนรู้เรื่อง การจัดเก็บและการ deploy บน cloud และในขณะที่เรากำลังเขียนฉบับพิมพ์ครั้งที่สองนี้ generative AI ก็กำลังส่งผลกระทบอย่างมหาศาลต่อหลายส่วนของระบบนิเวศการพัฒนาซอฟต์แวร์

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

Ensure Compliance with Decisions (รับรองการปฏิบัติตามการตัดสินใจ)

สถาปนิกถูกคาดหวังให้รับรองการปฏิบัติตาม architecture decision และ design principle

การรับรองการปฏิบัติตามหมายถึงการตรวจสอบอย่างต่อเนื่องว่าทีมพัฒนากำลังปฏิบัติตามการตัดสินใจและ design principle ที่ถูกกำหนด บันทึก และสื่อสารโดยสถาปนิก

ลองจินตนาการว่าคุณในฐานะสถาปนิกตัดสินใจจำกัดการเข้าถึง database ใน layered architecture ให้เฉพาะ Business layer และ Services layer เท่านั้น (ไม่ใช่ Presentation layer) การตัดสินใจนี้ (ดังที่คุณจะเห็นใน บทที่ 10 ) หมายความว่า Presentation layer ต้องผ่านทุก layer ของ architecture เพื่อทำแม้แต่การเรียก database ที่ง่ายที่สุด อย่างไรก็ตาม นักพัฒนา user interface (UI) คนหนึ่งไม่เห็นด้วยกับการตัดสินใจนี้ และให้ Presentation layer เข้าถึง database ได้โดยตรงด้วยเหตุผลด้าน performance คุณตัดสินใจแบบ architecture นั้นด้วยเหตุผลเฉพาะเจาะจง คือเพื่อไม่ให้การเปลี่ยนแปลง database ส่งผลกระทบต่อ Presentation layer หากคุณไม่รับรองการปฏิบัติตาม architecture decision ของคุณ การละเมิดแบบนี้ก็เกิดขึ้นได้ ผลลัพธ์อาจเป็นว่า architecture ไม่สามารถให้ characteristic ที่ต้องการได้ และแอปพลิเคชันหรือระบบก็ไม่ทำงาน ตามที่คาดไว้ ใน บทที่ 6 เราจะพูดถึงการวัดการปฏิบัติตามด้วย automated fitness function และเครื่องมืออื่นๆ

Understand Diverse Technologies (เข้าใจเทคโนโลยีที่หลากหลาย)

สถาปนิกถูกคาดหวังให้มีความคุ้นเคยกับเทคโนโลยี framework แพลตฟอร์ม และสภาพแวดล้อมที่หลากหลายและแตกต่างกัน

ไม่ได้คาดหวังให้สถาปนิกทุกคนเป็นผู้เชี่ยวชาญใน framework แพลตฟอร์ม และภาษาทุกตัว แต่พวกเขาควรคุ้นเคยกับเทคโนโลยีที่หลากหลายอย่างน้อยที่สุด สภาพแวดล้อมส่วนใหญ่ในปัจจุบันมีความหลากหลาย (heterogeneous) ดังนั้นอย่างน้อยที่สุด สถาปนิกควรรู้วิธี interface กับระบบและ service หลายๆ ตัว ไม่ว่าภาษา แพลตฟอร์ม หรือเทคโนโลยีของมันจะเป็นอะไรก็ตาม

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

Know the Business Domain (รู้จัก Business Domain)

สถาปนิกถูกคาดหวังให้มีความเชี่ยวชาญด้าน business domain ในระดับหนึ่ง

Software architect ที่มีประสิทธิภาพเข้าใจปัญหาทางธุรกิจ เป้าหมาย และความต้องการที่ architecture มุ่งจะแก้ไข ซึ่งรวมเรียกว่า business domain ของ problem space นั้น มันยากที่จะออกแบบ architecture ที่มีประสิทธิภาพ ถ้าคุณไม่เข้าใจความต้องการของธุรกิจ ลองจินตนาการว่าเป็นสถาปนิกที่ธนาคารใหญ่แห่งหนึ่ง แล้วไม่เข้าใจคำศัพท์ทางการเงินทั่วไปอย่าง average directional index , aleatory contracts , rates rally หรือแม้แต่ nonpriority debt คุณจะไม่สามารถสื่อสารกับ stakeholder และผู้ใช้งานทางธุรกิจได้ และจะสูญเสียความน่าเชื่อถืออย่างรวดเร็ว

สถาปนิกที่ประสบความสำเร็จมากที่สุดที่เรารู้จักมีความรู้เชิงเทคนิคที่กว้างขวางลงมือปฏิบัติได้จริง และ มีความรู้อันแข็งแกร่งใน domain เฉพาะทางหนึ่ง พวกเขาสามารถสื่อสารกับผู้บริหารระดับ C และผู้ใช้งานทางธุรกิจ ด้วยภาษาที่ stakeholder เหล่านี้รู้จักและเข้าใจ สร้างความมั่นใจว่าพวกเขารู้ว่าตัวเองกำลังทำอะไรอยู่ และมีความสามารถที่จะสร้าง architecture ที่มีประสิทธิภาพและถูกต้อง

Possess Interpersonal Skills (มีทักษะด้านมนุษยสัมพันธ์)

สถาปนิกถูกคาดหวังให้มีทักษะด้านมนุษยสัมพันธ์ที่โดดเด่น รวมถึงการทำงานเป็นทีม การอำนวยความสะดวก (facilitation) และความเป็นผู้นำ

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

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

Understand and Navigate Politics (เข้าใจและรับมือกับการเมือง)

สถาปนิกถูกคาดหวังให้เข้าใจบรรยากาศทางการเมืองขององค์กร และสามารถรับมือกับการเมืองนั้นได้

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

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

ในสถานการณ์ที่สอง สถาปนิกที่รับผิดชอบระบบ customer relationship management (CRM) ขนาดใหญ่ กำลังประสบปัญหาในการควบคุมการเข้าถึง database จากระบบอื่นๆ การรักษาความปลอดภัยข้อมูลลูกค้าบางส่วน และการเปลี่ยนแปลง database schema ปัญหาทั้งหมดนี้มาจากการที่ระบบอื่นๆ ใช้ database ของ CRM มากเกินไป สถาปนิกจึงตัดสินใจสร้าง application silo โดยที่ database ของแต่ละแอปพลิเคชันจะเข้าถึงได้จากแอปพลิเคชันที่เป็นเจ้าของ database นั้นเท่านั้น การตัดสินใจนี้จะให้สถาปนิกควบคุมข้อมูลลูกค้า ความปลอดภัย และการเปลี่ยนแปลงได้ดีขึ้น

อย่างไรก็ตาม ต่างจากการตัดสินใจของนักพัฒนาในสถานการณ์แรก สถาปนิกคาดได้เลยว่าแทบทุกคนในบริษัทจะท้าทาย การตัดสินใจของพวกเขา (ยกเว้นทีมแอปพลิเคชัน CRM ที่อาจไม่ท้าทาย) แอปพลิเคชันอื่นๆ ต้องการข้อมูล CRM และหากไม่สามารถเข้าถึง database ได้โดยตรงอีกต่อไป พวกเขาต้องขอข้อมูลจากระบบ CRM ผ่าน remote access call เจ้าของ product ผู้จัดการโปรเจกต์ และ stakeholder ทางธุรกิจอาจคัดค้านการเพิ่มขึ้นของค่าใช้จ่ายหรือความพยายาม ในขณะที่นักพัฒนาอาจรู้สึกว่าวิธีของตนดีกว่า แทบทุกการตัดสินใจที่สถาปนิกทำจะถูกท้าทาย

ไม่ว่าข้อคัดค้านจะเป็นอะไร สถาปนิกต้องรับมือกับการเมืองในองค์กรและใช้ทักษะการเจรจาต่อรอง เพื่อให้การตัดสินใจส่วนใหญ่ได้รับการอนุมัติ นี่อาจเป็นเรื่องน่าหงุดหงิดมาก เพราะ software architect ส่วนใหญ่เริ่มต้นจากการเป็นนักพัฒนา และเคยชินกับการตัดสินใจโดยไม่ต้องขออนุมัติหรือแม้แต่ review ในฐานะสถาปนิก ในที่สุดพวกเขาก็สามารถทำการตัดสินใจที่กว้างและสำคัญได้ แต่พวกเขาต้องให้เหตุผลและต่อสู้เพื่อ แทบทุกการตัดสินใจ ทักษะการเจรจาต่อรอง เช่นเดียวกับทักษะภาวะผู้นำ มีความจำเป็นมากจนเราทุ่มเทหนึ่งบทเต็มให้กับมัน ( บทที่ 25 )