בחירת פלטפורמת ה Low-Code הארגונית

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

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

איפה ענקיות הטק?:

כשמדובר ב Low-Code, רבים תוהים: איפה ענקיות הטק (מיקרוסופט, גוגל, אמזון, מטא ואחרות). הרי להן יש את היכולת להעמיד כלים מדהימים כאשר בפועל הם מעמידים כלים רפים כגון PowerApps או AppSheets שמכוונים לאפליקציות קטנות.

מה הסיבה לגרירת הרגליים הזו?:

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

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

אם יש או יהיה, על כלי הפיתוח שלהן איום אמיתי, הן יפעלו ובגדול.

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

אפילו הפיתוחים של ה AI נעשו בשקט וברקע עד ל Disruption של OpenAI. וכל המהלכים שנעשים כעת, נעשים באופן מחושב ביותר, אל מול כלי הפיתוח השונים.

איך זה משפיע על זירת ה Low-Code?:

משפיע מאד: ענקיות הטק לא ממש רוצות לעשות קניבליזציה לכלי הפיתוח או לפלטפורמות הפתרונות שלהן ולכן הן לא ממהרות לייצר כלי Low-Code משמעותיים משלהן. אבל בהינתן איום חיצוני משמעותי, כהרף עיין האיום יירכש או יזכה לתחרות ישירה (שלא תשאיר ממנו הרבה).

מזווית הראיה הזו - בחירת כלי Low-Code הופכת למאתגרת. מאחר ואם כלי מעניין לא מהווה איום על הספקיות הגדולות, מה זה אומר עליו? ואם הוא כן מהווה איום?  אז יספוג תחרות ישירה, או שהוא יירכש (ומודל החיוב ישתנה לרעה).

דוגמה? בבקשה: AppGyver. כלי Low-Code יצירתי ומתקדם, ליצירת GUI עם מודל תשלומים מפתה (חינמי לתמיד - בעייתי בפני עצמו) נרכש על ידי SAP, גרסת החינם צומצמה ונפכה ללא מעניינת והכלי - פנה להשלים את האקו-סיסטם של SAP. בדיוק אותו סיפור קרה ל AppSheets.

אז מה עושים?

Full-Stack vs. Front-End+BEaaS

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

Back-End as a Service

אחת מהתנועות הכי משמעותיות (שווה פוסט בפני עצמו) בעולם הפיתוח, הוא תחום ה Back-End כשירות. כתוצאה מהתנועה לענן, ריבוי השחקנים בעולם ה Data, התפתחות השימוש בסוגי בסיסי נתונים ייעודיים (כמו: בסיס נתונים בזיכרון, בסיס נתונים בטלפון, התמחות בניהול תורים, NoSQL, SQL ואחרים) ריבוי האינטגרציות, הקושי באבטחה, תנועת ה Back-End as a Service, תופסת תאוצה. כלים כמו:FireBase, Mongo, Backendless, Xano, Supabase ואחרים, החלו לשלב את ניהול הנתונים, ניהול ההרשאות, תהליך האותנטיקציה, הגיבויים, קוד צד שרת (Serverless functions), ניהול קבצים ועוד.

התפתחות ה BEaaS פתחה עולם אלטרנטיבות חדש לפיתוח הארגוני המהיר שכן ההתקדמות המשמעותית בצד ה Back-End, שוכן הענן, מזמין כלי GUI להתממשק ובכך להשלים פלטפורמת פיתוח שלמה. עולם ה Back-End נוגע נכון יותר בנתונים שוכני ענן וכולל את מערכי התמיכה הנדרשים, החל מגיבויים, ניהול גישה, ניהול אבטחה, טיפול בביצועים, ממשקים, ניטור ועוד. הגישה הזו משאירה ל Front-End להתמודד עם האתגרים שלו, תוך הפחתת התלות.

מבין שתי הגישות: Full-Stack או שילוב של BEaaS יחד עם אפליקציית Low-Code המתמחה בGUI, מה עדיף?

מסתבר שבעולם המורכב של הפיתוח, לנסות להילחם מול כל השינויים, התחרות, התחזוקה והאינטרסים של הספקיות הגדולות ולתחזק פתרון full-stack זה בגדר "תפסת מרובה - לא תפסת". הפיצול בין כלי ה GUI, לכלי ה Back-End נתפס כפחות מאיים על הספקיות (עובדה - לכולן יש ייצוג מכובד בתחום).

הפיצול מאפשר בחירת הכלי הטוב ביותר, בסגנון Best Of Breed (הטוב מסוגו) מבחינת ממשק המשתמש וגם מבחינת ה Back-End.

הפיצול, לא רק שאינו פוגע בפיתוח המהיר, להיפך.

הגמישות בלהחליף את אחד מהכלים, כל אחד בתורו, גדלה.

