Measuring Architecture Characteristics (การวัดผล Architecture Characteristics)

สถาปนิกมักดิ้นรนกับการนิยาม architectural characteristics ด้วยเหตุผลหลายประการ

They aren't physics (มันไม่ใช่วิชาฟิสิกส์)

architecture characteristics ที่ใช้กันทั่วไปหลายตัวมีความหมายที่คลุมเครือ ยกตัวอย่างเช่น สถาปนิกจะออกแบบเพื่อ agility หรือ deployability ได้อย่างไร แล้ว wicked fast performance ล่ะ คนในวงการต่างมีมุมมองที่แตกต่างกันอย่างมากต่อคำศัพท์ทั่วไปเหล่านี้ — บางครั้งก็มาจากบริบทที่ต่างกันจริง ๆ บางครั้งก็เกิดจากความบังเอิญ

Wildly varying definitions (คำนิยามที่แตกต่างกันอย่างสุดขั้ว)

แม้แต่ในองค์กรเดียวกัน แผนกต่าง ๆ ก็อาจเห็นไม่ตรงกันเกี่ยวกับนิยามของ characteristic สำคัญอย่าง performance ตราบใดที่นักพัฒนา สถาปนิก ฝ่ายปฏิบัติการ และคนอื่น ๆ ยังไม่สามารถรวมเป็นนิยามเดียวกันได้ พวกเขาจะสนทนากันอย่างเข้าใจตรงกันได้อย่างไร

Too composite (ประกอบซ้อนกันเกินไป)

architecture characteristics ที่พึงประสงค์หลายตัวจริง ๆ แล้วเป็นการรวมกันของ characteristics ย่อยอีกที ตามที่เราได้พูดถึงเรื่อง composite architectural characteristics ไว้ใน Chapter 5 ตัวอย่างเช่น agility แตกออกเป็น characteristics ต่าง ๆ เช่น modularity, deployability และ testability

การแตก composite architectural characteristics ออกเป็นส่วนประกอบย่อย ๆ เป็นขั้นตอนสำคัญในการสร้างนิยามที่เป็นภววิสัย (objective) ให้กับ architecture characteristics ซึ่งช่วยแก้ปัญหาทั้งสามข้อข้างต้นได้

เมื่อองค์กรตกลงกันว่าทุกคนจะใช้นิยามมาตรฐานที่เป็นรูปธรรมสำหรับ architecture characteristics พวกเขาก็จะสร้าง ubiquitous language รอบ ๆ เรื่อง architecture ขึ้นมา การทำให้เป็นมาตรฐานแบบนี้ช่วยให้พวกเขาแกะ composite characteristics ออกมาเจอฟีเจอร์ที่ วัดผลได้อย่างเป็นภววิสัย (objectively measurable)

Operational Measures (การวัดผลด้านปฏิบัติการ)

architecture characteristics หลายตัวมีวิธีวัดผลโดยตรงที่ชัดเจน เช่น performance หรือ scalability แต่ถึงอย่างนั้นก็ยังตีความได้หลายแบบตามเป้าหมายของแต่ละทีม ตัวอย่างเช่น สมมติว่าทีมของคุณวัด average response time ของ request บางประเภท — นี่เป็นตัวอย่างที่ดีของการวัด operational architecture characteristic แต่ถ้าทีมวัดแค่ค่าเฉลี่ย จะเกิดอะไรขึ้นถ้ามี boundary condition บางอย่างที่ทำให้ 1% ของ request ใช้เวลานานกว่าที่อื่นถึง 10 เท่า ถ้าเว็บไซต์มี traffic มากพอ outlier เหล่านี้อาจไม่โผล่ให้เห็นเลยด้วยซ้ำ เพื่อจับ outlier ให้ได้ คุณอาจต้องวัด maximum response time ด้วย

ทีมระดับสูงไม่ได้แค่ตั้งตัวเลข performance ตายตัว แต่พวกเขาอิงนิยามของตัวเองจากการวิเคราะห์เชิงสถิติ ตัวอย่างเช่น สมมติบริการสตรีมมิงวิดีโอต้องการมอนิเตอร์ scalability แทนที่จะตั้งตัวเลขเป้าหมายแบบสุ่ม ๆ วิศวกรจะวัดสเกลตามเวลาแล้วสร้างโมเดลเชิงสถิติขึ้นมา จากนั้นแจ้งเตือนหากค่าที่วัดได้แบบเรียลไทม์เบี่ยงเบนไปจากโมเดลที่พยากรณ์ไว้ ถ้าเกิดขึ้น ความล้มเหลวนี้อาจหมายถึงสองอย่าง คือโมเดลผิด (ซึ่งทีมอยากรู้) หรือมีบางอย่างผิดปกติเกิดขึ้นจริง (ซึ่งทีมก็อยากรู้เช่นกัน)

ประเภทของ characteristics ที่ทีมวัดผลนั้นเปลี่ยนแปลงอย่างรวดเร็วไปพร้อมกับเครื่องมือ เป้าหมาย อุปกรณ์ และความสามารถต่าง ๆ ตัวอย่างเช่น ช่วงหลังหลายทีมโฟกัสไปที่ performance budget สำหรับ metric อย่าง first contentful paint และ first CPU idle ซึ่งทั้งสองตัวบอกอะไรได้มากเกี่ยวกับปัญหา performance ของผู้ใช้เว็บเพจบนมือถือ เมื่อสิ่งเหล่านี้และอื่น ๆ อีกมากมายเปลี่ยนแปลงไป ทีมก็จะพบสิ่งใหม่ ๆ และวิธีวัดผลใหม่ ๆ ต่อไปเรื่อย ๆ