אסטרטגיה למודרניזציה של IBM i בנוף הטכנולוגי של BFSI (Noel Prince Moses V) PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

אסטרטגיה למודרניזציה של IBM i בנוף הטכנולוגי של BFSI (נואל פרינס מוזס החמישי)

תַקצִיר

ישנן המלצות חזקות ליישומי IBM i לעבור מודרניזציה או העברה לפלטפורמה עתידנית, ויש גם היסוס חזק שמניע את הסנטימנט נגד ההגירה. זה מוביל אותנו לשאלה; האם אנחנו צריכים להשקיע במערך הכישורים
של הפלטפורמה הקיימת או לא?

סקירה כללית

מכיוון ש-IBM i היא המערכת הישנה, ​​היא מיועדת להגירה על ידי ארגונים רבים מסיבות שונות. כאן בבלוג הזה, נחקור אפשרויות זמינות להגירה בתרחיש של היום, סבירות לאימוץ, הסיבה לאי מעקב מהיר
ההגירה או היציאה והצורך בהרמת כוח העבודה בפיתוח.

IBM i (הידועה בכינויו AS/400) הייתה אחת המערכות האסטרטגיות ביותר עבור רבים מארגונים בינוניים עד גדולים, כולל בנקאות, שירותים פיננסיים וביטוח (BFSI). הוא נמצא בשימוש על ידי כל הארגונים הללו במשך יותר מ-25 עד 30 שנה. זה מארח ליבה
יישומים עבור בנקים ומבטחים כולל Core Banking, ניהול כרטיסים, ניהול פוליסות וכו'. IBM i, כפי שנדון כאן, היא כל האקולוגית שמגיעה יחד עם IBM i, החומרה, מערכת ההפעלה, שפות התכנות כמו RPG,
COBOL ו-CL, מסד נתונים DB2 for i, IBM MQ להעברת הודעות, ניהול משימות, גישת משתמשים, אבטחה וכו'. מודרניזציה מדור קודם נמצאת בדיון בבנקים כבר שנים רבות, ו-IBM i נמצאת גם ברדאר להחלפה בטכנולוגיות חדשות בגלל אתגרים
קשור למערך מיומנויות ספציפיות לפלטפורמת IBM i (RPG, COBOL), ארכיטקטורת מונולית של יישומים המובילה לבעיות זריזות, יכולת פעולה הדדית עם פלטפורמות אחרות וכלי DevOps, לא מותאמת להשקעות אסטרטגיות, חסרות את רוב יתרונות הענן (למשל,
קיבולת לפי דרישה) וכו'. במקביל, ישנן מספר סיבות מדוע ההגירה נדחתה. חלקם הם מהדורות חומרה חדשות, מהדורות מערכת הפעלה, חלון תמיכה מורחב, ההשקעות הנוכחיות בתשתיות כבדות, סיכון הגירה ועלות.
כאן, אנו מנסים לאמוד את האפשרויות המוקדמות של היציאה שלה כך שתחזו את התלות בחברות קטנות ובינוניות שלה.

נקודת המבט שלנו

במהלך התקופה, העסק גדל, הדרישות העסקיות גדלו, סיכונים שונים גדלו, דרישות הציות והרגולציה גדלו ובסופו של דבר כל אלה נתפסו וטופלו בתוך יישום מונוליט אחד לכל אחד.
מִפְעָל. ומכאן רמת המורכבות הגבוהה שיש בריכוז כל הידע, הכללים העסקיים, התהליכים העסקיים. נוספו לזה את כל ההטמעות הטכניות כמו ריבוי השחלות, הודעות, תזמון עבודה, בקרת עבודה וכו',
הם גם חלק מיישום המונוליט.

עם הופעת ענן, שיטות DevOps ו-Agile, תעשיות וארגונים, כולל בנקאים ומבטחים, מחפשים טרנספורמציה של יישומי IBM i גם כדי לקצור את התכונות והיתרונות העדכניים ביותר. לארגונים יש מספר אפשרויות
מולם. פלטפורמה זו יכולה לעקוב אחר שיטות זריזות ולהיות חלק מעולם DevOps עם פתרונות ARCAD. אחד מהבנקים הגדולים בבריטניה אימץ את DevOps ב-IBM i בהצלחה. פלטפורמת IBM i Merlin שהושקה לאחרונה (Modernization Engine for Lifecycle
אינטגרציה) עוזרת לכך עם כלים משולבים של IDE, CI/CD Merlin לחוויית DevOps יחד עם אספקת מחשב וירטואלי של IBM i, ניהול ממשקי API של REST וכו', ומביאה תקווה למערכת אקולוגית מלאה של DevOps בעתיד. פיתוחים אחרונים עוזרים בזריזות
של סביבות IBM i ואירוח מחדש של היישומים שלה. ניהול המערכת של פלטפורמה זו יוסר על ידי העברת תשתית ישירות ל-IBM Cloud או ל-Skytap ב-Azure ו-IBM Cloud או ל-Connectria ב-AWS. Infinite i נמצא בחילוץ לארח מחדש
האפליקציות ב-Azure או AWS או Google Cloud. כל האפשרויות הללו יסווגו כמודרניזציה במקום או פסאודו-מודרניזציה ויהיו תלויות בערכת הכישורים של IBM i.

