• جلوگیری از شکست معماری سازمانی و افزایش شانس موفقیت آن

• کاهش امکان هدر رفتن سرمایه‌های سازمانی نظیر بودجه، زمان، نیروی انسانی

• توانمندسازی سازمان در پاسخگویی به نیازمندی‌های ذینفعان خود

• افزایش انعطاف پذیری و تطبیق پذیری نسبت به تغییرات

• افزایش اثربخشی معماری سازمانی

• فراهم آوردن امکان مدیریت مؤثرتر تغییرات

• مدیریت بهینه منابع سازمانی

• کاستن از زمان تحویل محصولات معماری

• • قابل فهم کردن معماری برای ذینفعان معماری از طریق سادگی در معماری

• ایجاد قابلیت استفاده مجدد برای محصولات معماری

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

• افزایش رضایتمندی ذینفعان

• کاستن از حجم مستندات معماری

۲-۸-۷- اصول حاکم بر معماری سازمانی چابک
معماری سازمانی چابک دارای مشخصات و اصولی می‌باشد. همان‌طور که متدولوژی‌‌ها و اصول حاکم بر معماری سازمانی متأثر از متدولوژی‌های توسعه نرم‌افزار و مدیریت پروژه‌های فناوری اطلاعات می‌باشد، معماری سازمانی چابک هم متأثر از روش‌های چابک توسعه نرم‌افزار و اصول چابک مدیریت پروژه‌های فناوری اطلاعات می‌باشد.
بسیاری از اصول حاکم بر معماری چابک برگرفته از اصول حاکم بر توسعه‌ی نرم‌افزار چابک می‌باشد. اما نرم‌افزار، صرفاً به عنوان بخشی از معماری فناوری اطلاعات در سازمان می‌باشد و لازم است به سایر حوزه‌های معماری نیز توجه نمود. از جمله‌ی این حوزه‌ها باید به حوزه‌ی کسب‌و‌کار و فناوری اشاره کرد. لذا معماری دارای اصول مربوط به خود است.
برخلاف چارچوب‌های کلاسیک معماری سازمانی که معماری سازمانی ایستا بوده و ذینفعان معماری در سازمان کمتر درگیر کار معماری می‌شوند، در معماری سازمانی چابک بر نقش افراد بسیار تأکید می‌شود. نقش افراد در دو بخش بر کار معماری اثرگذار است. بخش اوّل در تیم‌های توسعه، در قالب خلاقیت و هوش افراد و بخش دوّم برای افراد منتسب به سازمان که در قالب تعهد و تعامل آنان نسبت به کار معماری، ظهور می‌یابد. بازخوردهای کار معماری در سازمان که نتیجه‌ی تعامل بالای با ذینفعان است، نقش تعیین کننده‌ای در اثربخشی و کارآیی معماری خواهد داشت.
چارچوب‌های کلاسیک معماری سازمانی یک چارچوب را برای انواع مختلفی از کسب و کار تجویز می‌کنند و مستندسازی مطابق با یک قالب مشخص و سطحی مشخص از جزئیات انجام می‌شود و معمولاً مستندات حجمی زیادی دارند و بدون در نظر گرفتن نیازمندی‌های کسب و کار و اولویت‌بندی آنان، تولید می‌شوند.
از دیگر مشخصه‌ های معماری چابک فاصله زمانی کوتاه بین تدوین و اجرای معماری و یا همزمانی تدوین سند معماری و پیاده سازی معماری در سازمان می‌باشد. برای به حداقل رساندن فاصله زمانی بین تدوین سند معماری و پیاده سازی آن در سازمان، فرایند توسعه معماری با رویکرد تکامل تدریجی و حول محور نیازمندی‌های سازمان تکرار می‌گردد.
روش‌های چابک سبب می‌شوند که کاربران و ذینفعان به شکل فعال‌تر و مؤثرتری در جریان انجام کارها مشارکت نمایند. هدف روش‌های چابک این است که نیازمندی‌های کاربران را تأمین و اجرا نمایند نه اینکه حجم بالایی از مستندات را تولید نمایند. روش‌های چابک کلیه ذینفعان معماری را همانند معماران و توسعه دهندگان و مدیران پروژه ها جزئی از تیم کاری به حساب می‌آورند و سعی دارند تا با بهره گرفتن از روش‌های ابتکاری، نشاط و انگیزه را در بین افراد تقویت کنند[۳۱].
معماری سازمانی چابک دارای خصوصیات خاص خود می‌باشد و این به تفاوت مهندسی و مدیریت با معماری برمی‌گردد. در معماری علاوه بر اصول مهندسی بر هنر نیز تأکید بسیاری وجود دارد. همچنین در معماری هم برجنبه‌های رفتاری تأکید وجود دارد و هم برجنبه‌های ساختاری. در معماری سازمانی چابک به دلیل اینکه با سازمان سروکارداریم لذا پیچیدگی و تلاطم در مسأله بیشتر وجود داشته و توجه به منابع انسانی از اهمیت بیشتری برخوردار است. در معماری سازمانی چابک نیاز فراوانی به مؤلفه‌های قابل استفاده مجدد پویا می‌باشد. همچنین در معماری سازمانی چابک، روش ها، تجارب عملی و فرایند‌ها و افراد خاصی مورد نیاز می‌باشد. بدین منظور می‌توانیم اصول معماری سازمانی چابک را چنین تعریف می‌نماییم[۵]:

