Architecture Versus Design (Architecture กับ Design)

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

ในทำนองเดียวกัน software architecture เกี่ยวข้องกับรูปลักษณ์ของระบบน้อยกว่า แต่เกี่ยวข้องกับโครงสร้างของมันมากกว่า ในขณะที่ design เกี่ยวข้องกับรูปลักษณ์ของระบบมากกว่า แต่เกี่ยวข้องกับโครงสร้างของมันน้อยกว่า ตัวอย่างเช่น การเลือกใช้ microservices นิยามโครงสร้างและรูปร่างของระบบ (architecture ของมัน) ในขณะที่หน้าตาและความรู้สึกของหน้าจอ user interface (UI) นิยาม design ของระบบ

แต่แล้วการตัดสินใจอย่างเช่นจะแยก service ออกเป็นส่วนย่อยหรือไม่ หรือการเลือก UI framework ล่ะ น่าเสียดายที่การตัดสินใจแบบนี้ส่วนใหญ่ตกอยู่บน spectrum ระหว่าง architecture กับ design ทำให้ยากที่จะบอกว่าอะไรควรถือเป็น architecture

การใช้เกณฑ์ต่อไปนี้ช่วยพิจารณาได้ว่าสิ่งหนึ่งเป็นเรื่อง architecture หรือเรื่อง design มากกว่ากัน

  • มันมีลักษณะเชิงกลยุทธ์ (strategic) หรือเชิงยุทธวิธี (tactical) มากกว่ากัน

  • ต้องใช้ความพยายามมากแค่ไหนในการเปลี่ยนแปลงหรือสร้างมันขึ้นมา

  • trade-off มีความสำคัญมากแค่ไหน

ปัจจัยเหล่านี้แสดงไว้ใน รูปที่ 2-1 ซึ่งแสดง spectrum ระหว่าง architecture กับ design เพื่อช่วยพิจารณาว่าการตัดสินใจหนึ่งๆ อยู่ตรงไหน และใครควรเป็นผู้รับผิดชอบมัน

Spectrum Between Architecture and Design

Figure 2-1. The spectrum between architecture and design

Strategic Versus Tactical Decisions (การตัดสินใจเชิงกลยุทธ์กับเชิงยุทธวิธี)

ยิ่งการตัดสินใจเชิงกลยุทธ์มากเท่าไร มันก็ยิ่งเป็นเรื่อง architecture มากขึ้นเท่านั้น ในทางกลับกัน ยิ่งการตัดสินใจเชิงยุทธวิธีมากเท่าไร มันก็มีแนวโน้มจะเป็นเรื่อง design มากขึ้นเท่านั้น การตัดสินใจแบบ strategic โดยทั่วไปเป็นระยะยาว ในขณะที่การตัดสินใจแบบ tactical โดยทั่วไปเป็นระยะสั้นและมักไม่ขึ้นกับ action หรือการตัดสินใจอื่นๆ

วิธีที่ดีวิธีหนึ่งในการพิจารณาว่าการตัดสินใจหนึ่งๆ เป็นแบบ strategic หรือ tactical มากกว่ากัน คือการพิจารณาคำถามต่อไปนี้

การตัดสินใจนี้ต้องใช้ความคิดและการวางแผนมากแค่ไหน

การตัดสินใจที่ใช้เวลาแค่สองสามนาทีมีแนวโน้มจะเป็นแบบ tactical และจึงเป็นเรื่อง design มากกว่า ในขณะที่การตัดสินใจที่ต้องใช้เวลาวางแผนหลายสัปดาห์มีแนวโน้มจะเป็นแบบ strategic และจึงเป็นเรื่อง architecture มากกว่า

มีคนกี่คนที่เกี่ยวข้องในการตัดสินใจนี้

