הרהורים ומחשבות על חידוש יישומי Legacy

המערכות הוותיקות הללו הן מורכבות ומגיעות עם תהליכים מורכבים, כתוצאה מעשרות שנים של התפתחות בסביבות הטכנולוגיות המשתנות במהירות ● הפעם במדור: כמה עצות איך עושים זאת נכון, על הצד הטוב ביותר

21/03/2018 17:01
אריה עמית, יועץ אסטרטגי וניהולי בכיר ב-I-amIT

מערכות Legacy הן מערכות מורכבות עם תהליכים מורכבים, שהם תוצאה של עשרות שנים של התפתחות בתעשיית המחשוב, בסביבות טכנולוגיות המשתנות במהירות. הן משקפות 200 מיליארד שורות קוד ב-30 אלף מחשבי מיינפריים. הצפי הוא ש-40-60 מיליארד שורות קוד יידרשו לעבור השבחה בחמש השנים הבאות, מה שמספק הזדמנות עסקית של יותר מ-120 מיליארד דולר.

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

מרכיבי הסיכון של מערכות ה-Legacy

המרוץ אחר הפתרון הטוב, המהיר והזול יותר חשף את הארגונים המבוססים על מערכות Legacy למספר סכנות:

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

המסע ל-"חידוש" המערכות

הגדרת הדרך
כוללת הערכה של פורטפוליו ה-IT וקביעת הערך האסטרטגי ליישומים, עם המלצה על האופציה ליישומים, תכנון "מפת הדרכים" הממליצה על האסטרטגיות לחידוש עבור כל יישום מתוך פורטפוליו היישומים המתוכננים להתבצע בחידוש והגדרת הצורך העסקי לשינוי.

הגדרת הדרך נשענת על מומחי "עבר" בתשתיות וביישומי ה-Legacy המובילים, ומנוסים ביותר בניהול פרויקטים מורכבים בסביבה מרובת יצרנים וספקים.

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

עוד היא נשענת על מומחי "עתיד" בשימוש בארכיטקטורות עתידיות ומודרניות (דוגמת SOA), וכן שימוש בתהליכים עסקיים ובמודלים מיטביים במגזרי התעשייה השונים.

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

גידור הסיכונים
כולל את הכנת תכנית המעבר, גידור הסיכונים התפעוליים, אופטימיזציה של המשאבים, אירוח היישומים המחודשים, ניהול הסביבה המודרנית והמעבר לתפעול.

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

להלן כמה עצות ליוצאים למסע לעבר הארגון הגמיש:

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

אסטרטגיות Re אלטרנטיביות לתהליך המודרניזציה

תהליך הרציונליזציה ליישומים מתבסס על שבע אסטרטגיות ישימות לבניית תיק נכסי היישומים החדש של הארגון:

  • Relearn – ניתוח מבנה התכניות והנתונים הקיימים ויצירת בסיס נתונים סטטיסטי, איתור החוקים העסקיים, זיהוי מועמדים לרכיבים לשימוש חוזר והכנת תקציר של היישומים הקיימים.
  • Retire – אילו יישומים ומערכות ייסגרו ויוצאו משימוש.
  • Re host – אילו יישומים יועברו לתפעול על פלטפורמות מחשוב חדשות או מערכות הפעלה חדשות.
  • Re architect – אילו יישומים יתוכננו בארכיטקטורות מודרניות מבוססות שירותים (SOA).
  • Re interfaced – אילו יישומים ישנו את הממשקים שלהם ויפתחו שירותים בעלי תכונות ופונקציונאליות חדשות, מבוססות ווב ומובייל.
  • Replaced – אילו יישומים יוחלפו בחבילות ארגוניות מוכנות או ביישומים שפותחו מחדש לפי הצרכים על ידי שימוש ברכיבים מסחריים.
  • Refactor – אופטימיזציה של הקוד, לשיפור יעילות ההרצה השוטפת של היישום.

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

  • נתונים סטטיסטיים על גודל, שורות קוד ותדירות של מאפיינים שונים.
  • דיאגרמות על המבנה הלוגי של היישומים.
  • בסיס נתונים אינטראקטיבי על היישומים, לצורך שאילתות נוספות.
  • מלאי של תכניות, קלט, פלט, שלבי תפעול ועוד.
  • מודלים יישומיים בסטנדרט UML או אחר.

חדש, המר והנדס מחדש (Modernize, transform and reengineer)

לסיום, המתודולוגיות הכוללות למודרניזציה מכילות אוסף של טקטיקות לתהליך מעבר של כל יישום:

  • פרמוט של הקוד לפורמט סטנדרטי.
  • הסבה פשוטה של מבנים מסודרים, כמו ממבנה נתונים היררכי לרלציוני.
  • בנייה מחדש של קוד המקור והסרת קוד בלתי פעיל או פקודות GOTO.
  • החלפה של מבנה מסכים מ-Character mode ל-Block mode.
  • תרגום משפת תכנות אחת לשנייה ללא שינוי פונקציונאליות (מקובול לדוט.נט או ג'אווה).

תגובות

(1)

כתיבת תגובה

האימייל לא יוצג באתר.

אין לשלוח תגובות הכוללות דברי הסתה, דיבה, וסגנון החורג מהטעם הטוב

  1. Edith Ohri

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

אירועים קרובים