۳-۸-۳۲- ارزیابی تأثیر نیازمندی‌ها[۳۳]
در طول چرخه‌ی ADM، اطلاعات جدیدی مربوط به معماری جمع آوری می‌شود. هنگامی که این که اطلاعات جمع آوری می‌شوند، ممکن است حقایق جدیدی روشن شوند که جنبه‌های موجود معماری را از درجه اعتبار ساقط کنند. ارزیابی تأثیر نیازمندی‌ها، نیازمندی‌ها و مشخصات معماری فعلی را به منظور شناسایی تغییراتی که باید اعمال شوند، مورد ارزیابی قرار می‌دهد. این یک ارزیابی از تغییرات و پیشنهاداتی برای تغییر معماری را مستند می‌کند. محتوای پیشنهادی به شرح زیر است:

• • ارجاع به نیازمندی‌های خاص

• • اولویت نیازمندی‌های ذینفعان نسبت به زمان

• • مراحلی که باید بازبینی شوند.

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

• • نتایج تحقیقات در هر مرحله و اولویت‌های بازنگری شده

• • توصیه‌هایی در زمینه مدیریت نیازمندی‌ها

• • شماره ارجاع به مخزن

اینها اغلب به عنوان یک پاسخ به درخواست تغییر تولید می‌شوند.
۳-۹- رهنمودهایی برای تطبیق دادن ADM برای سازمان[۳۳]
ADM، یک روش کلی برای توسعه معماری است، که برای رسیدگی به اغلب نیازمندی‌های سیستمی و سازمانی طراحی شده است. به منظور تطابق با نیازهای خاص، اغلب نیاز به بهبود یا گسترش ADM است. یکی از کارها قبل از استفاده از ADM، این است که فرایند و خروجی‌های آن از نظر قابلیت اجرا، بررسی شود و سپس آنها برای شرایط سازمان‌های خاصی متناسب شود. این فعالیت به خوبی می‌تواند یک ADM خاص سازمان تولید کند.
۳-۹-۱- انجام تکرار برای ADM
ADM از چندین مفهوم از تکرار پشتیبانی می‌کند. انتظار می‌رود که:

• • با شروع فعالیت چشم‌انداز جدید، به عنوان نتیجه‌ای از مدیریت تغییر معماری، تیم‌های پروژه کل چرخه ADM را تکرار خواهند کرد.

• • تیم‌های پروژه ممکن است در قالب چرخه‌هایی برنامه‌ریزی شده که مراحل گوناگون را پوشش می‌دهند، بین مراحل ADM بچرخند. (به عنوان مثال، کسب‌و‌کار معماری، معماری سیستم‌های اطلاعاتی و معماری فناوری).

• • تیم‌های پروژه، ممکن است به منظور بازگشت به عقب و به روز رسانی محصولات کار با اطلاعات جدید، به مراحل قبلی برگردند.

• • بسیاری از تیم‌های پروژه، چرخه‌های ADM خود را ممکن است به صورت همزمان با روابطی بین تیم‌های مختلف، عملیاتی کنند. به عنوان مثال، یک تیم معماری ممکن است یک درخواست برای کار را برای یک تیم معماری دیگر، راه‌اندازی کند.

