Architecture Decision Record

Active theme: Light

← תבניות רשומות החלטה

תבנית רשומת החלטה של ג׳ף טיירי וארט אקרמן

זוהי תבנית תיאור ההחלטה הארכיטקטונית שפורסמה ב-"Architecture Decisions: Demystifying Architecture" by Jeff Tyree and Art Akerman, Capital One Financial.

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

  • החלטה (Decision): נסחו בבירור את כיוון הארכיטקטורה, כלומר את העמדה שבחרתם.

  • מצב (Status): מצב ההחלטה, כמו ממתינה, הוחלט או אושרה.

  • קבוצה (Group): אפשר להשתמש בקיבוץ פשוט, כמו אינטגרציה, הצגה, נתונים וכן הלאה, כדי לארגן את קבוצת ההחלטות. אפשר גם להשתמש באונטולוגיית ארכיטקטורה מתוחכמת יותר, כמו זו של John Kyaruzi ושל Jan van Katwijk, שכוללת קטגוריות מופשטות יותר כמו אירוע, לוח שנה ומיקום. לדוגמה, באמצעות האונטולוגיה הזו תקבצו תחת אירוע החלטות שעוסקות בהתרחשויות שבהן המערכת דורשת מידע.

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

  • אילוצים (Constraints): תעדו כל אילוץ נוסף על הסביבה שהחלופה שנבחרה (ההחלטה) עשויה להטיל.

  • עמדות (Positions): פרטו את העמדות (אפשרויות או חלופות ברות קיימא) ששקלתם. אלה דורשות לעיתים קרובות הסברים ארוכים, לפעמים אפילו מודלים ותרשימים. זו אינה רשימה ממצה. עם זאת, אתם לא רוצים לשמוע את השאלה "חשבתם על...?" בסקירה הסופית; זה מוביל לאובדן אמינות ולהטלת ספק בהחלטות ארכיטקטוניות אחרות. הסעיף הזה גם עוזר להבטיח ששמעתם את דעותיהם של אחרים; ציון מפורש של דעות אחרות עוזר לגייס את תומכיהן להחלטה שלכם.

  • טיעון (Argument): תארו למה בחרתם בעמדה, כולל פריטים כמו עלות מימוש, עלות בעלות כוללת, זמן יציאה לשוק וזמינות משאבי הפיתוח הנדרשים. זה כנראה חשוב כמו ההחלטה עצמה.

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

  • החלטות קשורות (Related decisions): ברור שהחלטות רבות קשורות זו לזו; אפשר לפרט אותן כאן. עם זאת, מצאנו שבפועל מטריצת עקיבות, עצי החלטה או מטא-מודלים שימושיים יותר. מטא-מודלים שימושיים להצגת קשרים מורכבים בתרשימים (כמו מודלים של Rose).

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

  • תוצרים קשורים (Related artifacts): פרטו את מסמכי הארכיטקטורה, העיצוב או ההיקף הקשורים שההחלטה הזו משפיעה עליהם.

  • עקרונות קשורים (Related principles): אם לארגון יש קבוצת עקרונות מוסכמת, ודאו שההחלטה עקבית עם אחד מהם או יותר. זה עוזר להבטיח התאמה בין תחומים או מערכות.

  • הערות (Notes): מכיוון שתהליך קבלת ההחלטות יכול להימשך שבועות, מצאנו שמועיל לתעד הערות וסוגיות שהצוות דן בהן במהלך תהליך ההחברות.