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