הניהול הארגוני נכון יותר ומאפשר ההתמחות ב look&feel, במקביל להתמחות בנכסים הדיגיטליים הארגוניים. מבנה כזה מאפשר למקבל (parallel) את העבודה לפרויקטים ארגוניים משמעותיים ורחבים, לנהל ביצועים, לנהל אבטחה, ותחזוקת מערכות מעולה.

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

אותו דבר גם לגבי ה Back-End: הוא עשיר יותר בפונקציונאליות, זול יותר (כי יש לו אלטרנטיבות) ויש הרבה פחות תלות ארגונית. הוא יכול לשרת יותר מאפליקציה אחת, ואם הוא משתדרג או מוחלף, ההשפעה על ממשק המשתמש - מנוהלת. אין משבר.

אם נוסיף לשיקולים את העובדה שה AI מתקדם משמעותית על הכלים האלה - כשהם בנפרד, ההמלצה שלנו מתחילה להיות ברורה: שילוב של BEaaS וכלי Low-Code ב GUI עדיף.

AI אי אפשר בלי מילה על

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

לעניות דעתי: לא הייתי עוצר את הנשימה עד שזה יקרה...

הסיבה לא נעוצה ביכולות ה AI שמתפוצץ עלינו בקצב מסחרר. אלא בתוצר.

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

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

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

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

האויב של הטוב הוא היותר טוב

גם אם מחר יש כלי לפיתוח מהיר, יותר טוב, מכיל יותר featur-ים, טבול בעולם שכולו AI, האם זה נכון להימנע מבחירת כלי נכון היום?

השימוש בכלי Low-Code לפיתוח מהיר מוריד את מחיר הטעות באופן משמעותי. על כן, אם נתחיל במימוש צרכים עם כלי פיתוח מהיר היום, ומחר בבוקר יש כלי אחר - אפשר להחליף !

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

מחיר הרישוי

מבדל משמעותי (בין כלי Low-Code) נוסף הוא שיטת הרישוי. האם התשלום הוא למשתמש קצה, או למפתח? האם התשלום כולל שכבת שימוש בסיסית, או שמשלמים מהביט הראשון?

כמובן שמודל התשלום פר מפתח הוא זול יותר משמעותית לארגון.

כמובן שאם מפצלים את השימוש ליותר מ Back-End אחד (לפי התמחות וצורך) השימוש ברישוי מוזל (לגבי המשמעויות על כ"א וניהול הידע - שווה בדיקה). זה לא ייקרה בכלים שהם full-stack.

כאשר כלי ה Low-Code הוא full-stack, לספק יש קושי בתמחור מאחר והוא צריך לנהל את המשתמשים, את הנתונים, התעבורה ו CPU. אבל אם כלי ה Low-Code, ל GUI, מופרד, לספק כלי ה GUI אין בעיה עם תמחור הוגן מאחר והוא מתוגמל באופן ישיר על המוצר שלו ואין לו צורך לתמחר שירותי צד ג'.

כלומר גם מבחינת הרישוי יש חיזוק משמעותי לשילוב BEaaS ו GUI.

ובאופן קצת כללי יותר: שירותי ענן הם יקרים. שינוי דרמתי לא הולך לקרות כאן. אז איך מורידים עלויות?

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

עלות התחזוקה

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

אולי הייתרון המשמעותי ביותר של כלי Low-Code הוא ה Time-To-Market לפתרון הבא, יחד עם חוב טכני זעיר (בהשוואה למערכות מסורתיות).

כלומר עלות התחזוקה יורדת אפילו יותר מקצב הפיתוח.

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

שיקולים לבחירת פלטפורמת Low-Code

להלן כמה שיקולים (מהיותר מהותיים) שכדאי לעבור דרכם בדרך להחלטה על פלטפורמת ה Low-Code הנכונה עבורכם:

התאמה לכ"א הקיים בארגון

קלות האינטגרציה לפלטפורמות קיימות בארגון

זמן הפיתוח של ה"פתרון הבא"

מידת התלות בספקים (vendor-lock-in)

מידת התמיכה האפשרית של הספק

קהילת המשתמשים

הערכת אורך חיי הפלטפורמה (בטרם תירכש/תיסגר)

מודל התמחיר והעלות בראיה כוללת

תאימות לפלטפורמות (IOS, אנדרואיד, WEB...)

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

כלי בדיקות מובנים

היכולת לייצא את הקוד/תוצר (למטרות גיבוי/שיפור/שרידות)

תמיכה בעננים שונים + חצר הלקוח

היכולת להשתמש במקורות מידע קיימים של הארגון

היכולת להתקין את הפתרון On-Premise

סיכום - הצעד הראשון או מחיר הטעות

קודם כל - נוריד את הלחץ...

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

המלצה שניה: לשלב Low-Code המתמקד ב Front-End עם פלטפורמת BEaaS (טרנד נהדר שמתפתח בקצב גבוה).

ולבסוף, צירפתי עוד מספר שיקולים שיסייעו לכוון נכון.

בהצלחה.