ערכות כלים מבית Fresche, Google (G4) מספקות המרה אחת לאחד (refactor) של קודי מקור מקוריים של IBM ופותחים את השער לפריסת האפליקציה במערכות פתוחות ובענן. אבל ההעדפה לאופציה זו דועכת בהתחשב ביכולת התחזוקה
וראייה עתידנית עבור ארגונים גדולים כמו בנקים. לבנקים וליתר דיוק למבטחים יש צרכים עסקיים דינמיים מאוד כמו דרישות רגולטוריות ותאימות מתגברות ומכאן הצורך בבסיס קוד בר תחזוקה גבוה.

בהשארת המודרניזציה במקום (המוצא האחרון) וה-refactor, את האפשרויות האחרות ניתן לקבץ במידה רבה לאחת משתי האפשרויות, כלומר, החלפת COTS או שכתוב היישום כולו. לאפשרויות אלה יש יתרונות וחסרונות משלהן. עבור רוב ה
בנקים בינוניים וגדולים ובנקים עם פעילות מרובת מדינות או ריבוי גיאוגרפיות, יישומי הליבה הם האוצר שלהם, החוזק שלהם והמאפשר למה שהם. אז, שיעור אימוץ COTS יהיה מוגבל בגלל ההתאמה המדויקת של יישום COTS
ליכולות העשירות של הבנק כמו עיבוד כרטיסים, נאמנות וניהול תגמולים.

כעת, לבנקים נותרה האפשרות האחרת שהיא שכתוב. כפי שכולם יודעים, שכתוב האפליקציה הקיימת (שקולה מבחינה פונקציונלית אך עדכנית מבחינה ארכיטקטונית) לנוף יעד זה כמעט כמו בניית אפליקציה חדשה. הנדסה הפוכה
כלים של Fresche ו-ARCAD עוזרים להאיץ את חילוץ הכללים. דרך הפיתוח החדשה המופעלת באמצעות Agile, DevOps, Test Automation וכו', ייתכן שהשכתוב לא ייקח יותר מדי זמן אבל גם הוא לא יהיה קצר. כמה מהבנקים הגדולים ניסו לשכתב
ומתנסים. בנקים רבים מגלים עניין בשכתוב אך מחפשים הגירה חסכונית, חזקה וללא סיכונים או סיכון מופחת, אשר עדיין רחוקה.

מלבד ציר הזמן הצפוי לשכתוב, הגורמים כמו החלטה אסטרטגית על נוף היעד, טכנולוגיות היעד, ארכיטקטורת היעד, אתגרי הרגולציה והציות, שינויים ארגוניים לאימוץ פעילויות הטרנספורמציה,
ההשקעה הנוכחית בתשתיות כבדות וכו' הולכות להשפיע על ציר הזמן הכולל של ההגירה של IBM i עבור רוב הבנקים.

יבמ גם משקיעה ומשדרגת ללא הרף את שרתי Power (שרתים מבוססי Power10 שהושקו ב-2021) ו-IBM i (7.5 שוחררו במאי 2022) על בסיס קבוע יחד עם תמיכה גם בטכנולוגיות פתוחות כדי לשמור על המומנטום בשמירה על פלטפורמה זו.
חלון התמיכה (באופן כללי 7+3 שנים - רגיל + מורחב) והשימוש החוזר של שרתי Power עבור סביבות אחרות (AIX) הם חלק מהגורמים החשובים שנותנים מקום נוסף לקבלת החלטות (אין למהר לצאת מהפלטפורמה).

סיכום

עם כל הגורמים הללו, הצורך בהפעלת יישומי IBM i ממשיך להישאר גבוה עוד שנים רבות. המשמעות היא שיש לתמוך, לתחזק ולשפר יישומים אלה עד שהארגונים ימצאו חלופה יעילה. אבל ב-
במקביל, זה נהיה יותר ויותר קשה להעסיק את כוח העבודה במערך הכישורים של IBM i. הגיע הזמן להעלות את כוח העבודה בפיתוח על ידי מינוף ה-IDEs והכלים המשופרים לפלטפורמה זו.

בול זמן:

עוד מ פינקסטרה