תוכנית שירותי פיתוח בקוד נמוך: מדריך לקונים

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

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

שכבת הפלטפורמה היא כלי העבודה: בוני טפסים גרור ושחרר, מעצבי מודל נתונים, מנועי זרימת עבודה, מחברי API וצינורות פריסה. דוגמאות לשמות כוללות Microsoft Power Apps, OutSystems, Mendix, Appian, Retool, Budibase, ו- עבור צוותים שכבר השקיעו באקוסיסטם ה-4D - הכלים לבניית טפסים, מתודות ומודלי נתונים של 4D עצמה. שכבת השירותים היא העבודה האנושית: סדנאות גילוי, מודלים של נתונים, אינטגרציה, בדיקות ומסירה. שכבת התמיכה היא מה שקורה לאחר ההפעלה: ניטור, בקשות לשינוי, שדרוגי גרסאות והדרכת משתמשים.

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

ארבעת מודלי השירות, בהשוואה

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

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

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

קשורים: Claris FileMaker Pro — פלטפורמת מסד הנתונים הרלוונטיים ארוכת השנים לצוותים שזקוקים לאפליקציות מותאמות אישית במחשב שולחני, באינטרנט ובנייד מקובץ בודד..

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

ההבדלים בין שירותי Low-Code ו-No-Code בפועל

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

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

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

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

איך נראית התקשרות אמיתית, שלב אחר שלב

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

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

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

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

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

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

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

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

קריטריוני בחירה שבאמת מנבאים הצלחה

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

חביב הקוראים: Microsoft Power Apps — פיתוח אפליקציות בעלות קוד נמוך ברמה ארגונית מחוברת ל-Microsoft 365, Dataverse ו-Power Automate..

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

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

היכן שתוכניות עם קוד נמוך משתלמות באמת - והיכן שלא

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

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

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

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

בנייה מול קניה: כאשר תוכנית פנימית מנצחת תוכנית חיצונית

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

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

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

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

מקורות וקריאה נוספת

• פלטפורמת פיתוח בקוד נמוך — ויקיפדיה: פלטפורמת פיתוח בקוד נמוך (LCDP) מספקת סביבת פיתוח תוכנה - בדרך כלל ממשק משתמש גרפי (GUI) - הכוללת כתיבה מועטה או לא…

שאלות נפוצות

מהי תוכנית שירותי פיתוח בקוד נמוך?

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

כמה עולים שירותי פיתוח בקוד נמוך?

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

האם פיתוח בקוד נמוך מתאים ליישומים ארגוניים?

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

מה ההבדל בין שירותי פיתוח עם קוד נמוך ללא קוד?

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

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

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

מה צריך לכלול חוזה שירותי low-code?

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