Architecture Decision Record

Active theme: Light

← แม่แบบบันทึกการตัดสินใจ

แม่แบบบันทึกการตัดสินใจโดย Jeff Tyree และ Art Akerman

นี่คือแม่แบบสำหรับอธิบายการตัดสินใจด้านสถาปัตยกรรมจาก "Architecture Decisions: Demystifying Architecture", Jeff Tyree และ Art Akerman, Capital One Financial

  • ประเด็น (Issue): อธิบายปัญหาการออกแบบสถาปัตยกรรมที่กำลังตอบสนอง ไม่ให้เหลือข้อสงสัยว่าทำไมคุณจึงตอบสนองตอนนี้ ตามแนวทางมินิมัล ให้จัดการและบันทึกเฉพาะประเด็นที่ต้องการความสนใจในจุดต่าง ๆ ของวงจรชีวิต

  • การตัดสินใจ (Decision): ระบุทิศทางสถาปัตยกรรมอย่างชัดเจน กล่าวคือจุดยืนที่เลือก

  • สถานะ (Status): สถานะของการตัดสินใจ เช่น pending, decided, approved

  • กลุ่ม (Group): คุณใช้การจัดกลุ่มอย่างง่าย เช่น การบูรณาการ การนำเสนอ ข้อมูล ฯลฯ เพื่อช่วยจัดระเบียบชุดการตัดสินใจได้ คุณอาจใช้ออนโทโลยีสถาปัตยกรรมที่ละเอียดกว่า เช่น ของ John Kyaruzi และ Jan van Katwijk ที่มีหมวดหมู่เชิงนามธรรมมากขึ้น เช่น เหตุการณ์ ปฏิทิน และสถานที่ ด้วยออนโทโลยีนี้ ตัวอย่างเช่น คุณจะจัดกลุ่มการตัดสินใจที่ตอบสนองสถานการณ์ที่ระบบต้องการข้อมูลไว้ภายใต้เหตุการณ์

  • สมมติฐาน (Assumptions): อธิบายสมมติฐานพื้นฐานอย่างชัดเจนในสภาพแวดล้อมที่ทำการตัดสินใจ: ต้นทุน กำหนดการ เทคโนโลยี และอื่น ๆ โปรดทราบว่าข้อจำกัดด้านสภาพแวดล้อม (เช่น มาตรฐานเทคโนโลยีที่ยอมรับ สถาปัตยกรรมองค์กร รูปแบบที่ใช้กันทั่วไป) อาจจำกัดทางเลือกที่พิจารณา

  • ข้อจำกัด (Constraints): บันทึกข้อจำกัดเพิ่มเติมที่ทางเลือกที่เลือก (การตัดสินใจ) อาจกำหนดต่อสภาพแวดล้อม

  • จุดยืน (Positions): ระบุจุดยืนที่พิจารณา (ตัวเลือกที่เป็นไปได้หรือทางเลือก) ซึ่งมักต้องอธิบายยาวและบางครั้งถึงขั้นต้องมีแบบจำลองและแผนภาพ นี่ไม่จำเป็นต้องเป็นรายการครบถ้วน แต่คุณคงไม่อยากได้ยินคำถามว่า "คุณคิดถึง ... หรือยัง" ในการทบทวนครั้งสุดท้าย เพราะนำไปสู่การสูญเสียความเชื่อมั่นและข้อสงสัยต่อการตัดสินใจด้านสถาปัตยกรรมอื่น ส่วนนี้ยังช่วยยืนยันว่าคุณรับฟังความเห็นของผู้อื่น การทำให้ความเห็นอื่นชัดเจนช่วยดึงผู้สนับสนุนมาอยู่ฝ่ายเดียวกับการตัดสินใจของคุณ

  • ข้อโต้แย้ง (Argument): ร่างว่าทำไมคุณจึงเลือกจุดยืนหนึ่ง ด้วยหัวข้อเช่น ต้นทุนการนำไปใช้ ต้นทุนรวมของการเป็นเจ้าของ เวลาออกสู่ตลาด และความพร้อมของทรัพยากรพัฒนาที่จำเป็น ซึ่งน่าจะสำคัญพอ ๆ กับตัวการตัดสินใจเอง

  • นัยยะ (Implications): การตัดสินใจมีนัยยะมากมาย ดังที่เมทาโมเดล REMAP แสดง ตัวอย่างเช่น การตัดสินใจอาจสร้างความจำเป็นต้องทำการตัดสินใจอื่น สร้างข้อกำหนดใหม่หรือแก้ไขข้อกำหนดที่มีอยู่ กำหนดข้อจำกัดเพิ่มเติมต่อสภาพแวดล้อม ต้องเจรจาขอบเขตหรือกำหนดการใหม่กับลูกค้า หรือต้องฝึกอบรมบุคลากรเพิ่มเติม การเข้าใจและระบุนัยยะของการตัดสินใจอย่างชัดเจนอาจมีประสิทธิผลมากในการได้รับความเห็นชอบและสร้างแผนที่นำทางสำหรับการดำเนินการตามสถาปัตยกรรม

  • การตัดสินใจที่เกี่ยวข้อง: เห็นได้ชัดว่าการตัดสินใจจำนวนมากเกี่ยวข้องกัน คุณระบุไว้ที่นี่ได้ แต่ในทางปฏิบัติ เราพบว่าเมทริกซ์การติดตาม ต้นไม้การตัดสินใจ หรือเมทาโมเดลมีประโยชน์กว่า เมทาโมเดลมีประโยชน์ในการแสดงความสัมพันธ์ที่ซับซ้อนในแผนภาพ (เช่น โมเดล Rose)

  • ข้อกำหนดที่เกี่ยวข้อง: การตัดสินใจควรขับเคลื่อนโดยธุรกิจ เพื่อแสดงความรับผิดชอบ ให้เชื่อมโยงการตัดสินใจกับเป้าหมายหรือข้อกำหนดอย่างชัดเจน คุณระบุข้อกำหนดที่เกี่ยวข้องเหล่านี้ไว้ที่นี่ได้ แต่เราพบว่าสะดวกกว่าที่จะอ้างอิงเมทริกซ์การติดตาม คุณประเมินระดับที่แต่ละการตัดสินใจด้านสถาปัตยกรรมมีส่วนช่วยตอบสนองแต่ละข้อกำหนด จากนั้นประเมินว่าข้อกำหนดได้รับการตอบสนองดีเพียงใดในทุกการตัดสินใจ หากการตัดสินใจไม่ช่วยตอบสนองข้อกำหนดใด อย่าทำการตัดสินใจนั้น

  • ผลงานที่เกี่ยวข้อง: ระบุเอกสารด้านสถาปัตยกรรม การออกแบบ หรือขอบเขตที่เกี่ยวข้องซึ่งการตัดสินใจนี้ส่งผลกระทบ

  • หลักการที่เกี่ยวข้อง: หากบริษัทมีชุดหลักการที่ตกลงกัน ให้แน่ใจว่าการตัดสินใจสอดคล้องกับหลักการอย่างน้อยหนึ่งข้อ ซึ่งช่วยให้แน่ใจถึงความสอดคล้องข้ามโดเมนหรือระบบ

  • บันทึก: เนื่องจากกระบวนการตัดสินใจอาจใช้เวลาหลายสัปดาห์ เราพบว่ามีประโยชน์ที่จะบันทึกหมายเหตุและประเด็นที่ทีมหารือระหว่างการแบ่งปันเบื้องต้น