Case Study: The Vasa (กรณีศึกษา: เรือ Vasa)

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

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

การร่วมมือกันระหว่างสถาปนิกและ business stakeholder มีความสำคัญอย่างยิ่งในระหว่างการวิเคราะห์ architectural characteristics อย่างไรก็ตาม หากสถาปนิกเสนอรายการ architectural characteristics ที่เป็นไปได้ยาวเหยียด แล้วถาม business stakeholder ว่าต้องการให้สถาปัตยกรรมรองรับตัวไหนบ้าง คำตอบจะเป็นอะไรทุกครั้งไป? “ทุกตัวเลย!”

ดังนั้น สถาปนิกจึงต้องการเทคนิคในการกำหนดว่า architectural characteristics ตัวไหนขับเคลื่อนการตัดสินใจเชิงโครงสร้างและสำคัญต่อความสำเร็จ ผู้เขียนได้พัฒนาเทคนิคหลายอย่างเพื่ออำนวยความสะดวกในเรื่องนี้ รวมถึง “worksheet” ของ architectural characteristics ดังแสดงใน Figure 5-3 (และดาวน์โหลดได้ที่ https://developertoarchitect.com/resources.html )

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

ทำไมต้องเจ็ด? ทำไมจะไม่ได้ล่ะ? พูดจริง ๆ สถาปนิกต้องจำกัดรายการให้เป็นจำนวนที่สมเหตุสมผลจำนวนหนึ่ง—หกหรือแปดก็ใช้ได้เช่นกัน (แม้จะมีจิตวิทยาที่น่าสนใจอยู่เบื้องหลัง เลขเจ็ด ) คอลัมน์ที่สองประกอบด้วย implicit architectural characteristics บางส่วน ซึ่งปรากฏในระบบส่วนใหญ่ แต่บางครั้งสถาปนิกก็จัดลำดับความสำคัญให้มันเป็นประเด็นขับเคลื่อนของแอปพลิเคชันที่ต้องการการออกแบบและพิจารณาเป็นพิเศษ ในกรณีเหล่านั้น สถาปนิกจะ “ดึง” implicit characteristics เข้ามาในคอลัมน์แรก ถ้าคอลัมน์แรกเต็มแล้วและมีตัวเลือกที่ดีกว่ามาแทนที่ตัวที่มีอยู่ สถาปนิกจะย้ายตัวเดิมไปยังหมวด “Others Considered”

Figure 5-3. Worksheet ของ architectural characteristics

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

สถาปนิกและ domain stakeholder หลายคนอยากจัดลำดับความสำคัญเพื่อให้ได้รายการสุดท้ายของ architectural characteristics ที่แอปพลิเคชันหรือระบบต้องรองรับ แม้นี่จะเป็นผลลัพธ์ที่พึงประสงค์อย่างแน่นอน แต่ในกรณีส่วนใหญ่ มันเป็นความพยายามที่สูญเปล่า ซึ่งไม่เพียงเสียเวลา แต่ยังสร้างความหงุดหงิดและความขัดแย้งที่ไม่จำเป็นกับ stakeholder หลักด้วย แทบไม่มีทางที่ stakeholder ทุกคนจะเห็นตรงกันในลำดับความสำคัญของทุกคุณลักษณะ วิธีที่ดีกว่าคือให้ domain stakeholder เลือกคุณลักษณะที่สำคัญที่สุดสามอันดับแรกจากรายการสุดท้าย (ในลำดับใดก็ได้) วิธีนี้ทำให้การหาฉันทามติง่ายขึ้นมาก และส่งเสริมการพูดคุยเกี่ยวกับสิ่งที่สำคัญที่สุด ทั้งหมดนี้ช่วยให้สถาปนิกวิเคราะห์ trade-off เมื่อต้องตัดสินใจด้านสถาปัตยกรรมที่ สำคัญ