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