นามธรรม
มีคำแนะนำที่ชัดเจนสำหรับแอ็พพลิเคชัน IBM i ที่จะปรับปรุงให้ทันสมัยหรือโอนย้ายไปยังแพลตฟอร์มแห่งอนาคต และมีความลังเลใจอย่างมากเช่นกัน ซึ่งทำให้เกิดความรู้สึกต่อต้านการย้ายข้อมูล สิ่งนี้นำเราไปสู่คำถาม เราจำเป็นต้องลงทุนในชุดทักษะหรือไม่
ของแพลตฟอร์มที่มีอยู่หรือไม่?
ขององค์กร
IBM i เป็นระบบดั้งเดิม มีเป้าหมายสำหรับการโอนย้ายโดยองค์กรจำนวนมากเนื่องจากเหตุผลหลายประการ ในบล็อกนี้ เราจะสำรวจตัวเลือกที่มีอยู่สำหรับการย้ายข้อมูลในสถานการณ์ปัจจุบัน ความน่าจะเป็นในการนำไปใช้ เหตุผลที่ไม่ติดตามอย่างรวดเร็ว
การโยกย้ายหรือออกและความจำเป็นในการยกระดับบุคลากรด้านการพัฒนา
IBM i (รู้จักกันอย่างกว้างขวางในชื่อ AS/400) เป็นหนึ่งในระบบเชิงกลยุทธ์ที่ดีที่สุดสำหรับองค์กรขนาดกลางถึงขนาดใหญ่หลายแห่ง รวมทั้งการธนาคาร บริการทางการเงิน และการประกันภัย (BFSI) มีการใช้งานโดยองค์กรเหล่านี้มานานกว่า 25 ถึง 30 ปี มันเป็นเจ้าภาพหลัก
แอปพลิเคชันสำหรับธนาคารและบริษัทประกัน ได้แก่ Core Banking, Card Management, Policy Administration เป็นต้น IBM i ที่เราพูดถึงในที่นี้คือระบบนิเวศทั้งหมดที่มาพร้อมกับ IBM i, ฮาร์ดแวร์, ระบบปฏิบัติการ, ภาษาการเขียนโปรแกรม เช่น RPG,
ภาษาโคบอลและ CL, ฐานข้อมูล DB2 สำหรับ i, IBM MQ สำหรับการส่งข้อความ, การจัดการงาน, การเข้าถึงของผู้ใช้, การรักษาความปลอดภัย ฯลฯ การปรับปรุงมรดกให้ทันสมัยอยู่ในการสนทนาภายในธนาคารเป็นเวลาหลายปีแล้ว และ IBM i ยังอยู่ในเรดาร์สำหรับการแทนที่ด้วยเทคโนโลยีใหม่ เนื่องจาก ความท้าทาย
เกี่ยวข้องกับชุดทักษะเฉพาะของแพลตฟอร์ม IBM i (RPG, COBOL), สถาปัตยกรรมแบบ monolith ของแอปพลิเคชันที่นำไปสู่ปัญหาด้านความคล่องตัว, การทำงานร่วมกันกับแพลตฟอร์มอื่นและเครื่องมือ DevOps, ไม่สอดคล้องกับการลงทุนเชิงกลยุทธ์, ขาดประโยชน์ส่วนใหญ่ของคลาวด์ (เช่น
ความจุตามต้องการ) เป็นต้น ในขณะเดียวกันก็มีสาเหตุหลายประการที่ทำให้การโยกย้ายถูกเลื่อนออกไป บางส่วน ได้แก่ การเปิดตัวฮาร์ดแวร์ใหม่ การเปิดตัวระบบปฏิบัติการ หน้าต่างการสนับสนุนที่ขยาย การลงทุนในปัจจุบันบนโครงสร้างพื้นฐานจำนวนมาก ความเสี่ยงและต้นทุนการย้ายข้อมูล
ที่นี่ เราพยายามที่จะวัดความเป็นไปได้ในช่วงต้นของการออกจากระบบ เพื่อให้การคาดการณ์การพึ่งพาธุรกิจขนาดกลางและขนาดย่อม
มุมมองของเรา
ในช่วงระยะเวลาหนึ่ง ธุรกิจเติบโตขึ้น ความต้องการทางธุรกิจเพิ่มขึ้น ความเสี่ยงต่างๆ เพิ่มขึ้น ข้อกำหนดด้านการปฏิบัติตามกฎระเบียบและกฎระเบียบต่างๆ เติบโตขึ้น และในที่สุดสิ่งเหล่านี้ทั้งหมดก็ได้รับการรวบรวมและดูแลภายในแอปพลิเคชันเดียวสำหรับแต่ละแอปพลิเคชัน
องค์กร. และด้วยเหตุนี้ความซับซ้อนระดับสูงจึงมีความเข้มข้นของความรู้ทั้งหมด กฎทางธุรกิจ กระบวนการทางธุรกิจ เพิ่มการใช้งานทางเทคนิคทั้งหมด เช่น มัลติเธรด การส่งข้อความ การจัดตารางงาน การควบคุมงาน ฯลฯ
เป็นส่วนหนึ่งของการดำเนินการแบบโมโนลิธด้วย
ด้วยการเกิดขึ้นของ Cloud, DevOps และแนวทางปฏิบัติแบบ Agile อุตสาหกรรมและองค์กรต่างๆ รวมถึงนายธนาคารและบริษัทประกันกำลังมองหาการเปลี่ยนแปลงของแอปพลิเคชัน IBM i รวมทั้งเพื่อเก็บเกี่ยวคุณสมบัติและประโยชน์ล่าสุด องค์กรมีหลายทางเลือก
ต่อหน้าพวกเขา แพลตฟอร์มนี้สามารถปฏิบัติตามแนวทางปฏิบัติที่คล่องตัวและเป็นส่วนหนึ่งของโลก DevOps ด้วยโซลูชัน ARCAD ธนาคารขนาดใหญ่แห่งหนึ่งในสหราชอาณาจักรได้นำ DevOps มาใช้กับ IBM i ได้สำเร็จ IBM i Merlin Platform (Modernization Engine for Lifecycle
Integration) ช่วยในเรื่องนี้ด้วย IDE, CI/CD Merlin tools สำหรับประสบการณ์ DevOps พร้อมกับ IBM i virtual machine allocation, REST APIs Management เป็นต้น และนำความหวังสำหรับระบบนิเวศ DevOps ที่สมบูรณ์ในอนาคต การพัฒนาล่าสุดช่วยในเรื่องความคล่องตัว
ของสภาพแวดล้อม IBM i และโฮสต์แอปพลิเคชันอีกครั้ง การดูแลระบบของแพลตฟอร์มนี้จะถูกถ่ายโอนโดยการย้ายโครงสร้างพื้นฐานโดยตรงไปยัง IBM Cloud หรือไปยัง Skytap บน Azure และ IBM Cloud หรือไปยัง Connectria บน AWS Infinite i กำลังช่วยชีวิตเพื่อโฮสต์ใหม่
แอปพลิเคชันบน Azure หรือ AWS หรือ Google Cloud ตัวเลือกทั้งหมดเหล่านี้ต้องจัดประเภทเป็นการปรับให้ทันสมัยแบบแทนที่หรือการปรับให้ทันสมัยแบบเทียม และขึ้นอยู่กับชุดทักษะ IBM i
ชุดเครื่องมือจาก Fresche, Google (G4) ให้การแปลงแบบหนึ่งต่อหนึ่ง (refactor) ของซอร์สโค้ด IBM i แบบเนทีฟ และเปิดประตูสำหรับการปรับใช้แอปพลิเคชันบนระบบเปิดและระบบคลาวด์ แต่ความชอบสำหรับตัวเลือกนี้กำลังจางหายไปเมื่อพิจารณาถึงความสามารถในการบำรุงรักษา
และมุมมองแห่งอนาคตสำหรับองค์กรขนาดใหญ่ เช่น ธนาคาร ธนาคารและโดยเฉพาะอย่างยิ่ง ผู้ประกันตนมีความต้องการทางธุรกิจที่ไม่หยุดนิ่ง เช่น ความต้องการด้านกฎระเบียบและการปฏิบัติตามกฎระเบียบที่เพิ่มมากขึ้น และด้วยเหตุนี้ความต้องการฐานรหัสที่บำรุงรักษาได้สูง
ออกจากการปรับปรุงให้ทันสมัยแบบแทนที่ (ทางเลือกสุดท้าย) และการปรับโครงสร้างใหม่ ตัวเลือกอื่นๆ สามารถจัดกลุ่มส่วนใหญ่เป็นหนึ่งในสองตัวเลือก ได้แก่ การเปลี่ยน COTS หรือการเขียนแอปพลิเคชันใหม่ทั้งหมด ตัวเลือกเหล่านี้มีข้อดีและข้อเสียในตัวเอง สำหรับส่วนใหญ่ของ
ธนาคารขนาดกลางและขนาดใหญ่และธนาคารที่มีการดำเนินงานในหลายประเทศหรือหลายพื้นที่ แอปพลิเคชันหลักคือขุมทรัพย์ ความแข็งแกร่ง และปัจจัยสนับสนุนสำหรับสิ่งที่พวกเขาเป็น ดังนั้น อัตราการยอมรับ COTS จะถูกจำกัดเนื่องจากความเหมาะสมของแอปพลิเคชัน COTS ที่แน่นอน
สำหรับความสามารถที่หลากหลายของธนาคาร เช่น การประมวลผลบัตร ความภักดี และการจัดการรางวัล
ตอนนี้ธนาคารเหลือตัวเลือกอื่นซึ่งเขียนใหม่ อย่างที่ทุกคนทราบ การเขียนแอปพลิเคชันที่มีอยู่ใหม่ (ใช้งานได้เทียบเท่าแต่เป็นสถาปัตยกรรมปัจจุบัน) ลงในแนวนอนเป้าหมายนั้นแทบจะเหมือนกับการสร้างแอปพลิเคชันใหม่ วิศวกรรมย้อนกลับ
เครื่องมือจาก Fresche และ ARCAD ช่วยเพิ่มความเร็วในการแยกกฎ วิธีการพัฒนาแบบใหม่ที่ขับเคลื่อนด้วย Agile, DevOps, Test Automation เป็นต้น การเขียนใหม่อาจใช้เวลาไม่นานนัก แต่จะไม่สั้นเช่นกัน ธนาคารขนาดใหญ่บางแห่งพยายามเขียนใหม่
และทำการทดลอง ธนาคารหลายแห่งแสดงความสนใจในการเขียนใหม่ แต่มองหาการย้ายข้อมูลที่คุ้มค่า แข็งแกร่ง และปราศจากความเสี่ยงหรือลดความเสี่ยง ซึ่งยังห่างไกล
นอกเหนือจากไทม์ไลน์ที่คาดไว้สำหรับการเขียนใหม่แล้ว ปัจจัยต่างๆ เช่น การตัดสินใจเชิงกลยุทธ์เกี่ยวกับภูมิทัศน์เป้าหมาย เทคโนโลยีเป้าหมาย สถาปัตยกรรมเป้าหมาย ความท้าทายด้านกฎระเบียบและการปฏิบัติตามกฎระเบียบ การเปลี่ยนแปลงขององค์กรเพื่อนำกิจกรรมการเปลี่ยนแปลงมาใช้
การลงทุนในปัจจุบันกับโครงสร้างพื้นฐานจำนวนมาก ฯลฯ จะส่งผลกระทบต่อไทม์ไลน์การย้าย IBM i โดยรวมสำหรับธนาคารส่วนใหญ่
นอกจากนี้ IBM ยังลงทุนและอัปเกรดเซิร์ฟเวอร์ Power อย่างต่อเนื่อง (เซิร์ฟเวอร์ที่ใช้ Power10 ซึ่งเปิดตัวในปี 2021) และ IBM i (7.5 ที่เปิดตัวในเดือนพฤษภาคม 2022) เป็นประจำพร้อมกับการสนับสนุนเทคโนโลยีแบบเปิด เพื่อรักษาโมเมนตัมในการรักษาแพลตฟอร์มนี้ไว้
หน้าต่างการสนับสนุน (โดยทั่วไปคือ 7+3 ปี – ปกติ + ขยาย) และการนำ Power servers มาใช้ซ้ำสำหรับสภาพแวดล้อมอื่นๆ (AIX) เป็นปัจจัยสำคัญบางประการที่ทำให้มีพื้นที่เพิ่มเติมสำหรับการตัดสินใจ (ไม่ต้องเร่งรีบในการออกจากแพลตฟอร์ม)
สรุป
ด้วยปัจจัยทั้งหมดเหล่านี้ ความจำเป็นในการรันแอ็พพลิเคชัน IBM i จะยังคงสูงต่อไปอีกหลายปี หมายความว่า แอปพลิเคชันเหล่านี้ควรได้รับการสนับสนุน บำรุงรักษา และปรับปรุงจนกว่าองค์กรจะพบทางเลือกอื่นที่มีประสิทธิภาพ แต่ที่
ในขณะเดียวกัน การมีส่วนร่วมกับพนักงานในชุดทักษะ IBM i ก็ยากขึ้นเรื่อยๆ ถึงเวลายกระดับทีมพัฒนาโดยใช้ประโยชน์จาก IDE และเครื่องมือที่ปรับปรุงแล้วสำหรับแพลตฟอร์มนี้
