قالب رکورد تصمیم از Jeff Tyree و Art Akerman

این قالب توصیف تصمیم معماری است که در "Architecture Decisions: Demystifying Architecture" نوشتهٔ Jeff Tyree و Art Akerman، Capital One Financial منتشر شده است.

مسئله (Issue): مسئلهٔ طراحی معماری را که به آن می‌پردازید شرح دهید، به‌گونه‌ای که هیچ پرسشی دربارهٔ اینکه چرا اکنون به این مسئله می‌پردازید باقی نماند. با رویکرد حداقل‌گرا، فقط به مسائلی بپردازید و آن‌ها را مستند کنید که در نقاط مختلف چرخهٔ عمر نیاز به پرداختن دارند.
تصمیم (Decision): جهت معماری، یعنی موضعی را که انتخاب کرده‌اید، به‌روشنی بیان کنید.
وضعیت (Status): وضعیت تصمیم، مانند در انتظار، تصمیم‌گرفته‌شده یا تأییدشده.
گروه (Group): می‌توانید از یک گروه‌بندی ساده — مانند یکپارچه‌سازی، ارائه، داده و غیره — برای کمک به سازمان‌دهی مجموعهٔ تصمیم‌ها استفاده کنید. همچنین می‌توانید از یک هستی‌شناسی (ontology) معماری پیچیده‌تر، مانند هستی‌شناسی John Kyaruzi و Jan van Katwijk که دسته‌های انتزاعی‌تری مانند رویداد، تقویم و مکان دارد، استفاده کنید. برای مثال، با این هستی‌شناسی، تصمیم‌هایی را که با رخدادهایی سروکار دارند که سیستم در آن‌ها به اطلاعات نیاز دارد، ذیل رویداد گروه‌بندی می‌کنید.
فرضیات (Assumptions): فرضیات زیربنایی محیطی را که در آن تصمیم می‌گیرید — هزینه، زمان‌بندی، فناوری و غیره — به‌روشنی شرح دهید. توجه کنید که محدودیت‌های محیطی (مانند استانداردهای فناوری پذیرفته‌شده، معماری سازمانی، الگوهای رایج و غیره) ممکن است گزینه‌هایی را که بررسی می‌کنید محدود کنند.
قیود (Constraints): هر محدودیت اضافی بر محیط را که گزینهٔ انتخاب‌شده (تصمیم) ممکن است ایجاد کند ثبت کنید.
مواضع (Positions): مواضع (گزینه‌ها یا جایگزین‌های عملی) را که بررسی کرده‌اید فهرست کنید. این‌ها اغلب به توضیحات طولانی و گاهی حتی مدل‌ها و نمودارها نیاز دارند. این فهرست جامع نیست. با این حال، نمی‌خواهید در بازبینی نهایی این پرسش را بشنوید که «آیا به … فکر کرده بودید؟»؛ این امر به از دست رفتن اعتبار و زیر سؤال رفتن سایر تصمیم‌های معماری می‌انجامد. این بخش همچنین کمک می‌کند مطمئن شوید نظرات دیگران را شنیده‌اید؛ بیان صریح نظرات دیگر به جلب طرفداران آن‌ها به تصمیم شما کمک می‌کند.
استدلال (Argument): توضیح دهید چرا یک موضع را برگزیدید، از جمله مواردی مانند هزینهٔ پیاده‌سازی، هزینهٔ کل مالکیت، زمان ورود به بازار و در دسترس بودن منابع توسعهٔ لازم. این احتمالاً به اندازهٔ خود تصمیم مهم است.
پیامدها (Implications): هر تصمیم پیامدهای فراوانی دارد، همان‌طور که فرامدل REMAP نشان می‌دهد. برای مثال، تصمیم ممکن است نیاز به اتخاذ تصمیم‌های دیگر ایجاد کند، نیازمندی‌های جدید بسازد یا نیازمندی‌های موجود را تغییر دهد؛ محدودیت‌های اضافی بر محیط وارد کند؛ مذاکرهٔ مجدد دامنه یا زمان‌بندی با مشتریان را ایجاب کند؛ یا نیازمند آموزش اضافی کارکنان باشد. درک و بیان روشن پیامدهای تصمیم می‌تواند در جلب موافقت و ایجاد نقشهٔ راه برای اجرای معماری بسیار مؤثر باشد.
تصمیمات مرتبط (Related decisions): بدیهی است که بسیاری از تصمیم‌ها به هم مرتبط‌اند؛ می‌توانید آن‌ها را اینجا فهرست کنید. با این حال، ما در عمل دریافته‌ایم که ماتریس ردیابی، درخت‌های تصمیم یا فرامدل‌ها مفیدتر هستند. فرامدل‌ها برای نمایش روابط پیچیده به‌صورت نموداری (مانند مدل‌های Rose) مفیدند.
الزامات مرتبط (Related requirements): تصمیم‌ها باید کسب‌وکارمحور باشند. برای نشان دادن پاسخگویی، تصمیم‌های خود را به‌صراحت به اهداف یا نیازمندی‌ها نگاشت کنید. می‌توانید این نیازمندی‌های مرتبط را اینجا برشمارید، اما ما ارجاع به ماتریس ردیابی را مناسب‌تر یافته‌ایم. می‌توانید سهم هر تصمیم معماری را در برآورده کردن هر نیازمندی ارزیابی کنید، و سپس ارزیابی کنید که نیازمندی در مجموع همهٔ تصمیم‌ها چقدر خوب برآورده شده است. اگر تصمیمی در برآورده کردن نیازمندی سهمی ندارد، آن تصمیم را نگیرید.
مصنوعات مرتبط (Related artifacts): اسناد معماری، طراحی یا دامنه را که این تصمیم بر آن‌ها تأثیر می‌گذارد فهرست کنید.
اصول مرتبط (Related principles): اگر سازمان مجموعه‌ای از اصول توافق‌شده دارد، مطمئن شوید که تصمیم با یک یا چند مورد از آن‌ها سازگار است. این امر به همسویی در سراسر حوزه‌ها یا سیستم‌ها کمک می‌کند.
توضیحات (Notes): از آنجا که فرایند تصمیم‌گیری می‌تواند هفته‌ها طول بکشد، ثبت یادداشت‌ها و مسائلی را که تیم در جریان فرایند اجتماعی‌سازی دربارهٔ آن‌ها بحث می‌کند مفید یافته‌ایم.