Architecture and the Business Environment (สถาปัตยกรรมกับสภาพแวดล้อมทางธุรกิจ)

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

เราเรียกความสอดคล้องนี้ว่า domain-to-architecture isomorphism ตัวอย่างเช่น บริษัทที่กำลังลดต้นทุนอย่างหนักจะไม่เข้ากันดีกับ microservices หรือ space-based architecture ซึ่งมีค่าใช้จ่ายสูงในการสร้างและดูแลรักษา ในทางกลับกัน ธุรกิจที่กำลังขยายตัวอย่างก้าวร้าวผ่านการควบรวมและซื้อกิจการก็จะไม่ได้รับประโยชน์จาก monolithic architecture style ที่ขาดความสามารถในการวิวัฒนาการและปรับตัว

ปัญหาหนึ่งที่สถาปนิกมักเผชิญกับจุดตัดนี้คือการเปลี่ยนแปลงทางธุรกิจ โดยเฉพาะ unknown change อดีตรัฐมนตรีกลาโหมสหรัฐฯ Donald Rumsfeld เคย กล่าวไว้อย่างโด่งดัง ว่า

มีสิ่งที่รู้ว่ารู้ (known knowns) นั่นคือสิ่งที่เรารู้ว่าเรารู้ เรายังรู้ว่ามีสิ่งที่รู้ว่าไม่รู้ (known unknowns) นั่นคือเรารู้ว่ามีบางสิ่งที่เราไม่รู้ แต่ก็ยังมีสิ่งที่ไม่รู้ว่าไม่รู้ (unknown unknowns) ซึ่งเป็นสิ่งที่เราไม่รู้ด้วยซ้ำว่าเราไม่รู้

ผลิตภัณฑ์และระบบจำนวนมากเริ่มต้นด้วยรายการของ known unknowns นั่นคือสิ่งที่ developer ต้องเรียนรู้เกี่ยวกับ domain และเทคโนโลยีที่พวกเขารู้ว่าจะเปลี่ยนแปลง อย่างไรก็ตาม ระบบเดียวกันนี้ก็ตกเป็นเหยื่อของ unknown unknowns เช่นกัน นั่นคือสิ่งที่ไม่มีใครรู้ว่าจะเกิดขึ้น แต่กลับปรากฏขึ้นโดยไม่คาดคิด “Unknown unknowns” คือศัตรูตัวฉกาจของระบบซอฟต์แวร์ นี่คือเหตุผลที่ความพยายามแบบ “Big Design Up Front” ทั้งหมดล้มเหลว เพราะสถาปนิกไม่สามารถออกแบบรองรับ unknown unknowns ได้ ยกคำพูดของ Mark มาว่า

สถาปัตยกรรมทั้งหมดกลายเป็นแบบ iterative เพราะ unknown unknowns Agile เพียงแค่ตระหนักถึงสิ่งนี้และทำมันได้เร็วขึ้นเท่านั้น

การวางแผนรับมือการเปลี่ยนแปลงในสถาปัตยกรรมซอฟต์แวร์เป็นเรื่อง ยาก Evolutionary architecture practice ช่วยรับมือกับภูมิทัศน์ทางธุรกิจที่เปลี่ยนแปลงตลอดเวลา เช่นเดียวกับ iterative architecture การยอมรับ architectural characteristics เช่น portability , scalability , evolvability และ adaptability ก็ช่วยทำให้สถาปัตยกรรมซอฟต์แวร์มีความยืดหยุ่นและปรับตัวรับการเปลี่ยนแปลงได้มากขึ้นเช่นกัน

Barry O’Reilly สถาปนิกซอฟต์แวร์ผู้มีประสบการณ์เชี่ยวชาญด้าน complexity theory และ software design ได้คิดค้นวิธีคิดใหม่เกี่ยวกับการเปลี่ยนแปลงทางธุรกิจที่เกิดขึ้นตลอดเวลา เรียกว่า residuality theory ในหนังสือของเขา Residues: Time, Change, and Uncertainty in Software Architecture (Leanpub, 2024) O’Reilly อธิบายเทคนิคในการมองการเปลี่ยนแปลงทางธุรกิจเป็น stressor และมองการเปลี่ยนแปลงทางสถาปัตยกรรมที่ตามมาเป็น residue ทฤษฎีของเขาคือ เมื่อสถาปนิกตอบสนองต่อการเปลี่ยนแปลงโดยการเพิ่ม residue เข้าไปในสถาปัตยกรรมมากขึ้นเรื่อยๆ residue เหล่านี้ในที่สุดจะเริ่มรับมือกับการเปลี่ยนแปลงที่ ไม่รู้ ล่วงหน้าซึ่งสถาปนิกไม่มีทางคาดการณ์ได้ สร้างสถาปัตยกรรมที่เข้าถึงสภาวะวิกฤต (critical state) ภายใน complexity theory เป็นทฤษฎีที่น่าสนใจ ซึ่งเรากำลังจับตามองอย่างใกล้ชิด