Legacy System มรดกคนไอที ที่ไม่อยากได้รับ

ทำไมเมื่อผู้ว่าจ้างต้องการหานักพัฒนาไปพัฒนาระบบแล้วบอกว่า "ต้องเชื่อมต่อกับระบบเดิมนะ" เมื่อสอบถามกลับไปว่ามีคนดูแลระบบเดิมมั้ย มี ER-Diagram, Data Flow หรือคนทำ API ให้มั้ย หากคำตอบที่ได้ว่าข้อมูลเหล่านี้มีน้อยหรือไม่มี นักพัฒนาจะขยาดไม่อยากรับงานแบบนี้ เพราะมีความเสี่ยงสูง เพราะระบบเดิม ฟังดูแล้วเหมือนจะมีความ Legacy สูงมาก มีความเสี่ยงที่พัฒนาระบบนี้ไม่สำเร็จ ส่งมอบไม่ได้ จึงไม่เสี่ยงที่จะรับงาน แล้ว Legacy System คืออะไรละ ?

Legacy System

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

ปัจจัยและปัญหาในการดูแลระบบ Legacy System

1. เทคโนโลยีล้าสมัย ไม่มีผู้พัฒนาดูแลต่อ
2. ไม่มีเอกสาร องค์ความรู้ ทั้งทางธุรกิจและเทคนิค หรือองค์ความรู้ไม่อัพเดต
3. ไม่สามารถขยายฟังก์ชั่น ฟีเจอร์ใหม่ๆ เนื่องจากการออกแบบ เลือกเทคโนโลยี ไม่เหมาะสม หรือไม่ทันสมัย
4. ไม่สามารถเชื่อมต่อระบบอื่นๆ เทคโนโลยีอื่นๆ Protocol อื่นๆได้
5. มีช่องโหว่ด้านความปลอดภัยมาก
6. ไม่รองรับการขยายระบบ เมื่อผู้ใช้งานเพิ่มสูงขึ้น
7. ต้องคอยแก้ปัญหา Dependencies อยู่เป็นประจำ เช่น แก้ฟังก์ชั่นหนึ่ง ไปกระทบอีกหลายหน้าจอ หลายระบบผิดหรือพังไปด้วย
8. คอขวดเรื่อง Performance เช่น การจะประมวลผลเรื่องคำนวณผลตอบแทนให้ลูกค้าเพียงไม่กี่คน แต่ไปกระทบกับส่วนงานอื่น หรือลูกค้าคนอื่นใช้งานไม่ได้ไปด้วย
9. ช่องว่างเรื่องความรู้และทักษะของคนในองค์กร ทั้งทางธุรกิจและเทคนิค ระบบของเรามีคนรู้ลึกรู้มากดูแลได้และแก้ปัญหาได้แค่ไหน
10. ความเสี่ยงผลกระทบกับการดำเนินกิจการและธุรกิจ เมื่อพบเห็นข้อใดหนึ่งจาก 9 ข้อ ก็เริ่มมีความเสี่ยงต่อการดำเนินธุรกิจ ถ้ามีทั้ง 9 ข้อเป็นความเสี่ยงระดับรุนแรง ที่มี Use case จริงที่ทำให้บริษัทปิดตัวลงได้ เพราะมีระบบที่ใช้งานจริงแล้วแต่ดูแลไม่ได้หลายอย่างมาก

ภายใต้แอพพลิเคชั่นที่สวยงาม อาจต้องทำงานร่วมกับ Legacy System ซึ่งมีปัญหาต่างๆมากมายซ่อนอยู่ภายใต้ภูเขาน้ำแข็ง

แล้วระบบเราเป็น Legacy System มั้ย ?

