جنبه‌ها و حوزه‌‌های مختلف سازمان می‌باشد. وجود یک چارچوب از طریق کمک تفکر نظام‌مند در خصوص سازمان، مدیریت منابع سازمانی را تسهیل کرده و از چندباره کاری و یا نادیده گرفته شدن احتمالی جلوگیری می‌کند و از این جهت بهره‌‌وری سازمانی را به دنبال خواهد داشت.
زکمن چارچوب معماری را این گونه تعریف می‌کند: «یک ساختار منطقی برای رده‌بندی و سازماندهی توصیف‌‌های مختلف از یک سازمان است که برای مدیریت و توسعه سیستم‌‌های آن سازمان حائز اهمیت می‌باشد.»
تعاریفی متعددی برای چارچوب معماری ارائه شده است، نظیر :
«چارچوب، ساختاری منطقی برای طبقه‌بندی و سازماندهی اطلاعات پیچیده و درهم تنیده می‌باشد كه به منظور طراحی یا توصیف سیستم‌ها به روشی علمی و مدون به کار می‌رود[35].»
«چارچوبهای معماری، روش‌هایی برای تفكر سازماندهی شده در باره سیستم‌‌های پیچیده و بزرگ ارائه می‌كنند[7].»
وظیفه‌ی معماری سازمانی، پیاده سازی ساختار معماری در سازمان است. پوشش همه جانبه‌ی فعالیت‌های سازمانی سبب می‌شود که ساختار معماری سازمانی، پیچیده و مبهم به نظر آید، بنابراین برای جلوگیری از مشکلات و شناسایی مدلی مناسب، وجود یک چارچوب معماری سازمانی حیاتی است. استفاده از چارچوب مناسب، تحلیل ساختار سازمانی را بمنظور تعیین وضعیت کنونی، شرایط بهینه و همچنین تعریف کارکردهای انتقالی، تسهیل می‌سازد[60].
در حوزه‌ی معماری سازمانی، چارچوب بیش از هر حوزه‌ی دیگری مورد توجه است به گونه‌ای كه می‌توان گفت بدون وجود چارچوب، معماری معنایی ندارد. انتخاب چارچوب در هر پروژ‌های كه به نوعی مربوط به معماری اطلاعات می‌شود، تضمین كننده‌ی یكنواختی و استاندارد، در زمان گذار و یكپارچه‌سازی سامانه‌‌‌های اطلاعاتی است[35].
چارچوب معماری سازمانی قصد دارد امكان تمركز برروی یك جنبه از سازمان بدون از دست دادن دیدگاه كل‌نگر برای تمام ذینفعان را فراهم آورد. یك چارچوب خوب، تضمین كننده جامعیت محصولات نهائی تولید شده برای معماری می‌باشد. چارچوبهای معماری سازمانی مانند قفسه‌‌های خالی یك كتابخانه هستند كه در آن مشخص شده چه چیزهائی باید تهیه شده و جایگاه هر كدام كجاست. بدین شكل هم خروجی‌‌های كه از معماری سازمانی مورد انتظار می‌باشد، تعیین شده و هم چگونگی مرتب‌سازی آنها بیان گردیده است[8].
2-1-3- انواع معماری سازمانی
درخصوص انواع معماری سازمانی نمی‌توان به صورت قطعی دسته‌بندی‌‌هایی را برشمرد و با توجه به سطح جزئیات توصیف سازمان، زمان، ابعاد و جنبه‌‌های مختلف سازمان و دیدگاهی که به کسب و کار سازمان وجود دارد، معیارها، تعاریف و دسته‌بندی‌‌های مختلفی از معماری سازمانی ارائه شده است که در این بخش به برخی از آنها می‌پردازیم:
الف) طبقه‌بندی براساس زمان: در این نوع دسته بندی، اغلب برای معماری سازمانی، دو وضعیت «فعلی» و «مقصد» متصور است که به ترتیب از آنها به «معماری وضع موجود» و «معماری وضع مطلوب» تعبیر می‌شود.
ب) طبقه‌بندی براساس جنبه‌ای از سازمان که براساس آن سند معماری تدوین می‌گردد. معمولاً در این حالت، معماری سازمان در چهار لایه‌ی کسب و کار، داده، برنامه کاربردی و فناوری مستند می‌گردد و به ترتیب از آنها به عنوان معماری کسب و کار، معماری داده، معماری برنامه کاربردی و معماری فناوری یاد می‌شود.
ج) معماری سازمانی فرآیند محور2
این نوع معماری سازمانی با هدف مدیریت و بهبود فرآیندها صورت می‌پذیرد، اهداف کسب و کار با رویکردی بالا به پائین به عملیات و فعالیت‌ها نگاشت می‌شود تا نهایتاً کلیه فرآیندهای کسب و کار سازماندهی شوند، این نوع پروژه‌‌های معماری سازمانی توسط مدیران ارشد کسب و کار اجرا شده و زیر نظر مستقیم ریاست سازمان می‌باشند[9].
د) معماری سرویس‌گرا3
معماری سرویس‌گرا مفهومی جدید نیست و از دهه 90 میلادی وجود داشته است ولی آنچه جدید است توانائی اجرا و عینیت بخشیدن به آن است که به کمک ابزارها و پروتکل‌‌های مربوطه میسر شده است. معماری سرویس‌گرا از دیدگاه‌‌های مختلف قابل بررسی است و هر فرد یا ذینفع بر طبق جایگاه خود تصویری از معماری سرویس‌گرا دارد[9].
برای معماری سرویس‌گرا تعاریف مختلفی ارائه شده است. IBM، معماری سرویس‌گرا را این گونه تعریف می‌کند[36]: «رهیافتی برای ساخت سیستم‌‌های توزیع شده که کارکردهای نرم‌افزاری را در قالب سرویس ارائه می‌کند. این سرویس‌ها هم توسط دیگر نرم‌افزارها قابل فراخوانی هستند و هم برای ساخت سرویس‌‌های جدید مورد استفاده قرار می‌گیرند، این رهیافت برای یکپارچه سازی فناوری‌ها در محیطی که انواع مختلفی از سکو‌های نرم‌افزاری و سخت افزاری وجود دارد ایده آل است.»
ه) طبقه‌بندی براساس حجم مستندات معماری، میزان انعطاف‌پذیری، تطابق با تغییرات محیطی و بویژه تغییرات پیش بینی نشده صورت می‌گیرد و از آن به عنوان معماری چابک و یا غیرچابک یاد می‌شود که در ادامه به طور مفصل‌تری به آن خواهیم پرداخت.
2-1-4- محصولات معماری سازمانی
به خروجی‌‌های فرآیند معماری سازمانی، «محصولات معماری» گفته می‌شود. خروجی‌‌های معماری سازمانی شامل توصیف‌هایی متنی و گرافیکی از جنبه‌ها و لایه‌‌های مختلف معماری سازمانی است. توصیف‌‌های فوق، بنا به مورد از مدل‌ها و تکنیک‌‌های خاصی استفاده می‌کنند. خروجی‌‌های معماری سازمانی معمولاً در قالب یکسری کتابچه مشخص ارائه می‌گردند.
2-2- تاریخچه‌ی معماری سازمانی
پس از ظهور رایانه و ورود سیستم‌‌های اطلاعاتی در دهه‌ی 1960 به محیط‌‌های کسب و کار و به دنبال استقبال گسترده در استفاده از آنها، نگرانی‌‌ها‌یی برای صاحبان کسب و کار و سازمان‌ها ایجاد شد که می‌توان چالش‌هایی را نظیر چگونگی مدیریت و برنامه‌ریزی در جهت استفاده بهینه، متناسب ساختن با کسب و کار، روش توسعه سیستم‌‌های اطلاعاتی و یافتن روش‌هایی استاندارد برای توسعه‌ی آنها برشمرد.
تلاش‌ها و اقدامات مرتبط با توسعه سیستم‌ها، در ابتدا وابسته به روش‌‌های تصادفی و غیرسیستمی بودند. در اواخر دهه 1960، مشکلات توسعه سیستم‌ها منجر به پدید‌های تحت عنوان بحران نرم‌افزار گردید. این عارضه به معنی نگاه و تمرکز سیستم‌ها بر توسعه، همراه با هزینه زیاد، عدم کارکرد و زمان طولانی است.
با توجه به پیچیدگی سیستم‌ها، نیاز شدیدی به توسعه بود، در حالی که وضعیت، روز به روز بحرانی‌تر می‌شد. به همین دلیل رویکرد‌های متدولوژی به توسعه سیستم‌ها پدیدار گشت. توجه به متدولوژی در دهه 70 تا 80 بسیار زیاد بود. در این دهه‌ها بحث، بیشتر روی دو رویکرد سخت‌افزار و نرم‌افزار از توسعه سیستم‌‌های اطلاعاتی قرار داشت. در این دوران سازمان‌های بزرگ و دولت‌ها از متدولوژی‌‌های خاصی برای مدیریت پروژه‌‌های IT خود استفاده کردند. استفاده از این متدولوژی‌ها با مشکلاتی همراه شد. مثلاً اینکه آنها هرگز کار نمی‌کردند یا با تأخیر طولانی کار می‌کردند و یا با عملکرد پایین خود انتظارات کاربران را برآورده نمی‌نمودند. در اواخر دهه 80 انتقادات نسبت به متدولوژی افزایش یافت و در دهه 90 مطالعات روی این موضوع کاهش یافت و آن هم به دلیل مخالفت با مکتب متدولوژی و شکست‌‌های پی در پی آن و مورد دیگر تغییر الزامات و نیازمندی‌‌های سازمان‌ها بود. تحول در تکنولوژی و ساختار سازمان‌ها عللی دیگر بر عدم پذیرش متدولوژی‌ها بود[47].
در اوایل دهه 90 میلادی، با رشد انفجارگونه فناوری‌‌های اطلاعات جدید به ویژه با ابداع و همه‌گیر شدن اینترنت و محیط‌‌های چند رسانه‌ای، سازمان‌های بزرگ با كاربرد‌های متنوع این فناوری‌ها در واحدهای تابعه خود، روبه رو شدند. هر یك از این واحدها در جهت خاصی در حال گسترش بودند. این سازمان‌ها از سویی زیر فشار تقاضا‌های زیاد و روزافزون كاركنان خود و از سوی دیگر با دسترسی به بازار‌های گسترده محصولات، ناگزیر از استخدام و بكارگیری عملی محیط‌ها و فناوری‌‌های جدید شدند. بكارگیری مدام فناوری اطلاعاتی جدید مستلزم سرمایه‌گذاری هنگفتی در این زمینه بود كه برای انجام آن نیاز به توجیه اقتصادی كافی و برنامه‌‌های استراتژیك، احساس می‌شد. این امر خود را در سازمان‌های دولتی آمریكا كه برای تامین هزینه خود به بودجه عمومی دولت متكی بودند، با شدت بیشتری آشكار نمود. به دلیل شتاب روزافزون نوآوری در زمینه فناوری اطلاعات و سرمایه گذاری‌‌های بی هدف، فناوری‌‌های جدید به سرعت كهنه شده و بدون بازگشت سرمایه اولیه، منجر به خروج سرمایه از چرخه منابع سازمان‌ها می‌شدند[8].
در سال 1992 وزارت دفاع آمریكا4 پروژه تحقیقاتی را آغاز كرد كه به اختصار TAFIM5 نامیده شد، هدف از این پروژه تهیه یك طرح جامع برای چارچوب بخشیدن و هماهنگ كردن کلیه منابع اطلاعاتی در داخل مجموعه وزارت دفاع بود. در سال 1994 وزارت دفاع آمریكا با انتشار بیان‌های واحدهای تابعه خود را ملزم به اجرای نتایج TAFIM و انطباق سیستم‌‌های اطلاعاتی خود با آن نمود. این تجربه مورد استقبال سایر وزارتخانه‌ها و موسسات دولتی فدرال قرار گرفت و روشها و الگو‌های بكار گرفته شده در آن در سایر سازمان‌ها نیز بكار گرفته شد.
در سال 1996 قانونی در كنگره آمریكا به تصویب رسید كه به قانون كلینگر-كوهن6 معروف شد. مطابق این قانون همه وزارتخانه‌ها و سازمان‌های فدرال آمریكا ملزم شدند معماری فناوری اطلاعات خود را تنظیم كنند. مسئولیت تدوین، اصلاح و اجرای معماری فناوری اطلاعات یكپارچه در هر سازمان مطابق این قانون بر عهده مدیر ارشد اطلاعاتی آن سازمان قرار گرفت. این قانون مهمترین سند قانونی در مورد الزام تنظیم معماری اطلاعاتی در سازمان‌های دولتی آمریكاست. به دنبال تصویب آن، سازمان مدیریت و بودجه ریزی آمریكا نیز در رهنمودی كه در سال 1996 منتشر ساخت، بر لزوم هماهنگی طرح‌ها و هزینه‌‌های انجام شده توسط مؤسسات دولتی آمریكا با معماری فناوری اطلاعات سازمان تأكید نمود. پس از آن تاریخ تقریباً همه موسسات دولتی آمریكا، از جمله وزارتخانه‌ها، سازمان‌ها، نیروی انتظامی و دانشگاه‌هایی كه از بودجه دولتی استفاده می‌كنند، پروژه‌هایی را برای تنظیم و تدوین معماری اطلاعات خود به انجام رسانده‌اند. پس از این وقایع شورای مدیران ارشد اطلاعاتی آمریكا، سندی را منتشر ساخت كه حاوی چارچوب معماری سازمانی دولت فدرال آمریكا است[8].
2-3- ضرورت و نتایج معماری سازمانی
«جان زكمن» یكی از پیشگامان معماری سیستم‌‌های اطلاعاتی در سال 1987 در كتاب «چارچوب زكمن در معماری سازمانی» می‌گوید: «برای جلوگیری از فروپاشیدگی مأموریت‌‌‌های سازمان، لازم است تا مفهوم معماری سازمانی از یك موجودیت غیرضروری به یك موجودیت ضروری و واجب تبدیل شود.» زکمن انگیزه اصلی خود از ارائه معماری سازمانی را «حل مشكل مربوط به پیچیدگی سیستم‌‌های اطلاعاتی و بهبود مدیریت بر آن» می‌داند. وی پیچیدگی را نه فقط از جنبه بزرگ شدن سیستم‌ها بلكه مربوط به عوامل متعددی نظیر توزیع شدگی جغرافیائی سیستم‌ها، نیاز به تغییرات سریع سیستم‌ها به دلیل رشد سریع بازار تجارت، نیازمندی‌‌های خاص و كلیدی شدن جایگاه فناوری اطلاعات در سازمان‌ها می‌داند[9].
لزوم معماری سازمانی را می‌توان در ظهور سازمان‌های بزرگ، نیاز به طراحی و توسعة سیستم‌‌های اطلاعاتی پیچیده، ظهور سیستم‌‌های اطلاعاتی با منظور‌های خاص و اهمیت انعطاف‌پذیری سازمان‌ها در برابر فشار‌های بیرونی نظیر تغییر كسب و كار، تغییر مأموریت‌ها و ساختار‌های سازمانی و تغییرات سریع فناوری ارزیابی كرد[6].
یكی از دلایل افزایش اهمیت مقوله معماری سازمانی، نیاز به همراستایی فناوری اطلاعات و همراستایی كسب و كار است[37]. همراستایی استراتژیك نیازمند ابزار است، یكی از این ابزارها معماری سازمانی است. معماری سازمانی تعریف جامع و یكپارچ‌های از عناصر كلیدی سازمان و نحوه ارتباط آنها ارائه می‌دهد. به عبارت دیگر معماری سازمانی تصویر سیستماتیكی از ازمان، فرآیندهای تجاری، دادهها و فناوری اطلاعات به نمایش می‌گذارد كه زیربنایی برای همراستایی استراتژیك می‌باشد[38].
یكی از علل
