הדילמה: תגובה עסקית מהירה לעומת חוב טכני

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

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

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

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

"כיבוי שריפות"

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

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

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