إستراتيجية تحديث IBM i في مشهد تكنولوجيا BFSI (Noel Prince Moses V)

ملخص

هناك توصيات قوية لتحديث تطبيقات IBM i أو ترحيلها إلى منصة مستقبلية وهناك تردد قوي أيضًا مما يحرك المشاعر المناهضة للترحيل. هذا يقودنا إلى السؤال. هل نحتاج إلى الاستثمار في مجموعة المهارات
من النظام الأساسي الحالي أم لا؟

نبذة

نظرًا لكون نظام IBM i هو النظام القديم ، فهو مستهدف للترحيل من قبل العديد من المؤسسات لأسباب مختلفة. هنا في هذه المدونة ، سوف نستكشف الخيارات المتاحة للترحيل في سيناريو اليوم ، واحتمالية اعتمادها ، وسبب عدم التتبع السريع
الهجرة أو الخروج وضرورة النهوض بالقوى العاملة التنموية.

يعد IBM i (المعروف على نطاق واسع باسم AS / 400) أحد أكثر الأنظمة الاستراتيجية للعديد من المؤسسات المتوسطة والكبيرة بما في ذلك الخدمات المصرفية والمالية والتأمين (BFSI). يتم استخدامه من قبل جميع هذه المؤسسات لأكثر من 25 إلى 30 عامًا. تستضيف النواة
تطبيقات البنوك وشركات التأمين بما في ذلك Core Banking ، وإدارة البطاقات ، وإدارة السياسات وما إلى ذلك ، فإن IBM i ، كما نناقش هنا ، هو النظام البيئي بأكمله الذي يأتي جنبًا إلى جنب مع IBM i ، والأجهزة ، ونظام التشغيل ، ولغات البرمجة مثل RPG ،
COBOL و CL ، قاعدة بيانات DB2 لـ i ، IBM MQ للرسائل ، إدارة الوظائف ، وصول المستخدم ، الأمان إلخ. التحديث القديم قيد المناقشة داخل البنوك لسنوات عديدة حتى الآن ، و IBM i أيضًا في الرادار للاستبدال بالتقنيات الجديدة بسبب التحديات
المتعلقة بمجموعة المهارات الخاصة بمنصة IBM i (RPG ، COBOL) ، بنية متجانسة للتطبيقات تؤدي إلى مشكلات خفة الحركة ، وقابلية التشغيل البيني مع الأنظمة الأساسية الأخرى وأدوات DevOps ، غير المتوافقة مع الاستثمارات الإستراتيجية ، وفقدان معظم مزايا السحابة (على سبيل المثال ،
السعة عند الطلب) إلخ. وفي الوقت نفسه ، هناك عدد من الأسباب وراء تأجيل الترحيل. بعضها ، إصدارات الأجهزة الجديدة ، وإصدارات نظام التشغيل ، ونافذة الدعم الممتدة ، والاستثمارات الحالية في البنية التحتية الثقيلة ، ومخاطر الترحيل والتكلفة.
هنا ، نحاول قياس الاحتمالات المبكرة لخروجها بحيث يتم التنبؤ بالاعتماد على الشركات الصغيرة والمتوسطة.

منظورنا

على مدار هذه الفترة ، نمت الأعمال ، ونمت متطلبات العمل ، ونمت مخاطر مختلفة ، ونمت المتطلبات التنظيمية والامتثال ، وفي النهاية تم التقاط كل هذه الأمور والعناية بها في تطبيق واحد مترابط لكل منها
مَشرُوع. ومن ثم فإن المستوى العالي من التعقيد مع تركيز كل المعرفة وقواعد العمل والعمليات التجارية. يضاف إلى ذلك جميع التطبيقات التقنية مثل خيوط المعالجة المتعددة ، والرسائل ، وجدولة المهام ، والتحكم في الوظائف ، وما إلى ذلك ،
هي أيضًا جزء من تنفيذ monolith.

مع ظهور ممارسات Cloud و DevOps و Agile ، تبحث الصناعات والمؤسسات بما في ذلك المصرفيين وشركات التأمين عن تحويل تطبيقات IBM i لجني أحدث الميزات والفوائد. الشركات لديها خيارات متعددة
أمامهم. يمكن أن تتبع هذه المنصة ممارسات رشيقة وأن تكون جزءًا من عالم DevOps مع حلول ARCAD. اعتمد أحد البنوك البريطانية الكبيرة DevOps على IBM i بنجاح. تم إطلاق IBM i Merlin Platform مؤخرًا (محرك التحديث لدورة الحياة
التكامل) هذا مع أدوات Merlin IDE و CI / CD المتكاملة لتجربة DevOps جنبًا إلى جنب مع توفير الأجهزة الافتراضية لـ IBM i وإدارة REST APIs وما إلى ذلك ، وتجلب الأمل في نظام DevOps البيئي الكامل في المستقبل. التطورات الأخيرة تساعد في الرشاقة
بيئات IBM i وإعادة استضافة تطبيقاتها. يجب إلغاء تحميل إدارة النظام لهذا النظام الأساسي عن طريق ترحيل البنية التحتية مباشرة إلى IBM Cloud أو Skytap على Azure و IBM Cloud أو إلى Connectria على AWS. إن Infinite أنا في حالة إنقاذ لإعادة الاستضافة
التطبيقات على Azure أو AWS أو Google Cloud. يجب تصنيف كل هذه الخيارات على أنها إما تحديث موضعي أو تحديث زائف وتعتمد على مجموعة مهارات IBM i.