การตัดสินใจที่ทำคนเดียวหรือกับเพื่อนร่วมงานคนหนึ่งมีแนวโน้มจะเป็นแบบ tactical และอยู่ฝั่ง design ของ spectrum ในขณะที่การตัดสินใจที่ต้องประชุมกับ stakeholder หลายฝ่ายจำนวนมากมีแนวโน้มจะเป็นแบบ strategic และอยู่ฝั่ง architecture ของ spectrum

การตัดสินใจนี้เป็นวิสัยทัศน์ระยะยาวหรือ action ระยะสั้น

การตัดสินใจที่มีแนวโน้มจะเปลี่ยนแปลงในไม่ช้ามักมีลักษณะเป็น tactical และจึงเป็นเรื่อง design มากกว่า ในขณะที่การตัดสินใจที่จะคงอยู่ยาวนานมากมักเป็นแบบ strategic และเป็นเรื่อง architecture มากกว่า

แม้ว่าคำถามเหล่านี้จะค่อนข้างเป็นเรื่องอัตวิสัยอยู่บ้าง แต่ก็ยังช่วยพิจารณาได้ว่าสิ่งหนึ่งเป็นเชิง strategic หรือ tactical และจึงเป็นเรื่อง architecture หรือ design มากกว่ากัน

Level of Effort (ระดับความพยายาม)

ในบทความชื่อดังของเขา “Who Needs an Architect?” software architect อย่าง Martin Fowler เขียนไว้ว่า architecture คือ “สิ่งที่แก้ไขได้ยาก” โดยทั่วไปแล้วยิ่งบางสิ่งแก้ไขยากเท่าไร ก็ยิ่งต้องใช้ความพยายามมากขึ้นเท่านั้น ซึ่งทำให้การตัดสินใจหรือกิจกรรมนั้นเอนเอียง ไปทางฝั่ง architecture ของ spectrum ในทางกลับกัน สิ่งที่ต้องใช้ความพยายามน้อยมากในการ implement หรือเปลี่ยนแปลง จะเอนเอียงไปทางฝั่ง design ของ spectrum มากกว่า

ตัวอย่างเช่น การย้ายจาก monolithic layered architecture ไปเป็น microservices ต้องใช้ความพยายามอย่างมาก ดังนั้นจึงเป็นเรื่อง architecture มากกว่า การจัดเรียง field บนหน้าจอใหม่ต้องใช้ความพยายามน้อยมาก ดังนั้นจึงเป็นเรื่อง design มากกว่า

The Significance of Trade-Offs (ความสำคัญของ Trade-Off)

การวิเคราะห์ trade-off ของการตัดสินใจหนึ่งๆ ช่วยได้มากในการพิจารณาว่ามันเป็นเรื่อง architecture หรือ design มากกว่ากัน ยิ่ง trade-off มีความสำคัญมากเท่าไร การตัดสินใจนั้นก็ยิ่งมีแนวโน้มเป็นเรื่อง architecture มากขึ้นเท่านั้น ตัวอย่างเช่น การเลือกใช้ microservices architecture style ให้ scalability, agility, elasticity และ fault tolerance ที่ดีกว่า อย่างไรก็ตาม architecture นี้มีความซับซ้อนสูง ราคาแพงมาก มี data consistency ที่ไม่ดี และทำงานได้ไม่ดีนักเนื่องจาก service coupling เหล่านี้เป็น trade-off ที่ค่อนข้างสำคัญ เราสรุปได้ว่าการตัดสินใจนี้อยู่ฝั่ง architecture ของ spectrum มากกว่าฝั่ง design

แม้แต่การตัดสินใจด้าน design ก็มี trade-off เช่นกัน ตัวอย่างเช่น การแยกไฟล์ class ออกเป็นหลายไฟล์ ให้ maintainability และ readability ที่ดีขึ้น แลกกับการต้องจัดการ class ที่มากขึ้น trade-off เหล่านี้ ไม่ได้สำคัญมากนัก (โดยเฉพาะเมื่อเทียบกับ trade-off ของ microservices) ดังนั้นการตัดสินใจนี้จึงอยู่ฝั่ง design ของ spectrum มากกว่า