למה BiModal ב-IT לא יעבוד?

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

במשך הקריירה שלי עבדתי הן בחברות גדולות והן בקטנות. בתחילתה עבדתי על מיינפריים, לאחר מכן המשכתי במחשוב מבוזר ובענן, וכיום אני עובד גם בתחום המובייל. מעולם לא באמת פיתחתי בשיטת מפל המים. ההיפך – התחלתי במה שהיה ידוע אז כפיתוח אטירטיבי (Iterative development) וכיום מוכר כפיתוח תוכנה זמיש ו-DevOps.

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

כששמעתי בפעם הראשונה על המושג בי-מודלי (BiModal) של גרטנר (Gartner) לא הייתי בטוח מה משמעותו. חשבתי שזוהי עוד דרך להגדיר ניהול סיכוני מערכת (System risk governance) עבור מערכות של רשומות לעומת כאלה מעורבות. זה נשמע לי אז הגיוני.

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

מולטי-מודליות ולא בי-מודליות

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

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

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

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

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

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

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

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