Scalability & Technical Debt
ต้นทุนที่แท้จริงของหนี้ทางเทคนิคไม่ใช่โค้ดที่ไม่น่าสนใจ แต่คือว่าการเปลี่ยนแปลงธุรกิจแต่ละครั้งช้าลง มีค่าใช้จ่ายสูงขึ้น และมีความเสี่ยงมากขึ้น เมื่อผลิตภัณฑ์ ผู้ให้บริการ หรือ ตลาดใหม่แต่ละตัวเกี่ยวข้องกับระบบมากขึ้น สถาปัตยกรรมจะเป็นตัวจำกัดการเติบโต
สิ่งที่คุณอาจกำลังเห็น
- การเปลี่ยนแปลงเล็กน้อยต้องการการอัปเดตในหลายระบบหรือฐานข้อมูล
- ผู้ให้บริการ สกุลเงิน หรือ ตลาดใหม่ต้องคัดลอกตรรกะเดิม
- รอบการปล่อยซอฟต์แวร์ยาวขึ้นในขณะที่ความเสี่ยงด้านการถดถอยและการผลิตเพิ่มขึ้น
- ความรู้เชิงวิกฤตอยู่กับวิศวกรเพียงไม่กี่คน
- ทีมทราบว่าจำเป็นต้องปรับปรุงให้ทันสมัย แต่การส่งมอบระยะสั้นมักชนะเสมอ
เหตุใดจึงเกิดขึ้น
ขอบเขตของโดเมนไม่ชัดเจน.
สถานะ กฎระเบียบ และแบบจำลองข้อมูลถูกทำซ้ำ
ตรรกะเฉพาะผู้ให้บริการรั่วไหลเข้าสู่แกนกลาง
ฐานข้อมูลที่ใช้ร่วมกันและการพึ่งพาแบบซิงโครนัสสร้างความสัมพันธ์อย่างแน่นแฟ้น
การทดสอบ การสังเกตการณ์ และการกำกับดูแลการปล่อยซอฟต์แวร์อ่อนแอ
หนี้โครงสร้างถูกเลื่อนอย่างต่อเนื่องหลังการส่งมอบฟีเจอร์
ปัญหามักจะอยู่ที่ใด
Business & Funds
เมื่อผลลัพธ์ทางธุรกิจและสถานะเงินไม่สอดคล้องกัน
Systems & Data
เมื่อรหัสระบุ สถานะ กฎ หรือข้อมูลแตกต่างกันในแต่ละระบบ
การพึ่งพาภายนอก
เมื่อผู้ให้บริการ ธนาคาร หรือเครือข่ายเพิ่มความหมายที่แตกต่างกัน
Controls & Operations
ที่ซึ่งข้อยกเว้น การถือครอง และหลักฐานล้มเหลวในการปิดวงจร
จะเกิดอะไรขึ้นถ้ามันยังคงอยู่
- ความเสี่ยงด้านเงินทุนและผลกระทบต่อลูกค้าสามารถเพิ่มขึ้นก่อนที่ปัญหาจะปรากฏ
- การตรวจสอบด้วยมือและต้นทุนการดำเนินงานเพิ่มขึ้นตามเวลา
- การปิดงบ การตรวจสอบบัญชี และการรายงานการจัดการจะยากต่อความเชื่อถือ
- ขนาดช่วยขยายปัญหาเชิงโครงสร้างที่มีอยู่
เมื่อหนี้สินทางเทคนิคกลายเป็นข้อจำกัดต่อการเติบโต
หากตลาดใหม่ ผลิตภัณฑ์ หรือผู้ให้บริการแต่ละรายต้องมีการเปลี่ยนแปลงที่ไม่สมส่วนต่อระบบหลัก การปล่อยฟีเจอร์ใหม่จะมีความเสี่ยงมากขึ้น หรือทีมงานหลีกเลี่ยงการเปลี่ยนแปลงที่จำเป็นเพราะการเชื่อมโยงและหนี้สินทางเทคนิค กลายเป็นข้อจำกัดทางธุรกิจ
- ทีมสามารถอธิบายปัญหาได้โดยไม่ต้องพึ่งพาคนสำคัญเพียงคนเดียวหรือไม่?
- สามารถติดตามธุรกรรมหรือการเคลื่อนไหวของเงินทุกครั้งตั้งแต่ต้นจนจบได้หรือไม่?
- ข้อยกเว้นถูกจัดประเภท เป็นเจ้าของ และปิดด้วยหลักฐานหรือไม่?
- กฎทำงานได้สม่ำเสมอในผู้ให้บริการและตลาดต่าง ๆ หรือไม่?
- ปัญหาเดิมเกิดซ้ำแม้มีการแก้ไขด้วยตนเองหลายครั้งหรือไม่?
วิธีที่หนี้สินทางเทคนิคกลายเป็นข้อจำกัดในการเติบโตของธุรกิจ
หนี้ทางเทคนิคกลายเป็นเชิงกลยุทธ์เมื่อการเปลี่ยนแปลงไม่เกิดขึ้นเฉพาะท้องถิ่นอีกต่อไป: ทุกผลิตภัณฑ์ ผู้ให้บริการ หรือ ตลาดใหม่ จะกระตุ้นความเสี่ยงการถดถอยอย่างกว้าง ความเสียหายจากการประสานงาน และความไม่แน่นอนในการเปิดตัว
วิธีแก้ไขชั่วคราวในท้องถิ่น
วิธีแก้ไขเล็กน้อยหรือส่วนประกอบที่ทำซ้ำแก้ปัญหาเฉพาะโดยไม่ส่งผลกระทบอย่างมีนัยสำคัญต่อโดเมนอื่น
การเปลี่ยนแปลงซ้ำ ๆ กลายเป็นความเสี่ยง
การเปลี่ยนแปลงทั่วไปส่งผลกระทบต่อหลายบริการหรือเส้นทางโค้ด และการทดสอบถอยหลังขยายตัวเร็วกว่าแม้แต่ฟีเจอร์เอง
ผลิตภัณฑ์หรือตลาดใหม่ต้องมีการเขียนใหม่อย่างกว้างขวาง
การเพิ่มผู้ให้บริการ สกุลเงิน ภูมิภาค หรือผลิตภัณฑ์ซ้ำ ๆ จำเป็นต้องมีการเปลี่ยนแปลงในชั้นธุรกรรม เงิน การดำเนินงาน และรายงาน
ความน่าเชื่อถือและความเร็วในการปล่อยลดลง
รอบการปล่อยช้า เหตุการณ์เพิ่มขึ้น และทีมงานหลีกเลี่ยงการเปลี่ยนแปลงที่จำเป็นเพราะการพึ่งพาซับซ้อนคาดเดาได้ยาก
กลยุทธ์ข้อจำกัดด้านสถาปัตยกรรม
การตัดสินใจทางธุรกิจถูกปฏิเสธ ถูกเลื่อน หรือมีค่าใช้จ่ายเพิ่มขึ้นอย่างมากเพราะแพลตฟอร์มไม่สามารถรองรับการเติบโตหรือการเปลี่ยนแปลงได้อย่างปลอดภัย
ยกระดับจากการปรับปรุงโค้ดภายในท้องถิ่นไปสู่การปรับปรุงสถาปัตยกรรมเมื่อการขยายธุรกิจตามปกติซ้ำแล้วซ้ำเล่าต้องการการเปลี่ยนแปลงข้ามโดเมน ความเสี่ยงจากการปล่อยผลิตภัณฑ์กลายเป็นข้อกังวลด้านการจัดการ หรือสถาปัตยกรรมจำกัดตัวเลือกของผลิตภัณฑ์และตลาดอย่างมีนัยสำคัญ
วิธีแก้ไขปัญหา
โครงสร้างอาการ
แยกอาการที่มองเห็นออกจากสาเหตุที่แท้จริง
สร้างฐานข้อเท็จจริง
ใช้หลักฐานจากธุรกรรม เงิน ระบบ และการดำเนินงาน
แก้ไขโมเดล ไม่ใช่แค่ข้อมูล
แก้ไขกฎโครงสร้างให้ถูกต้องก่อนทำความสะอาดบันทึกประวัติ
ปิดวงจรการควบคุม
ให้ความรับผิดชอบในการยกเว้นแต่ละรายการ การดำเนินการ การตรวจสอบ และการปิด
วัดการเกิดซ้ำ
ใช้ปัญหาที่เกิดซ้ำเพื่อขับเคลื่อนการปรับปรุงผลิตภัณฑ์ สถาปัตยกรรม และการดำเนินงาน
ย้ายจากปัญหาไปยังทางออกที่ถูกต้อง
สถาปัตยกรรมและการปรับปรุงระบบการชำระเงิน
ออกแบบใหม่คอขวดโครงสร้างและพัฒนาระบบผ่านแผนงานปรับปรุงอย่างควบคุม
สำรวจโซลูชัน →การประเมินโครงสร้างพื้นฐานการชำระเงิน
ระบุสาเหตุหลัก ช่องว่างของหลักฐาน และการดำเนินการแก้ไขลำดับความสำคัญในโครงสร้างพื้นฐานการชำระเงิน
สำรวจโซลูชัน →โครงสร้างพื้นฐานการชำระเงินใหม่
รวมความสามารถในการชำระเงินที่เกิดใหม่โดยไม่สร้างแผนกใหม่หรือทำให้การควบคุมหลักอ่อนลง
สำรวจโซลูชัน →คำถามทั่วไป
อาการที่เห็นได้ชัดเป็นสาเหตุรากเหง้าตลอดเวลาหรือไม่?
ปัญหาการชำระเงินมักปรากฏในการกระทบยอด ยอดคงเหลือ หรือการดำเนินงาน ขณะที่สาเหตุที่แท้จริงอยู่ในสถานะ บัญชีแยกประเภท ข้อมูล หรือสถาปัตยกรรม
เราควรแก้ไขข้อมูลเก่าก่อนหรือไม่?
โดยปกติจะเริ่มจากการสร้างโมเดลและฐานการควบคุมก่อน จากนั้นแก้ไขข้อมูลประวัติศาสตร์โดยไม่สร้างปัญหาเดิมซ้ำ
ควรเริ่มการสอบสวนจากจุดไหน?
เริ่มต้นด้วยหลักฐาน: วัฏจักรธุรกรรม การเคลื่อนไหวของเงิน รายการบัญชี หนังสือบันทึกของผู้ให้บริการ การทำงานของกระบวนการ และเหตุการณ์ล่าสุด
เริ่มจากปัญหาที่แท้จริง
จัดโครงสร้างอาการ สาเหตุรากฐาน ผลกระทบ และการควบคุมปัจจุบันก่อนเลือกเส้นทางการแก้ไข