Legacy System ถ้ายังไม่ได้รับส่งมอบต้องมาดูแลแทนทีมที่พัฒนาก่อนหน้านี้ก็ยังไม่ถือว่าเป็นมรดกตกทอดมา ก็ยังไม่ถือว่าเป็น Legacy เพราะทีมที่พัฒนาเดิมยังดูแลอยู่ไม่ได้เกี่ยวกับว่า ระบบนั้นอายุมากเสมอไป ระบบใหม่ๆเทคใหม่ๆก็เป็น Legacy ได้ ถ้าทีมเดิมไม่อยู่ดูแล้ว แล้วต้องส่งมอบให้ทีมอื่นดูแล ถ้ามีการถ่ายทอดองค์ความรู้ให้ทีมใหม่ดูแลต่อได้ ก็เป็นมรดกที่ดี ส่วนใหญ่แล้วมักจะไม่ มักจะเป็นมรดกที่ตามมาด้วยหนี้ที่ต้องชดใช้ เต็มไปด้วย Technical Debt ส่วนของโค้ดที่ใช้งานได้แต่ไม่รู้ว่าทำงานยังไงทำไปเพื่ออะไร ทำให้นักพัฒนาขยาดเมื่อต้องรู้ว่าต้องทำงานกับ Legacy เป็นหนี้ที่เราต้องจ่ายจากการต้องดูแลปัญหาที่เกิดจากมัน ต้องคอยแก้ไขหรือ Workaround อยู่เรื่อยๆ เกิดขึ้นได้ในทุกระบบ เพียงแต่ใน Legacy จะมี Technical Debt เยอะกว่าระบบที่มีนักพัฒนาผู้สร้างระบบขึ้นมาดูแลอยู่ เพราะ Legacy ขาดทีมตั้งต้นที่รับรู้ Requirement มาตั้งแต่แรก

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

แนวทางการลดละเลิกใช้ Legacy System

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

แนวทางการแก้ไข
โดยส่วนใหญ่จะพยามลด ละ เลิก เพราะถ้าได้มรดกที่ทีมใหม่ดูแลไม่ได้ ก็อยากจะเปลี่ยนเป็นของที่ตัวเองถนัดและดูแลได้มากกว่าที่จะมาดูแลของเดิม แต่ก็ไม่สามารถยกเลิกได้ทันที เพราะระบบเดิมใช้เวลาและงบประมาณในการสร้างไปมากและมีการใช้งานจริงแล้ว ไม่สามารถหาของใหม่มาแทนที่ได้ทันที

สำหรับระบบ Legacy
ระยะสั้น

• ทำระบบใหม่ Business Unit ใหม่ที่รองรับบริการลูกค้าแต่จำเป็นเชื่อมต่อข้อมูลบางส่วน เช่น ข้อมูลลูกค้า, พนักงาน, สินค้า, ยอดการขายต่างๆ ขึ้นอยู่กับความจำเป็นของงานนั้นๆ ค่อยๆถอดองค์ความรู้จากการทำ Reverse Engineering เพื่อทำระบบใหม่เพื่อรองรับการใช้งานลูกค้าเพื่อแก้ปัญหา Performance อาจจะมีการส่งข้อมูลบางอย่างกลับไประบบเดิมในส่วนที่ระบบใหม่ยังประมวลผลแทนทำงานแทนไม่ได้ ทั้งนี้ต้องมี Business Domain และ Management สนับสนุนด้วย

ระยะกลาง

• ขยายขอบเขตจากระยะสั้น เริ่มลดบทบาทของ Legacy System ลง

ระยะยาว

• Migrate ข้อมูลจากระบบ Legacy แทนที่ด้วยระบบใหม่ทั้งหมด

แนวการป้องกันไม่ให้ระบบเป็น Legacy ที่ไม่ดีในอนาคต

1. มีระบบตรวจสอบ Monitoring, Alert, Notification การทำงานของแต่ละฟังก์ชั่น
2. อัพเดตความรู้ทั้งทางธุรกิจและเทคนิคให้คนในองค์กรอยู่เสมอ มีคนรู้เรื่องสำคัญที่มีผลต่อการทำงานของระบบมากกว่าหนึ่งคน เช่น อบรม, สัมนา, Pair Programming, Review Code (ข้อนี้ก็ยากสุดๆแล้วในหลายองค์กร เพราะอยากจะขับเคลื่อนอยู่ตลอด ไม่ค่อยให้ความสำคัญกับแบ่งเวลามาดูแล)
3. ตรวจสอบ Technical Debt และลดงานในส่วนนั้นลง
4. จัดทำเอกสารในองค์ความรู้ที่สำคัญที่จะทำให้ทีมดูแลระบบต่อไปได้

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

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

วันนี้ระบบที่คุณกำลังพัฒนาหรือใช้งาน ขาดการดูแล มีแววจะกลายเป็น Legacy ในอนาคตแล้วหรือยัง ? ทำซอฟท์แวร์ให้ดีนี่ยากเนอะ ต้องรู้อะไรตั้งหลายอย่าง ต้องมาดูแลมันอีก ทั้งงานที่ตัวเองทำ งานที่คนอื่นทำ เขียนโปรแกรมว่ายากแล้ว ดูแลมันให้ดีเป็นเรื่องที่ยากขึ้นไปอีก การทำซอฟท์ฺแวร์มันง่ายแค่งานเสกลเล็กๆเท่านั้นแหละ