Trade-Offs and Least Worst Architecture (Trade-off กับสถาปัตยกรรมที่แย่น้อยที่สุด)

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

ประการที่สอง architectural characteristics ทำงานร่วมกันแบบ synergistic ทั้งกับกันเองและกับ problem domain แม้เราจะอยากให้เป็นอย่างอื่น แต่แต่ละองค์ประกอบการออกแบบก็มีปฏิสัมพันธ์กับองค์ประกอบอื่นทั้งหมด ตัวอย่างเช่น การพยายามปรับปรุง security แทบจะแน่นอนว่าจะส่งผลลบต่อ performance เพราะแอปพลิเคชันต้องทำ encryption แบบ on-the-fly มากขึ้น มี indirection (เพื่อซ่อนความลับ) และกิจกรรมอื่น ๆ ที่อาจลดทอน performance นักบินเครื่องบินมักพบว่ายากเมื่อต้องเรียนขับเฮลิคอปเตอร์ ซึ่งมีคันบังคับสำหรับมือและเท้าแต่ละข้าง การปรับคันบังคับตัวหนึ่งจะส่งผลต่อตัวอื่นทั้งหมด เพราะมันทำงานแบบ synergistic การขับเฮลิคอปเตอร์คือการฝึกความสมดุล ซึ่งอธิบายกระบวนการ trade-off ในการเลือก architectural characteristics ได้เป็นอย่างดี เพราะมันก็ทำงานแบบ synergistic ทั้งกับ architectural characteristics อื่นและกับการออกแบบ domain เช่นกัน—การเปลี่ยนอย่างหนึ่งมักหมายถึงต้องเปลี่ยนอีกอย่างหนึ่งด้วย เหมือนนักบินเฮลิคอปเตอร์ที่ต้องดิ้นรนของเรา สถาปนิกก็ต้องเรียนรู้ที่จะจัดการสิ่งที่เชื่อมโยงกันหลาย ๆ อย่างพร้อมกัน

ประการที่สาม ดังที่เรากล่าวไปก่อนหน้านี้ การขาดนิยามมาตรฐานสำหรับ architectural characteristics ทำให้องค์กรต้องดิ้นรนกับความกำกวม แม้วงการนี้จะไม่มีทางสร้างรายการ architectural characteristics ที่ตายตัวได้ (เพราะมีตัวใหม่ ๆ ปรากฏขึ้นตลอดเวลา) แต่ละองค์กรก็สามารถสร้างรายการของตัวเอง (หรือ ubiquitous language ของตัวเอง) พร้อมนิยามที่เป็นภววิสัยได้

สุดท้าย ไม่เพียงแต่จำนวน architectural characteristics จะเพิ่มขึ้นเรื่อย ๆ เท่านั้น แต่จำนวน หมวดหมู่ ก็เพิ่มขึ้นในช่วงทศวรรษที่ผ่านมาด้วยเช่นกัน ตัวอย่างเช่น เมื่อไม่กี่ทศวรรษก่อน สถาปนิกแทบไม่สนใจประเด็นด้าน operation เลย ซึ่งถือเป็น “กล่องดำ” แยกต่างหาก อย่างไรก็ตาม ด้วยความนิยมที่เพิ่มขึ้นของสถาปัตยกรรมอย่าง microservices สถาปนิกและฝ่าย operation ต้องร่วมมือกันอย่างเข้มข้นและบ่อยครั้งมากขึ้น เมื่อสถาปัตยกรรมซอฟต์แวร์ซับซ้อนขึ้น มันก็มีแนวโน้มจะพันเกี่ยวกับส่วนอื่น ๆ ขององค์กรมากขึ้นตามไปด้วย

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

Tip

อย่ามุ่งหา สถาปัตยกรรมที่ดีที่สุด แต่ให้มุ่งหา สถาปัตยกรรมที่แย่น้อยที่สุด ต่างหาก

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

มุ่งออกแบบสถาปัตยกรรมให้เป็นแบบ iterative มากที่สุดเท่าที่จะทำได้ ยิ่งเปลี่ยนแปลงสถาปัตยกรรมได้ง่ายเท่าไร ทุกคนก็ยิ่งไม่ต้องเครียดกับการหาสิ่งที่ถูกต้องเป๊ะในความพยายามครั้งแรกมากเท่านั้น หนึ่งในบทเรียนสำคัญที่สุดของการพัฒนาซอฟต์แวร์แบบ Agile คือคุณค่าของการทำซ้ำ (iteration) ซึ่งเป็นจริงในทุกระดับของการพัฒนาซอฟต์แวร์ รวมถึงสถาปัตยกรรมด้วย