Legacy System Integration כשהמערכת הישנה לא הולכת לשום מקום אבל העולם כן
יש משפט שאנחנו שומעים הרבה בפגישות ראשונות עם לקוחות: "יש לנו מערכת שרצה כבר עשרים שנה, אי אפשר לגעת בה, אבל אנחנו צריכים שהיא תדבר עם האפליקציה החדשה."
זו לא בעיה חריגה. זו הנורמה.
מה זו בכלל מערכת Legacy?
המונח "Legacy System" מתאר לרוב מערכת תוכנה שנכתבה לפני עידן ה-API, לפני הענן, ולפעמים לפני שהאינטרנט הפך לתשתית עסקית. היא עובדת. היא יציבה. לפעמים היא עובדת טוב יותר ממה שיפותח היום. אבל היא לא מדברת עם שום דבר אחר.
בישראל, חברות תעשייה, לוגיסטיקה, ביטוח ופיננסים מפעילות מערכות כאלה - ERP ישן, תוכנת חשבונות שנכתבה ב-VB6, מערכת ניהול ייצור שרצה על אותו שרת מאז 2003 ועדיין לא יצאה לפנסיה. לא בגלל עצלות. בגלל שזה עובד ועלות ההחלפה, הן כספית והן ארגונית, מפחידה יותר מהמשך החיים עם הבעיה.
הבעיה היא לא המערכת הישנה. הבעיה היא הפער.
כשהארגון רוצה להוסיף אפליקציה לשטח, פורטל לקוחות, או דשבורד ניהולי, הוא מגלה שהמערכת הישנה לא יודעת לדבר. אין REST API. אין Webhook. לפעמים אין תיעוד בכלל. יש רק בסיס נתונים ישן, קבצי FTP, או ממשק שמייצא ל-Excel.
כאן נכנס מה שנקרא Legacy System Integration - בניית שכבת תיווך שמאפשרת לשתי הסביבות לתקשר, מבלי לשנות את המערכת הישנה ומבלי לוותר על הפונקציונליות החדשה.
איך זה עובד בפועל?
אין פתרון אחד. הארכיטקטורה תלויה במה שהמערכת הישנה מסוגלת לחשוף.
כשיש גישה לבסיס הנתונים ישירות, אפשר לבנות SQL Linked Service שמושך נתונים בזמן אמת או בהפרשים - ומנגיש אותם דרך API נקי למערכות החדשות. זה אחד הפתרונות הנפוצים מערכות ישנות שאין להן API מלא.
כשיש ממשק Web Services ישן, SOAP או XML, אפשר לעטוף אותו ב-RESTful bridge שמתרגם את הבקשות לפורמט מודרני. מבחינת האפליקציה החדשה, היא מדברת עם API רגיל. מה שקורה מאחורי הקלעים זה כבר בעיה של שכבת התיווך.
כשאין כלום, רק ייצוא ל-Excel או FTP, בונים מנגנון Polling שסורק שינויים, ממיר אותם לאירועים, ומזין אותם לצינור הנתונים. זה פחות אלגנטי, אבל עובד בצורה מפתיעה טוב כשהמימוש נכון.
מה ה-Middleware בעצם עושה?
Middleware (או בעברית, תווכה) הוא השכבה שיושבת בין שני עולמות שלא תוכננו לדבר זה עם זה. הוא לא מחליף אף אחד מהם. הוא מתרגם.
בפרויקטים שעשינו, ה-Middleware טיפל בדברים כמו: המרת פורמטים בין מערכת כספים ישנה לאפליקציה מובייל, סנכרון דו-כיווני בין ERP לאפליקציית שטח שעובדת גם אופליין, ואמות מידה עסקיות שהיו מקודדות בתוך הלוגיקה הישנה ואי אפשר היה לגעת בהן, אז עטפנו אותן ולא שיכפלנו.
האתגר הכי גדול הוא בדרך כלל לא הטכני. זה ה-Tribal Knowledge - הידע שקיים רק אצל מי שפיתח את המערכת הישנה לפני עשרים שנה, ולפעמים הוא כבר לא בחברה. חלק גדול מעבודת האפיון הוא לחפור את הלוגיקה הזאת ולתעד אותה לפני שכותבים שורת קוד.
מה לא לעשות?
הטעות הנפוצה ביותר היא לשכפל לוגיקה עסקית. כלומר, לכתוב מחדש בצד החדש את מה שהמערכת הישנה כבר עושה, במקום לצרוך את הפלט שלה. זה יוצר שני "מקורות אמת" (Source of truth) וברגע שהם מתבדרים, מתחילות הבעיות האמיתיות.
הטעות השנייה היא להתחיל לבנות בלי להבין מה קורה כשהמערכת הישנה לא זמינה. Downtime של ERP ישן הוא לא תרחיש נדיר. האפליקציה החדשה צריכה לדעת להתנהל בתנאים האלה - Deferred Sync, תורים, או לפחות הודעה ברורה למשתמש.
מתי כן כדאי להחליף את המערכת הישנה?
כשהפערים גדלים מהר יותר מהיכולת לגשר עליהם. אם כל בקשת פיצ'ר חדשה דורשת עוד workaround על גבי workaround - כנראה שהגעתם לגבול. אבל ההחלטה הזאת אסור שתהיה טכנית בלבד. היא ארגונית, תקציבית ועסקית ואנחנו לא ממליצים עליה אוטומטית.
Bit-Gem ו-Legacy Integration
חלק ניכר מהפרויקטים שלנו בשנים האחרונות הם בדיוק הסוג הזה. חברת שירות שטח עם Priority שלא עודכן מזה שנים ורוצה אפליקציה לטכנאים. מחסן שמנהל מלאי בקובץ Excel ורוצה בקרה בזמן אמת. מפעל שמערכת הייצור שלו לא יודעת לדבר עם שום דבר, אבל המנהלים רוצים דשבורד.
בכל המקרים האלה, הפתרון לא היה להחליף את מה שעובד - אלא לבנות גשר חכם שמכבד את שני הצדדים.
אם אתם מתמודדים עם פער כזה ורוצים להבין מה אפשר לעשות בלי לפרק הכל מחדש - שווה לדבר.
שאלות ותשובות
מה ההבדל בין Legacy Integration לבין החלפת המערכת הישנה?
החלפת מערכת ישנה היא פרויקט ארוך, יקר ורווי סיכון ארגוני - לעיתים נמשך שנים ומערב הדרכה מחדש של כל הצוות. אינטגרציה למערכת קיימת, שומרת על המערכת הקיימת פועלת ומוסיפה עליה שכבה שמאפשרת חיבור לאפליקציות מובייל, ממשקי API, ופורטלים חדשים. ברוב המקרים זו הגישה המהירה, הזולה והבטוחה יותר.
מהי גישת Offline-first ולמה היא חשובה באינטגרציה עם מערכות ישנות?
כשבונים אפליקציה שמתממשקת למערכת ישנה, חשוב להניח שהחיבור יתנתק. בין אם בגלל Downtime של ה-ERP, בגלל אזורי שטח ללא קליטה, או בגלל תחזוקה. Offline-first פירושו שהאפליקציה עובדת מקומית ושומרת פעולות בתור (Deferred Sync), ומסנכרנת כשהחיבור חוזר. בלי גישה זו, כל תקלה קטנה בצד המערכת הישנה מפילה את כל תהליך העבודה.
מתי כן כדאי להחליף מערכת ישנה במקום לעשות Integration?
כשהפערים גדלים מהר יותר מהיכולת לגשר עליהם. סימני אזהרה: כל בקשת פיצ'ר חדשה דורשת Workaround נוסף, המערכת הישנה כבר לא מקבלת תמיכה מהיצרן, או שהנתונים בה כל כך מבולגנים שה-Integration בעצמו הפך לנטל. ההחלטה הזאת צריכה להיות עסקית ולא טכנית וכדאי לקבל אותה עם מי שמבין את שני הצדדים.
מה עושים כשל-ERP הישן אין API?
זו הבעיה הנפוצה ביותר. כשאין API, ניתן לגשת ישירות לבסיס הנתונים דרך SQL Linked Service, לעטוף ממשק SOAP ישן ב-REST Bridge, או לבנות מנגנון Polling שסורק שינויים בקבצי FTP ו-Excel ומזין אותם לצינור הנתונים. כמובן, שהבחירה בין הגישות תלויה בארכיטקטורה של המערכת ובסביבת הפריסה.
כמה זמן לוקח פרויקט Legacy Integration?
זה תלוי במורכבות המערכת הישנה ובהיקף הנתונים שצריך לגשר עליהם. פרויקט בסיסי - חיבור ERP לאפליקציה אחת עם לוגיקה ברורה, יכול לקחת שבועות בודדים. פרויקטים הכוללים ריבוי מקורות נתונים, Deferred Sync ואינטגרציה דו-כיוונית יכולים להגיע גם למספר חודשים. האפיון הראשוני, שבו חושפים את הלוגיקה הטמונה במערכת הישנה, הוא לרוב החלק שלוקח הכי הרבה זמן ומפתיע הכי הרבה לקוחות.