• شناسایی بازیگران کامپیوتر و جایگاه آنها در مدل‌ فناوری عناصر محاسبات و نقش آنها

• شناسایی و مستندسازی نقش‌ها، مسئولیت‌ها و سنجش موفقیت هر بازیگر، دستور کار مورد نیاز هر بازیگر و نتایج مطلوب دست یابی به وضعیت مناسب

• بررسی سازگاری با هدفِ کار اثربخش معماری بعدی و اصلاح تنها در صورت لزوم

۳-۸-۱۹- تحلیل شکاف[۳۳]
روش شناخته شده‌ی تحلیل شکاف، به طور گسترده‌ای در ADM برای تأیید اعتبار معماری در حال توسعه استفاده می‌شود. این معمولاً گام نهایی در هر مرحله است. فرض اساسی برجسته کردن کمبود بین معماری مبدأ و معماری مقصد می‌باشد؛ و این عبارتست از مواردی که عمداً حذف شده، به طور تصادفی از قلم افتاده و یا هنوز مشخص نشده است.

۳-۸-۲۰- نقطه‌نظرات معماری[۳۳]
معمار از نما‌ها و نقطه‌نظرات در چرخه‌ی ADM در مراحل A تا D برای توسعه معماری در هر حوزه (کسب‌و‌کار، داده، برنامه‌کاربردی و فناوری) استفاده می‌کند. یک «نما^[۴۶]» چیزی است که شما می‌بینید. یک «نقطه‌نظر^[۴۷]» جایی است که شما از آنجا می‌بینید. نقطه یا چشم‌انداز مناسب است که آنچه را شما می‌بینید، تعیین می‌کند. (نما همچنین می‌تواند به عنوان یک قالب^[۴۸] در نظر گرفته شود). نقطه‌نظرات، کلی و عام می‌باشند و می‌توانند در کتابخانه‌ها برای استفاده مجدد ذخیره شود. یک نما، همیشه مختص معماری است که برای آن ایجاد شده است. هر نما یک نقطه‌نظر مرتبطی دارد که آن را حداقل به طور ضمنی توصیف می‌کند.
۳-۸-۲۱- نما‌های معماری[۳۳]
نما‌های معماری، نمایش‌هایی از معماری کلی است که برای یک یا چند ذینفع در سیستم، معنادارمی‌باشد. معمار مجموعه‌ای از نما‌ها را در چرخه‌ی ADM در مرحله‌ی A تا D انتخاب کرده و توسعه می‌دهد که این امکان را فراهم می‌آورد که معماری به تمام ذینفعان مرتبط شده و توسط آنها درک شود و آنها را قادر به بررسی صحت و دقت سیستمی می‌کند که به نگرانی‌های آنها رسیدگی خواهد کرد.
۳-۸-۲۱-۱- توسعه‌ی نما‌ها در چرخه ADM[33]
انتخاب نما‌هایی خاص از معماری برای توسعه، یکی از تصمیمات کلیدی است که معمار باید انجام دهد. معمار در خصوص اطمینان از کامل بودن (تناسب برای مقصد) معماری، از نظر پرداختن به صورت مناسب به تمام نگرانی‌های مربوط به ذینفعان، یکپارچگی معماری از نظر اتصال تمام نما‌های مختلف به یکدیگر، حل و فصل ناسازگاری نگرانی‌های ذینفعان مختلف به صورت رضایت آمیز و ارائه‌ مصالحه‌هایی برای انجام این کار (به عنوان مثال بین امنیّت و کارآیی)، مسئولیت دارد.
۳-۸-۲۲- بخش‌های سازنده‌ی معماری[۳۳]
بخش‌های سازنده‌ی معماری یا ABBها، مستندات معماری و مدل‌هایی از مخزن معماری سازمان هستند که مطابق با زنجیره‌ی معماری، طبقه‌بندی شده‌اند. آنها در طول اجرای ADM (عمدتاً در مرحله‌ی A،B، C و D) تعریف یا انتخاب می‌شوند. ویژگی‌های ABBها به شرح زیر است :

• آنها نیازمندی‌های معماری را در بر می‌گیرند. به عنوان مثال نیازمندی‌های کسب‌و‌کار، داده، برنامه‌کاربردی و فناوری

• آنها بخش‌های سازنده‌ی راه ‌حل ‌ها یا SBBها را جهت دهی و هدایت می‌کنند.

مشخصات بخش سازنده، حداقل شامل موارد زیر است:

• کارکرد‌ها و ویژگی‌های اساسی: معانی و مفاهیم، عدم ابهام، قابلیت امنیّت و قابلیت مدیریت