توفر مجموعات الأدوات من Fresche ، Google (G4) تحويلًا واحدًا إلى واحد (مُعاد بناء) لرموز المصدر الأصلية لـ IBM i وتفتح البوابة لنشر التطبيق على الأنظمة المفتوحة والسحابة. لكن تفضيل هذا الخيار يتلاشى بالنظر إلى قابلية الصيانة
ونظرة مستقبلية للمؤسسات الكبيرة مثل البنوك. البنوك وشركات التأمين على وجه التحديد لديها احتياجات أعمال ديناميكية للغاية مثل المتطلبات التنظيمية والامتثال المتزايدة ، وبالتالي الحاجة إلى قاعدة رمز قابلة للصيانة بشكل كبير.

ترك التحديث في المكان (الملاذ الأخير) وإعادة البناء ، يمكن تجميع الخيارات الأخرى إلى حد كبير في أحد الخيارين ، وهما استبدال COTS أو إعادة كتابة التطبيق بأكمله. هذه الخيارات لها مزاياها وعيوبها. بالنسبة لمعظم
البنوك والبنوك متوسطة وكبيرة الحجم مع عمليات متعددة البلدان أو مناطق جغرافية متعددة ، والتطبيقات الأساسية هي كنزها ، وقوتها ، والعامل التمكيني لها. لذلك ، سيكون معدل اعتماد COTS محدودًا بسبب الإعداد الدقيق لتطبيق COTS
لقدرات البنك الغنية مثل معالجة البطاقات والولاء وإدارة المكافآت.

الآن ، يتم ترك البنوك مع الخيار الآخر وهو إعادة الكتابة. كما يعلم الجميع ، فإن إعادة كتابة التطبيق الحالي (المكافئ وظيفيًا ولكن معماريًا حاليًا) في مشهد مستهدف يشبه تقريبًا إنشاء تطبيق جديد. الهندسة العكسية
أدوات من Fresche و ARCAD تساعد في تسريع استخراج القواعد. الطريقة الجديدة للتطوير التي تدعمها Agile و DevOps و Test Automation وما إلى ذلك ، قد لا تستغرق إعادة الكتابة وقتًا طويلاً ولكنها لن تكون قصيرة أيضًا. حاولت بعض البنوك الكبيرة إعادة الكتابة
والتجريب. يبدي العديد من البنوك اهتمامًا بإعادة الكتابة ولكنهم يبحثون عن وسيلة فعالة من حيث التكلفة وقوية وخالية من المخاطر أو هجرات مخاطرة منخفضة والتي لا تزال بعيدة المنال.

بصرف النظر عن الجدول الزمني المتوقع لإعادة الكتابة ، فإن العوامل مثل القرار الاستراتيجي بشأن المشهد المستهدف ، والتقنيات المستهدفة ، والبنية المستهدفة ، والتحديات التنظيمية والامتثال ، والتغييرات التنظيمية لاعتماد الأنشطة التحويلية ، و
سيؤثر الاستثمار الحالي في البنى التحتية الثقيلة وما إلى ذلك على الجدول الزمني الكلي لترحيل IBM i لمعظم البنوك.

تستثمر IBM أيضًا وترقيتها باستمرار (الخوادم القائمة على Power10 التي تم إطلاقها في عام 2021) و IBM i (7.5 تم إصدارها في مايو 2022) على أساس منتظم جنبًا إلى جنب مع دعم التقنيات المفتوحة وكذلك للحفاظ على الزخم في الاحتفاظ بهذا النظام الأساسي.
تعد نافذة الدعم (بشكل عام 7 + 3 سنوات - عادي + ممتد) وإعادة استخدام خوادم الطاقة للبيئات الأخرى (AIX) من العوامل المهمة التي توفر مساحة إضافية لاتخاذ القرار (لا داعي للاندفاع للخروج من النظام الأساسي).

وفي الختام

مع كل هذه العوامل ، تظل الحاجة إلى تشغيل تطبيقات IBM i مرتفعة لعدة سنوات أخرى. وهذا يعني أن هذه التطبيقات يجب دعمها وصيانتها وتعزيزها حتى تجد الشركات بديلًا فعالًا وقابل للتطبيق. لكن في
في الوقت نفسه ، تزداد صعوبة إشراك القوى العاملة في مجموعة مهارات IBM i. حان الوقت لرفع مستوى القوى العاملة في مجال التطوير من خلال الاستفادة من IDEs والأدوات المحسّنة لهذا النظام الأساسي.