Composite Architectural Characteristics (Architectural Characteristics แบบผสม)

เมื่อแปลประเด็นของ domain ให้เป็น architectural characteristics กับดักที่พบบ่อยอย่างหนึ่งคือการเทียบเท่าแบบผิด ๆ เช่น การมอง agility ว่าเป็นแค่ time to market เท่านั้น Agility เป็นตัวอย่างของ architectural characteristic แบบ composite นั่นคือ ไม่มีนิยามที่เป็นภววิสัยเพียงหนึ่งเดียว แต่ประกอบขึ้นจากสิ่งอื่นที่วัดผลได้หลายอย่าง ไม่มีวิธีวัด agility โดยตรง สถาปนิกจึงต้องถามว่า agility ประกอบด้วยอะไรบ้าง? มันรวมถึงสิ่งต่าง ๆ เช่น deployability , modularity และ testability ซึ่งทั้งหมดวัดผลได้

antipattern ที่พบบ่อยเกิดขึ้นเมื่อสถาปนิกโฟกัสแคบ ๆ ที่ส่วนใดส่วนหนึ่งของ composite เท่านั้น มักเพื่อความสะดวก สิ่งนี้เหมือนกับการลืมใส่แป้งลงในเนื้อเค้ก ตัวอย่างเช่น domain stakeholder อาจพูดประมาณว่า “เนื่องจากข้อกำหนดทางกฎหมาย เป็นเรื่องจำเป็นอย่างยิ่งที่เราต้องทำการคำนวณราคากองทุนสิ้นวันให้เสร็จตรงเวลา”

สถาปนิกที่ไม่มีประสิทธิภาพอาจตอบสนองด้วยการโฟกัสที่ performance เพียงอย่างเดียว เพราะดูเหมือนจะเป็นจุดสนใจหลักของประเด็นด้าน domain นี้ อย่างไรก็ตาม แนวทางนี้จะล้มเหลว ด้วยเหตุผลหลายประการ:

• ไม่สำคัญเลยว่าระบบจะเร็วแค่ไหน ถ้ามันไม่พร้อมใช้งานเมื่อจำเป็น

• เมื่อ domain เติบโตขึ้นและมีการสร้างกองทุนเพิ่มขึ้น ระบบต้อง scale ได้เพื่อทำการประมวลผลสิ้นวันให้เสร็จทันเวลา

• ระบบไม่เพียงต้องพร้อมใช้งานเท่านั้น แต่ยังต้องเชื่อถือได้ (reliable) ด้วย เพื่อไม่ให้ล่มขณะที่กำลังคำนวณราคากองทุนสิ้นวัน

• จะเกิดอะไรขึ้นถ้าระบบล่มขณะที่การคำนวณราคากองทุนสิ้นวันเสร็จไปแล้ว 85%? ระบบต้องสามารถกู้คืนและเริ่มการคำนวณต่อจากจุดที่ค้างไว้ได้

• สุดท้าย ระบบอาจเร็ว แต่ราคากองทุนที่คำนวณได้ถูกต้องหรือไม่?

ดังนั้น นอกเหนือจาก performance แล้ว สถาปนิกคนนี้ต้องให้ความสำคัญเท่า ๆ กันกับ availability, scalability, reliability, recoverability และ auditability ด้วย

เป้าหมายทางธุรกิจหลายอย่างเริ่มต้นในรูปของ composite architectural characteristics การแตกย่อยมันออกมาและกำหนดนิยามที่เป็นภววิสัยให้กับคุณลักษณะที่ได้ เป็นส่วนหนึ่งของงานสถาปนิก (เราจะเห็นความสำคัญของเรื่องนี้ใน Chapter 6 )