• واسط‌ها: مجموعه انتخاب شده، تأمین شده ( API‌ها^[۴۹]، فرمت‌های داده، پروتکل‌ها، واسط‌های سخت افزاری، استانداردها )

• قابلیت همکاری و ارتباط با دیگر بخش‌های سازنده

• بخش‌های سازنده وابسته به کارکردهای مورد نیاز و واسط‌های کاربری نامگذاری شده

• نگاشت شده به موجودیت‌ها و سیاست‌های سازمانی/ کسب‌و‌کار

هر بخش سازنده باید دربرگیرنده‌ی یک بیانی از مستندات معماری و مدل‌هایی از مخزن معماری سازمان باشد که می‌تواند در توسعه معماری مجدداً مورد استفاده قرار گیرد. توصیف بخش‌های سازنده‌ی مورد استفاده در ADM، فرآیندی تکاملی و تکرار شونده است.
۳-۸-۲۳- بخش‌های سازنده‌ی راه‌حل [۳۳]
بخش‌های سازنده‌ی راه‌حل یا SBBها، مربوط به زنجیره راه‌حل می‌باشند. آنها پیاده‌سازی‌هایی از معماری‌هایی هستند که در زنجیره معماری سازمان شناسایی شده‌اند و ممکن است تهیه شوند و یا توسعه یابند. SBB‌ها در مرحله‌ی E از چرخه‌ی ADM، جایی که برای اولین بار بخش‌های سازنده‌ی خاص محصول در نظر گرفته می‌شوند، ظاهر می‌شوند. SBB‌ها محصولات و اجزائی که عملکرد^[۵۰] را پیاده‌سازی خواهد کرد، تعریف می‌کنند، لذا پیاده‌سازی را تعریف می‌کنند. آنها نیازمندی‌های کسب‌و‌کار را برآورده کرده و محصول یا «آگاه از فروشنده» هستند. تشریح یک SBB، حداقل شامل موارد زیر است:

• قابلیت‌ها و ویژگی‌های خاص

• واسط‌ها؛ مجموعه پیاده‌سازی شده

• SBB‌های مورد نیاز که برای عملکرد مورد نیاز استفاده شده و نام‌ رابط‌های بکار رفته

• نگاشت SBB‌ها به توپولوژی IT و سیاست‌های عملیاتی

• مشخصات ویژگی‌های مشترک، مانند امنیت، قابلیت اداره، تمرکز پذیری، مقیاس پذیری

• کارآیی، قابلیت شکل پذیری

• پیشران‌های طراحی‌ها و محدودیت‌ها، شامل معماری فیزیکی

• روابط بین SBB‌ها و ABB‌ها

۳-۸-۲۴- برنامه‌ریزی مبتنی بر توانمندی‌ها[۳۳]
مراحل E و F روش دقیقی برای تعریف و برنامه‌ریزی تحول سازمان، براساس اصول برنامه‌ریزیِ مبتنی بر توانایی نمایان می‌سازند؛ تکنیکی که بر خروجی‌های کسب‌و‌کار تمرکز دارد. این تکنیکی مشتق شده از کسب‌و‌کار و همچنین رهبری کننده کسب‌و‌کار می‌باشد و تلاش‌های موردنیاز از سوی تمام خطوط کسب‌و‌کار را برای دستیابی به قابلیت‌های مطلوب، ترکیب می‌کند. این تکنیک اغلب، در مدل‌های کسب‌و‌کار سازمان‌های بزرگ جای می‌گیرد و به ویژه در سازمان‌هایی که یک توانایی نهفته برای پاسخ (به عنوان مثال یک واحد آمادگی اضطراری) مورد نیاز است و منابع یکسانی در قابلیت‌های متعدد درگیر هستند، مفید است. اغلب نیاز به این توانایی‌ها با بهره گرفتن از سناریوهای کسب‌و‌کار کشف و پالایش می‌شود.
شکل ۳-۵ ارتباط بین برنامه‌ریزی مبتنی بر توانایی، معماری سازمانی و مدیریت پرتفولیو/پروژه را نشان می‌دهد.
شکل ۳-۴: ارتباط بین توانمندی‌ها، معماری سازمانی و پروژه‌ها[۳۳]
۳-۸-۲۵- تکنیک‌های برنامه‌ریزی گذار
ابزارهای زیر برای پشتیبانی از برنامه‌ریزی انتقال در مراحل E و F ارائه شده است:

• ماتریس استنتاج و ارزیابی عوامل پیاده‌سازی

• ماتریس تلفیقی شکاف‌ها، راه ‌حل ‌ها و وابستگی‌ها

• جدول وضعیت تکامل معماری سازمانی

• جدول تعریف بازه‌های معماری