همه این تکنیک‌ها برنامه‌های کاربردی معتبر از ADM هستند و می‌توانند اطمینان دهند که رویکرد مورد استفاده در توسعه معماری، به‌اندازه کافی انعطاف پذیراست که با روش‌ها و چارچوب‌های دیگر تطبیق یابد.
۳-۹-۲- اجرای ADM در سطوح مختلف سازمان
ADM، به عنوان مدلی در نظر گرفته شده است تا از تعریف و پیاده‌سازی معماری در سطوح گوناگون در یک سازمان پشتیبانی کند و مورد استفاده قرار ‌گیرد. نظر به اینکه امکان رسیدگی به کلیه‌ی نیازهای همه‌ی ذینفعان با توسعه‌ی یک معماری واحد وجود ندارد، سازمان باید به نواحی مختلفی تقسیم شود که هر ناحیه می‌تواند با معماری‌هایی پشتیبانی شود. معمولاً معماری سازمانی برحسب موضوع اصلی، دوره زمانی و سطح جزئیات، تقسیم‌بندی می‌شود، همان طور که در شکل۳-۱۰ نشان داده شده است.
شکل ۳-۵: مدل طبقه‌بندی مختصر برای چشم‌اندازهای معماری
نسخه‌ی ۹ از توگف، انواع تعهداتی که ممکن است معماران ملزم به انجام آنها باشند را توصیف می‌کند و اینکه چگونه ADM برای هماهنگ کردن فعالیت‌های تیم‌های مختلفی از معماران مشغول به کار در سطوح مختلف، می‌تواند مورد استفاده قرار گیرد. آن همچنین دو راهبرد برای استفاده از ADM به عنوان یک فرایند برای پشتیبانی از سلسله مراتب‌ معماری‌ها فراهم می‌کند:

1. 1. معماری‌ها در سطوح مختلف می‌توانند از طریق تکرارهایی در فرایند ADM تکی، توسعه یابند. با بهره گرفتن از این روش، همانطور که در شکل ۳-۱۱ نشان داده شده، مرحله‌ی چشم‌انداز معماری می‌تواند برای توسعه‌ی یک دیدگاه راهبردی معماری مورد استفاده قرار گیرد. سپس، مرحله‌ی B، C و D یک دیدگاه معماری مفصل‌تر و رسمی‌تر از چشم‌انداز، برای بخش‌ها یا دوره‌های زمانی مختلف ارائه می‌کنند. سپس فازهای E و F یک طرح انتقال تفصیلی، را توسعه می‌دهند که ممکن است شامل حتی قابلیت‌های معماری مفصل‌تر و خاص شوند.

شکل ۳-۶: تکرارها در چرخه‌ی تکی ADM

1. 1. در مواردی که نیاز است معماری‌هایی در مقیاس بزرگتری توسط چندین تیم معماری مختلف، توسعه یابد، می‌توان از یک کاربرد سلسله مراتبی از ADM استفاده شود. این نگرش به ADM، از مرحله‌‌‌‌‌‌‌‌‌ی برنامه‌ریزی انتقال در یک چرخه ADM استفاده می‌کند تا پروژه‌های جدیدی را آغاز کند که آنها نیز معماری‌ها را توسعه می‌دهند. مطابق شکل ۳-۷ معماری‌ها در سطوح مختلف می‌توانند از طریق سلسله مراتبی از فرآیندهای ADMکه به طور همزمان اجرا می‌شوند، توسعه یابند.

