פלטפורמות Low Code בארגוני Enterprise – דעה

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

אחת השאלות הנפוצות מסביבה נוצרים דיונים רבים היא "האם זה יתפוס"? ולצידה השאלה "האם זה יתפוס גם בארגוני Enterprise? " בחיפוש מהיר ברשתות ניתן למצוא מחקרים וסקרים שמנבאים ש"עד שנת עשרים-עשרים ומשהו יהיו מעל 60% או 70% פתרונות מבוססי פלטפורמת Low Code בארגוני Enterprise". והאמת? אני מאמינה שהם ממש צודקים! כי כשמסתכלים עמוק – מגלים שדווקא בארגוני ה-Enterprise, שימוש ב-Low Code הוא ממש לא משהו חדש.

אם נתארח ב"חצר הטכנולוגית" של כל ארגון Enterprise מדגמי, נמצא בו מגוון רחב של סביבות עבודה וטכנולוגיות. ככל שהארגון ותיק יותר, כך המגוון רחב יותר: נמצא שם את סביבות ה-MF או ה-AS400, עם שפות פיתוח כמו קובול או TAL, מערכות שפותחו ב-C++, ASP ומערכות חדשות שפותחו בJava או Net. עם שפות Client מודרניות. ולצד כל אלה – נמצאים גם מחוללי היישומים הוותיקים – כמו Uniface, Power Builder ,Oracle Forms, Domino, Magic וכמובן Access. מחוללי היישומים "של פעם" נולדו מתוך אותם צרכים בסיסיים – מחסור במתכנתים, כמות דרישות גדולה והצורך בעמידה בקצב מהיר של… חילול יישומים 😊

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

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

כדי לעבור ממערכת שיש בה סדרי גודל של אלפים ואפילו עשרות אלפי מסכים שמבוססת על Uniface או Magic לסביבת Low Code חדשה ומודרנית אנחנו מדברים על Full Scale Modernization, ולא פרויקט יישום רגיל. מה זה אומר? זה אומר שלפני שאנחנו בכלל מתחילים לדון בארכיטקטורת היעד, ובוחרים את פלטפורמת ה-Low Code החדשה שלנו, אנחנו צריכים להבין את המצב הקיים. מזכירה – מדובר פה במערכות ותיקות, שלפעמים אין להם תיעוד ובהרבה מקרים האפיונים שלהם לא מעודכנים. לא תמיד אנחנו מכירים לעומק את התהליכים שמומשו, ולא תמיד נדע לתמלל את תכולות המערכת הקיימת כדי לתחום את הדרישות עבור המערכת החדשה.

אז הבנו שניתוח המצב הקיים ותכנון מודרניזציה למערכת כזו זה משהו שצורך זמן, משאבים ו-Attention. נוסיף מעל זה את העובדה שמערכות הMid Office הללו בד"כ מאוד יציבות (אין כמו טכנולוגיה של פעם 😊 ) ובדרך כלל הן גם לא בעדיפות עליונה לטיפול כי לפניהן יהיו כל מערכת שמוגדרת כליבה עסקית וכל מה שהוא Customer Facing – וקיבלנו קצב איטי מאוד להחלפה של מחוללי היישומים הוותיקים בסביבת Low Code חדשה ומודרנית. כי הרבה מאוד מהארגונים עוד מנסים למפות את הבעיה, ובכלל לא הגיעו לדון בפתרון.

הסיבה הראשונה מסבירה רק חלק מהבעיה.

לצידה יש את הסיבה השנייה והמשמעותית לא פחות – ארגוני Enterprise אכן מכירים פלטפורמות יישום כבר הרבה שנים – לטוב ולרע. ובעוד הטוב ממשיך להתקיים בפלטפורמות החדשות, ויש להן גם טוב חדש ומשופר להציע, ה"רע" יצר צלקות עמוקות שהן אלה שבאמת מחזירות לשולחן הדיונים את השאלה "האם לאמץ Low Code". כי כבר אימצנו, וקיבלנו UI קשיח ולא גמיש שהמשתמשים שלנו, שפעם אהבו אותו, מתלוננים עליו כי הוא לא חדשני, יש לנו Vendor Locking עם רישוי קבוע, פלטפורמה שאנחנו צריכים כל הזמן לשדרג, וצוותי פיתוח ייעודיים מומחים בפלטפורמה שהיום כבר מאוד קשה למצוא או להכשיר, מה שהופך את הצוותים שלנו לבלתי ניתנים להרחבה במקרה הטוב, ומצטמצמים בקצב מהיר במקרה הרע.

ועכשיו מגיעות הפלטפורמות החדשות – ואנחנו רוצים לוודא שאנחנו לא נכנסים לאותן צרות. אז אנחנו בוחנים ב-7 עיניים את האפשרות לייצר Pixel Perfect UI, את מהירות ההכשרה של מיישמים על הפלטפורמה, את הגמישות לשילובים של קוד ורכיבים נוספים בלי "לשבור או לעקם את המוצר", את הגמישות של מודל הנתונים והיכולת לעבוד עם מסדי נתונים חיצוניים, ואת היכולת שלנו לצאת מתי שאנחנו רוצים בלחיצת כפתור ולעבור לפתרון אחר. הפלטפורמות החדשות, שלא צמחו בוואקום, אכן מספקות מענה ראוי לכל אחת מצרות העבר וערוכות להדגים זאת. מכאן, תהליכי הבחינה של הפלטפורמות כוללים מעבר מדויק על כל אחד מהפיצ'רים, כאשר לעיתים קרובות יהיה גם פיילוט אחרי ה-POC, כשאת ה-POC מבצעים במקביל על שתיים או שלוש פלטפורמות – כדי להיות בטוחים. ולצד זה שחשוב מאוד ללמוד מטעויות העבר ולוודא שלא נכנסים לאותן צרות שוב – זה לוקח זמן.

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

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