กระบวนการบันทึกการตัดสินใจด้านสถาปัตยกรรมของ AWS

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

บันทึกการตัดสินใจด้านสถาปัตยกรรม (architectural decision record หรือ ADR) คือเอกสารที่อธิบายทางเลือกที่ทีมตัดสินใจเกี่ยวกับแง่มุมสำคัญของสถาปัตยกรรมซอฟต์แวร์ที่วางแผนจะสร้าง แต่ละ ADR อธิบายการตัดสินใจด้านสถาปัตยกรรม บริบท และผลที่ตามมา ADR มีสถานะ จึงเป็นไปตามวงจรชีวิต ดูตัวอย่าง ADR ได้ในภาคผนวก

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

เมื่อทีมยอมรับ ADR แล้ว ADR นั้นจะแก้ไขไม่ได้ (immutable) หากข้อมูลเชิงลึกใหม่ต้องการการตัดสินใจที่แตกต่างออกไป ทีมจะเสนอ ADR ใหม่ เมื่อทีมยอมรับ ADR ใหม่ ADR ใหม่จะมาแทนที่ ADR เดิม

ขอบเขตของกระบวนการ ADR

สมาชิกโครงการควรเขียน ADR สำหรับทุกการตัดสินใจที่มีนัยสำคัญด้านสถาปัตยกรรมซึ่งส่งผลต่อโครงการหรือผลิตภัณฑ์ซอฟต์แวร์ รวมถึง (Richards และ Ford 2020):

• โครงสร้าง (เช่น รูปแบบอย่างไมโครเซอร์วิส)

• ข้อกำหนดที่ไม่ใช่ฟังก์ชัน (ความปลอดภัย ความพร้อมใช้งานสูง ความทนทานต่อข้อผิดพลาด)

• การพึ่งพากัน (การเชื่อมโยงของคอมโพเนนต์)

• อินเทอร์เฟซ (API และสัญญาที่เผยแพร่)

• เทคนิคการก่อสร้าง (ไลบรารี เฟรมเวิร์ก เครื่องมือ กระบวนการ)

• ข้อกำหนดเชิงฟังก์ชันและไม่ใช่ฟังก์ชันเป็นอินพุตที่พบบ่อยที่สุดของกระบวนการ ADR

เนื้อหาของ ADR

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

กระบวนการนำ ADR มาใช้

แม้สมาชิกทีมคนใดก็เขียน ADR ได้ แต่ทีมควรกำหนดนิยามของความเป็นเจ้าของ ADR ผู้เขียนแต่ละคนซึ่งเป็นเจ้าของ ADR ควรดูแลและสื่อสารเนื้อหาของ ADR อย่างกระตือรือร้น เพื่อให้ความเป็นเจ้าของชัดเจน คู่มือนี้จึงเรียกผู้เขียน ADR ว่าเจ้าของ ADR ในส่วนต่อ ๆ ไป สมาชิกทีมคนอื่นสามารถมีส่วนร่วมกับ ADR ได้ทุกเมื่อ หากเนื้อหาของ ADR เปลี่ยนไปก่อนที่ทีมจะยอมรับ ADR เจ้าของต้องอนุมัติการเปลี่ยนแปลงเหล่านั้น

หลังจากทีมระบุการตัดสินใจด้านสถาปัตยกรรมและเจ้าของแล้ว เจ้าของ ADR จะนำเสนอ ADR ที่มีสถานะ Proposed (เสนอ) ในช่วงต้นของกระบวนการ ADR ที่มีสถานะ Proposed พร้อมสำหรับการทบทวน

จากนั้นเจ้าของ ADR เริ่มกระบวนการทบทวนสำหรับ ADR นั้น เป้าหมายของกระบวนการทบทวน ADR คือให้ทีมตัดสินใจว่าจะยอมรับ ADR พิจารณาว่าต้องแก้ไขใหม่ หรือปฏิเสธ ADR ทีมโครงการรวมถึงเจ้าของจะทบทวน ADR การประชุมทบทวนควรเริ่มด้วยเวลาที่กันไว้สำหรับอ่าน ADR โดยเฉลี่ยแล้ว 10–15 นาทีก็เพียงพอ ในช่วงเวลานี้ สมาชิกทีมแต่ละคนเพิ่มความเห็นและคำถามเพื่อทำเครื่องหมายหัวข้อที่ไม่ชัดเจน เมื่อสิ้นสุดขั้นตอนการทบทวน เจ้าของ ADR อ่านทุกความเห็นและหารือกับทีม

เมื่อทีมพบรายการที่ต้องดำเนินการเพื่อปรับปรุง ADR สถานะของ ADR จะยังคงเป็น Proposed เจ้าของ ADR รวบรวมรายการดำเนินการและทำงานร่วมกับทีมเพื่อมอบหมายผู้รับผิดชอบแต่ละรายการ สมาชิกทีมคนใดก็ช่วยรายการดำเนินการและแก้ไขได้ เจ้าของ ADR มีหน้าที่นัดกระบวนการทบทวนใหม่

ทีมอาจตัดสินใจปฏิเสธ ADR ก็ได้ ในกรณีนั้น เจ้าของ ADR เพิ่มเหตุผลของการปฏิเสธเพื่อป้องกันการอภิปรายซ้ำในหัวข้อเดิมในอนาคต เจ้าของเปลี่ยนสถานะของ ADR เป็น Rejected (ปฏิเสธ)

เมื่อทีมอนุมัติ ADR เจ้าของเพิ่มการประทับเวลา เวอร์ชัน และรายชื่อผู้มีส่วนได้ส่วนเสีย จากนั้นเจ้าของอัปเดตสถานะเป็น Accepted (ยอมรับ)

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

ตามแนวปฏิบัติที่ดี การเปลี่ยนแปลงซอฟต์แวร์ทั้งหมดควรผ่านการทบทวนโดยเพื่อนร่วมงานและต้องได้รับการอนุมัติอย่างน้อยหนึ่งครั้ง ระหว่างการทบทวนโค้ด ผู้ทบทวนอาจพบการเปลี่ยนแปลงที่ละเมิด ADR อย่างน้อยหนึ่งฉบับ ในกรณีนั้น ผู้ทบทวนขอให้ผู้เขียนการเปลี่ยนแปลงโค้ดแก้ไขโค้ดและแชร์ลิงก์ไปยัง ADR เมื่อผู้เขียนแก้ไขโค้ดแล้ว จะได้รับการอนุมัติจากผู้ทบทวนที่เป็นเพื่อนร่วมงาน และโค้ดจะถูกรวมเข้ากับโค้ดเบสหลัก

กระบวนการทบทวน ADR

หลังจากทีมยอมรับหรือปฏิเสธ ADR แล้ว ควรถือว่าเป็นเอกสารที่แก้ไขไม่ได้ หากต้องการเปลี่ยน ADR ที่มีอยู่ ทีมต้องเขียน ADR ใหม่ กำหนดกระบวนการทบทวนสำหรับ ADR ใหม่ และอนุมัติ ADR เมื่อทีมอนุมัติ ADR ใหม่ เจ้าของต้องเปลี่ยนสถานะของ ADR เดิมเป็น Superseded (ถูกแทนที่)