شکل ۳-۷: مثالی برای سلسله مراتب فرآیندهای ADM
۳-۱۰- چارچوب محتوای معماری[۳۳]
این بخش به معرفی چارچوب محتوای معماری، یک متامدلِ ساخت‌یافته برای مصنوعات معماری، می‌پردازد.
۳-۱۰-۱- نمای کلی از چارچوب محتوای معماری
در طول اجرای ADM، تعدادی خروجی به عنوان نتیجه ایجاد می‌شوند مانند جریان‌های پردازش، نیازمندی‌های معماری، طرح‌های پروژه، ارزیابی انطباق پروژه و…. برای اینکه بتوان این محصولات کار اصلی را مرتب نمود و به شکلی قابل قبول و ساخت‌یافته ارائه داد، به یک چارچوب محتوای معماری نیاز است تا بتوان نتایج را بر اساس آن ارائه داد. این کار، مراجعه آسان‌تر و دسته‌بندی استاندارد را امکان‌پذیر می‌کند و همچنین به ارتباط بین محصولات مختلف کار اصلی ساختار می‌بخشد که از آن به عنوان «معماری سازمانی» یاد می‌شود، تسهیل می‌کند.
چارچوب محتوای معماری که در توگف۹ تولید شده است به توگف امکان می‌دهد که به عنوان یک چارچوب مستقل برای معماری موجود در یک سازمان مورد استفاده قرار گیرد. به هر حال چارچوب‌های محتوای دیگری نیز اکنون وجود دارند (مانند ArchiMate و چارچوب Zachman) و انتظار می‌رود که بعضی سازمان‌ها ممکن است ترجیح دهند که از یک چارچوب خارجی در رابطه با ADM استفاده کنند. در این موارد، چارچوب محتوای معماری توگف، یک مرجع مفید برای نگاشت به متامدل سایر چارچوب‌ها و نقطه آغازی برای محتوای توگف است
به منظور کمک به دسته‌بندی تولیدات کار جدید و پتانسیل موردنیاز برای ارتباط با سایر چارچوب‌های محتوا (شامل هر نوع معماری دسته‌بندی محصولات کار)، چارچوب محتوای معماری، از سه مقوله‌ی زیر برای توصیف نوع محصول کار معماری، در زمینه کاربرد آن استفاده می‌کند.
۱–اقلام قابل تحویل، محصولی رسمی از کار معماری است که به صورت قراردادی تعیین می‌شود و معمولاً بررسی می‌شود، مورد موافقت قرار می‌گیرد و توسط ذینفعان آن امضاء می‌شود. اقلام قابل تحویل، اغلب نشان دهنده‌ی خروجی پروژه‌ها است.
۲–مصنوعات، محصولی جزئی‌تر از کار معماری است که معماری را از نقطه‌نظر خاصی توصیف می‌کند. ممکن است شامل بعضی چیز‌ها به عنوان مشخصات یک مورد کاربری، لیستی از نیازمندی‌های معماری یا یک نمودار شبکه باشد. مصنوعات عموماً در قالب یکی از این موارد دسته‌بندی می‌شوند: کاتالوگ‌ها(لیستی از اشیاء)، ماتریس‌ها (نشان دهنده‌ی ارتباط بین اشیاء) یا نمودارها (تصاویر اشیاء). یک قلم قابل تحویل معماری ممکن است شامل مصنوعات زیادی باشد.
۳–بخش های سازنده نشان دهنده‌‌‌ی یک جزء کسب‌و‌کار (با قابلیت استفاده مجدد)، فناوری اطلاعات یا توانمندی معماری است که می‌تواند با سایر بخش‌های سازنده برای ارائه‌‌ی معماری‌ها و راه ‌حل ‌ها ترکیب شود.
بخش‌های سازنده می‌توانند در سطوح مختلفی از جزئیات تعریف شوند و می‌توانند به معماری‌ها و راه ‌حل ‌ها مربوط باشد. معمولاً به وسیله‌ی بخش‌های سازنده‌ی معماری، توانمندی موردنیاز برای شکل دادن بخش‌های سازنده‌ی راه‌حل تشریح می‌شود و این بخش‌های سازنده‌ی راه‌حل، اجزائی را نشان خواهند داد که برای پیاده‌سازی توانمندی موردنیاز، باید مورد استفاده قرار گیرند.
ارتباط بین اقلام قابل تحویل، مصنوعات و بخش‌های سازنده در شکل ۳-۱۴نشان داده شده است.
شکل ۳-۸: ارتباط بین اقلام قابل تحویل، مصنوعات و بخش‌های سازنده
۳-۱۰-۲- متا مدلِ محتوا
چارچوب محتوای معماری براساس یک متامدل محتوای استاندارد است که برای همه انواع بخش‌های سازنده‌ی موجود در معماری، تعریفی ارائه می‌کند. یک نگاه سطح بالا از محتوای متامدل در شکل ۳-۹ نشان داده شده است. متامدل نشان می‌دهد که چگونه بخش‌های سازنده می‌توانند توصیف شوند و چگونه می‌توانند به یکدیگر مرتبط باشند.