• رعایت اصل سادگی

• پویایی در رفتار و تطبیق پذیری در مقابل تغییرات

• استفاده از روش‌های تکاملی و تدریجی و چابک

• تأکید بر افراد به جای تأکید بر فرایند‌ها و ابزارها

• تأکید بر ابتکار، خلاقیت، نوآوری، هوشمندی

• نتیجه گرایی

۳–چارچوب معماری توگف
۳-۱- مقدمه‌ای بر توگف
توگف یک چارچوب معماری سازمانی است که توسط Open Group ارائه شده است. توگف ابزاری برای کمک به پذیرش، تولید، استفاده و نگهداری طرح‌های معماری سازمانی می‌باشد. توگف بر پایه یک مدل فرآیندی تکرار پذیر می‌باشد، که توسط بهترین راهکارهای عملی و مجموعه‌ای از اجزای معماری با قابلیت استفاده مجدد، پشتیبانی می‌گردد. توگف توسط انجمن معماری Open Group توسعه و نگهداری می‌شود. اولین نسخه توگف، در سال ۱۹۹۵، بر پایه چارچوب معماری فنی وزارت دفاع ایالات متحده آمریکا برای مدیریت اطلاعات^[۲۱] ایجاد شد. با شروع کردن از این پایه‌ی بی نقص، انجمن معماری Open Group نسخه‌های موفقی از توگف را در دوره‌های زمانی معین ایجاد کرد و هر یک را بر روی وب سایت جامع Open Group منتشر ساخت. هسته توگف روشی است - تحت عنوان روش توسعه معماری^[۲۲] توگف - و برای توسعه یک معماری سازمانی که به نیازهای سازمان اشاره کامل می‌کند، به کار می‌رود.
۳-۲- ساختار سند توگف [۳۳]
ساختار سند نسخه‌ی ۹ از توگف، به هفت بخش تقسیم می‌شود که عبارتند از :
بخش ۱: مقدمه
این بخش یک معرفی سطح بالا از مفاهیم معماری سازمانی و به ویژه، برای روش توگف فراهم می‌کند و تعاریفی از واژه‌های مورد استفاده در سراسر توگف شامل می‌شود و جزئیات تغییرات میان این نسخه و نسخه‌های قبلی از توگف را منتشر می‌کند.
بخش ۲ : روش توسعه‌ی معماری
این بخش هسته‌ی اصلی توگف می‌باشد و روش توسعه‌ی معماری(ADM) را به صورت گام به گام برای توسعه‌ی یک معماری سازمانی توصیف می‌کند.
بخش ۳ : تکنیک‌ها و دستورالعمل‌های ADM
این بخش مجموعه‌ای از تکنیک‌ها و دستورالعمل‌های در دسترس را برای اجرای ADM شامل می‌شود.
بخش ۴ : چارچوب محتوای معماری
این بخش چارچوب محتوای توگف را توصیف می‌کند و یک متامدل ساخت‌یافته برای مصنوعات^[۲۳] معماری، بخش‌های سازنده‌ی معماری^[۲۴] با قابلیت استفاده مجدد و نمایی کلی از اقلام قابل تحویل متداول معماری شامل می‌شود.
بخش ۵ : ابزارها و زنجیره‌ی سازمان
این بخش به بحث طبقه‌بندی و ابزارهای مناسب برای دسته‌بندی و ذخیره خروجی‌های^[۲۵] فعالیت معماری در یک سازمان می‌پردازد.
بخش ۶ : مدل‌های مرجع چارچوب توگف
این بخش دو مدل مرجع معماری، یعنی مدل مرجع فنی^[۲۶] و مدل مرجع یکپارچه زیرساخت اطلاعات^[۲۷] را ارائه می‌کند.
بخش ۷ : چارچوب توانمندی معماری
این بخش در مورد ساختار، فرآیندها، مهارت‌ها، نقش‌ها و مسئولیت‌های موردنیاز برای ایجاد و راه‌اندازی یک معماری در سازمان بحث می‌کند.
هدف از تقسیم مشخصات توگف به این بخش‌های مستقل این است که اجازه می‌دهد حوزه‌های تخصصی مختلف، به صورت تفصیلی در نظر گرفته شوند و این امکان وجود دارد هر بخش به تنهایی مورد توجه قرار گیرد. اگر چه تمام بخش‌ها به عنوان یک کل، با هم کار می‌کنند اما امکان انتخاب بخش‌های خاصی برای تطابق، بدون در نظر گرفتن بقیه وجود دارد. به عنوان مثال، یک سازمان ممکن است مایل به اتخاذ فرایند ADM باشد، امّا به استفاده از هر یک از مواد مربوط به قابلیت معماری تمایلی نداشته باشد[۶۲].