معماری سازمانی

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به: ناوبری، جستجو

در سازمان‌های امروزی که اغلب دارای ابعاد و ساختارهای پیچیده و از نظر فیزیکی توزیع شده هستند تنها ذکر اینکه چه کارهایی باید توسط چه کسانی (شرح وظایف) انجام شود کافی نیست، بلکه فرایندها، داده‌ها، اهداف و نقش افرادی که در سازمان انجام وظیفه می‌کنند باید با اهداف و راهبردهای سازمان که در قالب برنامه‌ریزی راهبردی ارائه می‌شوند، همخوانی داشته باشد. چنین امری مستلزم آن است که سازمان دارای یک نقشه از تمام ابعاد خود باشد تا بتواند با استفاده از این نقشه، روابط بین ابعاد سازمان را درک نموده و در صورت نیاز با تغییرات هماهنگ نماید. این نقشه از سازمان، که حاوی اطلاعات افراد، فرایندها، مکان‌ها و دیگر ابعاد و خصوصیات سازمان است، معماری سازمانی نامیده می‌شود.

مقدمه[ویرایش]

معماری سازمانی چارچوبی برای تببین، هماهنگ‌سازی و همسوسازی کلیه فعالیت‌ها و عناصر سازمان در جهت نیل به اهداف راهبردی سازمان است. معمار سازمانی همانند دیگر معماران با بخش‌های مختلف سیستم درگیر می‌شود، اما برخلاف دیگر معماری‌ها، معمار با سیستمی مواجه‌است که اجزای آن اغلب غیرفیزیکی، غیرقابل لمس و مفهومی بوده و روابط حاکم بر آنها منبعث از روابط و فرهنگ کاری و (یا) انسانی است. جهت توصیف چنین سیستمی، او نمی‌تواند از روش‌های رایج برای دیگر معماری‌ها استفاده نماید و نیاز به استفاده از مدل‌های مختلف دارد. می‌توان معماری سازمانی را با مجموعه‌ای از مدل‌های بهم پیوسته و مرتبط نمایش داد که انتخاب بین انواع مدل‌های مناسب بر عهده معمار است. معماری سازمانی ریشه گرفته از بحث «معماری سیستم‌های اطلاعاتی» و به خصوص «معماری اطلاعات» و ادامه این نوع از معماری‌ها بطور خاص در سازمان است. تفاوت معماری سازمانی و معماری سیستم‌های اطلاعاتی در این است که معماری سازمانی تمام جنبه‌های سازمان نظیر کاربران، موقعیت جغرافیایی سیستم‌ها، نحوه توزیع آنها، فرآیندهای حرفه، انگیزه کارها، راهبردها، ماموریت‌های سازمان و غیره را در نظر می‌گیرد، در حالیکه معماری اطلاعات، تنها بر اطلاعات متمرکز شده‌است. در واقع، در معماری سازمانی با یک نوع مهندسی مجدد در کل سازمان، از منظر سیستم‌های اطلاعاتی روبرو هستیم که سعی در بهبود فرآیندهای کاری سازمان از طریق به کارگیری فناوری اطلاعات دارد. این روش از لحاظ تاریخی پیشینه طولانی ندارد و در بین بقیه روش‌ها از تازه‌ترین‌هاست و در طبقه‌بندی آنها از گونه سازمان‌گرا و داده‌گراست و ناشی از گسترش بکارگیری فناوری اطلاعات در سازمان‌ها و افزایش تعاملات درون و برون سازمانی و همچنین شتاب روزافزون تغییرات است که بحران فناوری را ایجاد نموده‌است.

سابقه و تاریخچه[ویرایش]

تاریخچه معماری سازمانی

زمینه معماری سازمانی (معماری فناوری اطلاعات سازمانی) در سال ۱۹۸۷ با انتشار مقاله‌ای با نام «چارچوبی برای معماری سیستم‌های اطلاعاتی» توسط جان زکمن پایه‌گذاری گردید. در این مقاله زکمن به چالش و چشم‌انداز معماری‌های سیستم‌های اطلاعاتی اشاره می‌کند. چالش به مدیریت سیستم‌های توزیع شده همراه با پیچیدگی در حال افزایش، مربوط است. زکمن می‌گوید:

«هزینه و موفقیت کسب و کار، به طور روزافزون به سیستم‌های اطلاعاتی کسب و کار و رویکرد نظام‌مند برای مدیریت این سیستم‌ها، بستگی دارد»

چشم‌انداز زکمن آن بود که ارزش و چالاکی کسب و کار می‌تواند بوسیلهٔ رویکرد همه‌جانبه برای معماری سیستم‌ها بهتر درک شود. یعنی هر موضوع از هر منظری نگاه گردد. رویکردهای چند بعدی برای معماری سیستم‌هایی که زکمن توضیح می‌دهد ابتدا «چارچوب معماری سیستم‌های اطلاعاتی» نام گرفت و به سرعت به «چارچوب معماری سازمانی» تغییر نام یافت.

زکمن در یکی از نخستین تلاش‌های خود تأثیر عمیقی در معماری سازمانی وزارت دفاع ایالات متحده گذارد. این فعالیت بنام «چارچوب معماری فنی برای مدیریت اطلاعات» شناخته می‌شود و در سال ۱۹۹۴ معرفی گردید.

در سال ۱۹۹۲ وزارت دفاع آمریکا پروژه‌ای تحقیقاتی TAFIM را با هدف تهیه یک طرح جامع برای انسجام و هماهنگی کلیه منابع اطلاعاتی در داخل مجموعه وزارت آغاز نمود. در سال ۱۹۹۴ این وزارت با انتشار بیانیه‌ای کلیه واحدهای تابعه خود را ملزم به اجرای نتایج TAFIM و انطباق سیستم‌های اطلاعاتی خود با آن نمود. TAFIM از آن تاریخ تاکنون همواره در حال بازنگری و اصلاح بوده و در حال حاضر نسخه ۳ آن توسط وزارت دفاع آمریکا مورد استفاده قرار می‌گیرد. این تجربه وزارت دفاع، مورد استقبال سایر وزارتخانه‌ها و موسسات دولتی قرار گرفت و روش‌ها و الگوهای بکار رفته در TAFIM در سایر سازمان‌ها نیز به کار گرفته شد. براساس تجربیات بدست آمده از پروژه TAFIM، در سال ۱۹۹۶ قانونی بنام «کلینگر- کوهن» در کنگره آمریکا به تصویب رسید که بر طبق این قانون و بر پایه نتایج TAFIM همه وزارتخانه‌ها و سازمان‌های دولتی آمریکا ملزم به تنظیم معماری فناوری اطلاعات سازمانی خود شدند. همچنین مسئولیت تدوین، اصلاح و اجرای معماری فناوری اطلاعات در هر سازمان برطبق این قانون برعهده مدیر ارشد فناوری اطلاعات سازمان قرار گرفت. به دنبال تصویب قانون کلینگر-کوهن که مهمترین سند قانونی در مورد الزام تنظیم معماری اطلاعاتی در سازمان‌های دولتی آمریکاست، سازمان برنامه و بودجه آمریکا نیز در رهنمودی که در سال ۱۹۹۶ منتشر ساخت بر لزوم هماهنگی طرح‌ها و هزینه‌های انجام شده توسط موسسات دولتی آمریکا با معماری فناوری اطلاعات سازمان تأکید نمود. پس از آن تاریخ اغلب موسسات دولتی آمریکا از جمله وزارتخانه‌ها، سازمان‌ها، نیروی انتظامی و دانشگاه‌هایی که از بودجه دولتی استفاده می‌کنند، پروژه‌هایی را برای تنظیم و تدوین معماری فناوری اطلاعات خود آغاز نمودند. سپس شورای مدیران ارشد فناوری اطلاعات آمریکا سندی را منتشر ساخت که حاوی چارچوب معماری سازمانی دولت فدرال بود که سند معماری اطلاعات دولت فدرال محسوب می‌شد و مستمراً در حال بازنگری و اصلاح است. این سند الگویی برای سازمان‌های بزرگ و مشتری مدار است.

در ایران معماری سازمانی ابتدا با نام معماری اطلاعات توسط دکتر فریدون شمس و همکارانش تبلیغ شد. این گروه سپس کمیته فنی معماری اطلاعات ایران را راه‌اندازی نمودند (http://enterprisearchitecture.ir). در سال ۱۳۸۵ برای اولین بار معماری سازمانی در دوازدهمین کنفرانس بین‌المللی انجمن کامپیوتر ایران به عنوان یک زمینه مستقل ارائه شد. سپس با تلاش‌های دکتر فریدون شمس مجوز ایجاد دوره کارشناسی ارشد معماری سازمانی در دانشگاه شهید بهشتی صادر شد. هسته پژوهشی معماری سیستم‌های اطلاعاتی از دیگر تلاش‌های علمی و کاربردی نمودن معماری سازمانی در ایران است. در حال حاضر شرکت‌ها و سازمان‌های بسیاری برای توسعه فناوری اطلاعات خود به این رویکرد روی آورده‌اند.
با گسترش نیاز موجود در کشور برای فراگیری و به‌کارگیری نظام مند رویکرد معماری سازمانی سرانجام با پشتکار وزارت ارتباطات، آزمایشگاه مرجع مدیریت طرح‌های معماری سازمانی(http://itc.ir/soea) در سازمان فناوری اطلاعات بصورت کامل راه اندازی شد، بخش ستادی این آزمایشگاه در سازمان فناوری اطلاعات ایران مستقر است و بخش فنی و اجرایی آن از سال ۹۱ در دانشگاه شهید بهشتی (قطب معماری سازمانی فناوری اطلاعات کشور) راه اندازی گردیده است. مأموریت بخش ستادی آزمایشگاه، سیاست گذاری و نظارتی است. در حالیکه مأموریت بخش فنی آزمایشگاه معماری سازمانی که در دانشگاه بهشتی مستقر است، تدوین اسناد مرجع فنی، ارزیابی طرح‌های معماری سازمانی و آموزش و فرهنگ سازی است.

با تلاش آزمایشگاه مرجع مدیریت طرح‌های معماری سازمانی، وزارت ارتباطات و فناوری اطلاعات اقدام به تصویب و ابلاغ بخشنامه‌ای خطاب به دستگاه‌های اجرایی نمود که در آن ضمن تشویق دستگاه‌ها، از آنها خواسته شده است برای تدوین طرح‌های معماری از ضوابط و شاخص‌های اعلام شده توسط سازمان فناوری اطلاعات پیروی نموده و در صورت دارا بودن طرح معماری سازمانی، «گواهی تاییدیه» را از آزمایشگاه فنی معماری سازمانی سرویس گرا اخذ نمایند. همزمان ضوابط فنی و اجرایی نیز با همکاری بخش فنی آزمایشگاه معماری سازمانی سرویس گرا، تدوین و برای انتشار در پورتال آزمایشگاه قرار گرفته است و در آینده نیز بصورت مرتب به روز رسانی خواد شد.

تفاوت محصولات معماری سازمانی با روش‌های دیگر[ویرایش]

طراحی و تولید سیستم‌های اطلاعاتی کوچک و محلی دارای پیشینه و تجربه زیادی بوده و روش‌های بسیاری برای آن ارائه شده‌است که آخرین آنها طراحی و توسعه براساس روش‌های شی‌گرا و بر پایه مولفه‌است که کمک بسیاری به انعطاف‌پذیری سیستم‌های اطلاعاتی نموده‌است. با این وجود روش‌های فوق نمی‌توانند در مورد سیستم‌های بزرگتری که حاوی چندین زیر سیستم کوچکتر هستند مفید واقع شوند. نگرشی که در طراحی و تولید یک سیستم اطلاعاتی مستقل وجود دارد مبتنی بر شناخت نیازمندی‌ها و موجودیت‌های اطلاعاتی محلی بوده و در نهایت منجر به ایجاد سیستمی برای مدیریت اطلاعات فوق می‌شود. سیستم‌های اطلاعاتی بزرگتر که خود از چندین زیر سیستم کوچکتر تشکیل می‌شوند، محتاج نگرشی کلی‌تر و همه‌جانبه‌تر به مسئله هستند تا بتوانند این جزایر اطلاعاتی را با هم مرتبط سازند. شباهت‌های زیادی که بین محصولات معماری سازمانی با خروجی‌های متدولوژی‌های تحلیل و طراحی سیستم‌ها نظیر SSADM و RUP و غیره دارد، اغلب گیج کننده بوده و این سؤال را مطرح می‌سازد که اساساً چه تفاوتی بین معماری سازمانی با روش‌های فوق وجود دارد. نکته کلیدی در پاسخ به این سؤال، توجه به مفهوم «عناصر پایه» است. همان‌طور که در بخش قبل نیز اشاره شد، هدف از معماری سازمانی ارائه توصیف‌هایی از جنبه‌های مختلف این عناصر پایه‌است. در این مورد معمولاً از تکنیک‌هایی استفاده می‌شود که در متدولوژی‌های تحلیل و طراحی نیز رایج است. به عنوان نمونه اغلب تکنیک‌های ساخت یافته‌ای که برای مدل‌های داده یا فرایند معماری سازمانی به کار می‌روند، عیناً برداشت شده از تکنیک‌های تحلیل و طراحی ساخت‌یافته یا شی‌گراست. در واقع، می‌توان گفت تفاوت اساسی در محصولاتی است که در معماری سازمانی ایجاد می‌شود. محصولات معماری سازمانی کاملاً نرمال بوده و طراحی آنها به گونه‌ای صورت گرفته که قادر به ایجاد «زیر ساخت» باشند. مهمترین نکته در رابطه با اجزائی که برای استفاده به عنوان زیر ساخت در نظر گرفته می‌شوند، قابلیت استفاده مجدد آنهاست. در صورتیکه این موضوع ممکن است در مورد محصولات متدولوژی‌های تحلیل و طراحی صادق نباشد. محصولات معماری سازمانی ابتدائی و ساده بوده و این قابلیت را دارند که بصورت دیگری ساخته شوند که این همان انعطاف‌پذیری است که به‌دنبال آن در معماری سازمانی هستیم. در مقایسه، سیستم‌های اطلاعاتی عموماً محصولاتی قابل انعطاف تولید نمی‌کنند و با هدف کاملاً روشنی تولید می‌شوند. به عبارت بهتر، با استفاده از توصیف‌های معماری سازمانی این امکان برای مدیران ارشد بوجود می‌آید که در صورت لزوم اقدام به ایجاد ترکیبی جدید از عناصر پایه و ارتباطات بین آنها نمایند.

کاربرد معماری سازمانی[ویرایش]

افراد مختلف سازمان می‌توانند کاربردهای مختلفی از معماری سازمانی داشته باشند. پس از تولید محصولات معماری، محصولات فوق در اختیار ذینفعان سازمان قرار داده می‌شوند. توصیف‌های موجود در محصولات فوق که عمدتاً به صورت گرافیکی ارائه می‌شوند کمک زیادی به تصمیم‌گیری‌ها، تحلیل‌های راهبردی، ارزیابی و اصلاح فرآیندهای حرفه، ارزیابی و سنجش کارایی، پیش بینی و برنامه‌ریزی تغییرات، ارزیابی هزینه‌ها و غیره می‌نماید. هر کدام از افراد فوق، بسته به جایگاه خودشان می‌توانند روی دیدگاه خاصی از معماری متمرکز شوند. بعنوان نمونه، دیدگاه‌های سطح بالایی چون «دیدگاه برنامه‌ریز» و «دیدگاه مالک» مناسب هیئت مدیره و مدیر ارشد سازمان است چرا که این دو دیدگاه توصیف کننده سرفصل‌های اطلاعاتی، ماموریت‌ها، فرآیندهای کاری، توزیع جغرافیایی مکان‌های سازمانی، ساختار سازمانی، رویدادهای مهم و راهبردهای مأموریتی سازمان هستند. از طرف دیگر، افرادی چون «کارشناسان فناوری اطلاعات»، «طراحان سیستم»، «تحلیل‌گران» و غیره می‌توانند توجه خود را روی محصولات «دیدگاه طراح» متمرکز کرده و به بررسی مواردی چون مدل مفهومی و منطقی داده‌ها، نمودارهای فعالیت، مدل مفهومی شبکه، سلسله مراتب سازمانی، نمودارهای ترتیبی و قواعد کار بپردازند. در هر صورت یکی از مواردی که لازم است قبل از شروع هر نوع معماری مشخص شود، هدف و منظور معماری است که نوع محصولات و چگونگی آنها را مشخص می‌نماید و کمک شایانی به همگرایی محصولات می‌کند. علاوه بر اینها، معماری سازمانی یک مخزن اطلاعاتی کامل از کل سازمان در اختیار می‌گذارد که مطالب آن به صورت اصولی طبقه‌بندی شده و قابل استفاده برای همه سازمان است. از لحاظ ماهیت، معماری سازمانی فرآیندی است که پیش از آنکه جنبه فنی داشته باشد، جنبه مدیریتی و عملیاتی دارد. این نسبت بعضاً ۸۰ به ۲۰ عنوان می‌شود.

فرایند معماری سازمانی[ویرایش]

هدف از فرایند معماری سازمانی ایجاد و اجرای معماری و ارائه خروجی‌های معماری در سازمان است. این فرایند در کنار دیگر فرآیندهای اصلی سازمان قرار گرفته و بصورت پیوسته اجرا می‌شود. بطور کلی، این فرایند شامل سه مرحله اصلی است که عبارتند از: ۱) برنامه‌ریزی راهبردی فناوری اطلاعات، ۲) برنامه‌ریزی معماری سازمانی، ۳) اجرای معماری سازمانی. هر کدام از این سه مرحله اصلی، به زیر مراحلی تقسیم می‌شوند که بررسی هر یک از آنها خارج از حیطه این تحقیق است، به همین دلیل تنها به توضیح «فرایند برنامه‌ریزی معماری سازمانی» خواهیم پرداخت. در واقع، برنامه‌ریزی راهبردی فناوری اطلاعات پایه‌ای برای برنامه‌ریزی معماری سازمانی است. برنامه‌ریزی معماری سازمانی، عبارتست از فرآیندی که به منظور تعریف معماری‌های لازم و برنامه‌ریزی جهت پیاده‌سازی معماری‌های فوق انجام شده و هدف از آن فراهم ساختن زمینه‌های استفاده مؤثر از اطلاعات جهت پشتیبانی از ماموریت‌های سازمانی است. این برنامه‌ریزی بر روی سه نوع زیر معماری انجام می‌شود که عبارتند از: معماری وضع موجود، معماری گذار و معماری وضع مطلوب. بهمراه تعریف معماری‌ها، برنامة اجرایی نیز برای اجرای آن ارائه خواهد شد تا معماری را به شکل عملی تبدیل نماید. اولین کاری که باید قبل از شروع مراحل «برنامه‌ریزی معماری سازمانی» انجام شود، تعیین مواردی چون چشم‌انداز، اهداف و اصول معماری سازمانی است. بعبارت بهتر، باید منظور معماری سازمانی بیان شود که همان خروجی‌های مرحله برنامه‌ریزی راهبردی فناوری اطلاعات را تشکیل می‌دهند. همچنین، باید در نظر داشت که این فرایند باید با همکاری تمام قسمت‌های سازمان انجام شود، بنابراین مستلزم حمایت مدیریت و اختصاص به موقع منابع و همکاری مدیران قسمت‌های مختلف سازمان است.

مجموعه مستندات معماری سازمانی (زمان انجام)[ویرایش]

مستندات نتایج گویای مؤلفه‌های معماری سازمانی مشتمل بر کسب و کار (Business) معماری اطلاعات (Information Architecture) سیستمهای کاربردی (Applications) و زیرساخت فناوری (Technology) می‌باشد.

  • معماری وضع موجود(As-IS): نشان دهنده وضع موجود بر اساس حقایقی که در سازمان وجود دارد اِیجاد می‌گردد. تجهیزات سخت‌افزارها شبکه‌ها و فرایندها و همهٔ سیستم‌های فعلی جزو معماری وضع موجود می‌باشند.
  • معماری وضع مطلوب (To-BE): چشم‌اندازی از آنچه که می‌خواهیم سازمان در آیندهٔ معین به آن برسد و گویای وضع آتی سازمان بر پایهٔ راهبردها، اهداف و برنامه‌های دراز مدت «معماری وضع مطلوب» نامیده می‌شود.
  • طرح انتقالی: سندی راهبردی و منظم با هدف برنامهٔ زمانی لازم برای انتقال سازمان از وضع موجود به وضع مطلوب می‌باشد. این سند حاوی تعریف و پیشنهاد به توسعهٔ سیستم‌های مطلوب(RFP)است.

چارچوب‌های معماری سازمانی[ویرایش]

نیاز به ارائه تفکرهای سازماندهی شده و ساختارهای منطقی طبقه‌بندی اطلاعات پیچیده و توصیف و مفهوم کارهای معمار پیشگامان معماری را بر آن داشت تا روش‌ها و الگوهای مختلفی را ابداع و به جامعه معماری این امکان را بدهند تا اطلاعات کار معماری را تبدیل به یک چارچوب نموده و به روش علمی و مدون نموده و بدین طریق هنر و علم خود را در اختیار دیگران بگذارد.

  • چارچوب معماری زکمن Zachman: را جان زکمن درسال ۱۹۸۷ برای صنعت و تجارت ارائه کرده‌است. وی در ابتدا این کار را با ارائه یک الگوی جامع در زمینه معماری اطلاعات شروع نمود و چون معتقد به تحلیل سازمان با استفاده از چارچوب معماری بود جنبه‌های مختلف طراحی یک سیستم از نظر محتوی، مفهوم، منطق، فیزیک و توصیف‌های دقیق غیر محتوایی را به صورت یک سری سؤال از دیدگاه داده، وظیفه، شبکه، افراد، زمان و انگیزه در یک جدول که تکمیل آن توصیف معماری انجام شده و پاسخ چه چیز، چطور، کجا، چه کسی، کی و چرا ی آینده سازمانی پویا می‌باشد.
  • چارچوب معماری C4ISR/DoDAF: که وزارت دفاع آمریکا درسال ۱۹۹۶ آن را در ابتدا برای توصیف معماری سیستم‌های نظامی عملیات مشترک طراحی نموده بود دارای چارچوبی بسیار جامع برای بیان سطوح مختلف یک سِستم می‌باشد و محصول نهائی آن تعدادی مستند معین گویای سه دیدگاه عملیاتی، سیستم و تکنیکی معماری انجام یافته بوده ودر نهایت آن را توصیف می‌نماید.
  • چارچوب معماریTOGAF: Open Group آن را در سال ۱۹۹۵ ارائه کرده‌است.
  • چارچوب معماری FEAF: شورای مدیران (CIO Council) دولت فدرال آمریکا آن را درسال ۱۹۹۹ برای افزایش تعامل در سطوح دولتی ارائه کرده‌است. این معماری شامل رهنمودهایی برای معماران سیستم‌های اطلاعاتی در توصیف مأموریت هائی که در اجراء آن چندین سازمان به صورت مشترک در دولت فعالیت دارند مورد استفاده قرار می‌گیرد. این چارچوب معماری سازمانی یک سازوکار سازماندهی مدیریت توسعه و نگهداری و همچنین ساختاری برای ساماندهی منابع اطلاعاتی و تشریح فعالیتهای معماری سازمانی فدرال ارائه می‌نماید. مدل دارای هشت مولفه اساسی است.
  • چارچوب معماری سازمانی (TEAF)خزانه داری آمریکا براساس معماری زکمن و چارچوب معماری FEAF درسال ۲۰۰۰ ارائه کرده‌است.

متدولوژی‌های معماری سازمانی[ویرایش]

در پاسخ به سؤال چگونگی انجام معماری، جواب یکتایی موجود نیست و گروهی معتقدند فرایند انجام معماری برای هر سازمانی باید متناسب با آن تطبیق داده شود، اکثر مؤلفان نیز در این زمینه به ارائهٔ راهنمایی‌های عمومی و گام‌های کلان پرداخته‌اند. معماری سازمانی شامل دو وضعیت موجود و مطلوب بوده و بنابراین فرایند معماری را باید چگونگی حرکت از وضع موجود به مطلوب دانست، البته تعریف و تعیین وضع موجود و مطلوب نیز می‌بایست جزو فرایند معماری به حساب آید.

  • متدولوژی مربوط به DODAF
  • فرایند ۶ مرحله‌ای DODAF شامل موارد زیر است:
  • تعیین مقصود استفاده از معماری
  • تعیین حوزه معماری
  • تعیین خصوصیاتی که باید مد نظر قرار گیرد
  • تعیین دیدگاه‌ها و محصولاتی که می‌بایست ایجاد شود
  • تعیین محصولات ضروری
  • استفاده از معماری بر اساس منظور مورد نظر

متدولوژی برنامه‌ریزی معماری سازمانی یا EAP آقای اسپیواک، متدولوژی پیشنهادی خود را اینگونه تعریف می‌کند: «برنامه ریزی معماری سازمانی، فرایندی است در جهت تعریف معماری برای استفاده اطلاعات به منظور پشتیبانی از حرفه و شامل یک برنامه برای اجرا است» آقای اسپیواک حوزه متدولوژی خود را دو سطر اول چارچوب زکمن معرفی نموده است. البته منظور ایشان، چارچوب اولیه زکمن است که شامل سه ستون بوده و در سال ۱۹۸۷ ارائه شد. وی طراحی سیستمها که در سطر سه می‌باشد را خارج از حوزه برنامه‌ریزی معماری خوانده است.

اسپیواک اجزاء متدولوژی خود را در ۴ لایه و شامل ۷ مؤلفه دسته‌بندی نموده است. این شکل به صورت یک کیک تولّد چهار طبقه می‌باشد. لایه‌ها و مؤلفه‌های این کیک به قرار زیر است:

  • لایهٔ اول: دارای یک مؤلفه با نام «برنامه ریزی آغازین» می‌باشد.
  • لایهٔ دوم: دارای دو مؤلفه به نام‌های «مدلسازی حرفه» و «سیستمها و تکنولوژی موجود» می‌باشد.
  • لایهٔ سوم: شامل سه مؤلفه به نام‌های «معماری داده»، «معماری سیستم» و «معماری تکنولوژی» می‌باشد.
  • لایهٔ چهارم: شامل یک مؤلفه به نام «برنامه گذار/ اجرایی» می‌باشد.

متدولوژی راهنمای کاربردی برای معماری سازمانی فدرال: این متد فرایندی را جهت توسعه معماری سازمانی مشخص می‌کند، گامها و اجزای این فرایند همپوشانی زیادی با متدولوژی اسپیواک دارند. به طور مشخص این متد مباحث بیشتری نسبت به متدولوژی EAP در حوزهٔ ابزارها، انتقال، بازاریابی معماری سازمانی و موضوعات مربوط به دولت و حکومت دارد. این فرایند شامل مراحل زیر است:

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

متدولوژی ADM چارچوب معماری سازمانی TOGAF جهت توسعهٔ معماری سازمانی اقدام به معرفی متدلوژی اختصاصی خود تحت عنوان «متد توسعه معماری» نمود. مراحل این متدولوژی به قرار ذیل است:

  • دیدگاه معماری
  • معماری کسب و کار
  • معماری سیستم‌های اطلاعاتی
  • معماری تکنولوژی
  • فرصت‌ها و راه حل‌ها
  • طرح مهاجرت (گذار)
  • اجرای دولت الکترونیک
  • مدیریت تغییرات معماری

متدولوژی Levis الکساندر لیوایز فرایندی هفت مرحله‌ای برای توسعهٔ معماری سازمانی بر مبنای چارچوب C4ISR ارائه نموده است که در دانشگاه George Mason تدریس می‌شود. مراحل این متدولوژی به قرار زیر است:

  • تعریف مسئله و جمع‌آوری اطلاعات دامنهٔ مسئله
  • تعیین مفهوم عملیاتی و نیازمندی‌ها
  • تعیین کارکردها و واحدهای سازمانی
  • تعیین عناصر عملیاتی و اطلاعاتی و نیز گِرِه‌های سیستمی
  • تعیین عناصِر سیستمی، خطوط مورد نیاز و کارکردها
  • تهیه مدل فعالیت، مدل دادهٔ منطقی و اختصاص وظایف
  • تهیه قوانین عملیاتی و واسط‌ها

مدل بلوغ معماری سازمانی[ویرایش]

مدل بلوغ معماری سازمانی مدل‌های مختلفی برای سنجش بلوغ معماری سازمانی منتشر شده که در اینجا یکی از آنها مورد بررسی قرار می‌گیرد، این مدل شامل ۵ فاز می‌باشد که خلاصه هر فاز در ادامه بررسی شده است.

فاز آغازین: در این مرحله فعالیت‌ها برروی جداسازی پروژه‌ها متمرکز است و اندکی نیز به استانداردهای حاکم در سازمان پرداخته می‌شود. به تکنولوژی‌ها به عنوان پشتیبانی کننده کسب و کار و راه‌های استفاده از آن توجه می‌شود. هنوز تیم معماری تشکیل نشده و مکانیسمی برای هدایت معماری وجود ندارد.

فاز طبقه‌بندی: در این مرحله تیم معماری تشکیل و مستقر شده و شالوده معماری مرجع بنا نهاده می‌شود. تمرکز اصلی در این مرحله بر طبقه‌بندی آنچه موجود است و چگونگی پشتیبانی آن توسط فناوری اطلاعات خواهد بود. تیم معماری با نگاه به چارچوب‌های مرجع مانند زکمن سعی می‌کند محصولات و مدل‌های معماری انتخاب شده (مدل‌ها هنوز ایجاد نشده‌اند) را طبقه‌بندی کند.

فاز برنامه کاری(blueprinting): در این مرحله معماری سازمانی از پروژه‌ای مبتنی بر فناوری اطلاعات به پروژه‌های استراتژیک با بودجه مشخص ترقی می‌کند. تیم معماری با جزئیات مناسب وضعیت موجود را توصیف و سپس وضعیت مطلوب را ترسیم می‌نماید. پروژه در سازمان کاملاً به رسمیت شناخته شده و تصمیمات حوزه‌های فناوری و استراتژیک بر اساس وابستگی‌های بین سازمانی اتخاذ خواهد شد. چارچوب معماری (مدل‌ها و روابط آن) که در فاز قبل انتخاب شده بود تصحیح می‌شود و اولین سرویس‌هایی که قابلیت استفاده در سطح سازمان (قابل استفاده مجدد) را دارند، ارائه و مورد استفاده قرار می‌گیرند اگرچه هنوز کامل و جامع نیستند.

فاز یکپارچه سازی: تمرکز این مرحله بر یکپارچه سازی فناوری اطلاعات در راستای کاهش هزینه تعامل میان سیستم‌ها و تکنولوژی‌های زیر ساختی است. در صورت تحقق این امر، فناوری اطلاعات قادر به پشتیبانی از تغییرات حرفه خواهد بود و به نوعی فناوری و حرفه همراستا می‌شوند. از نتایج این مرحله کاهش پیچیدگی فناوری اطلاعات به وسیله تعریف سرویس‌های مشترک جدید است، البته این بدین معنا نیست که تمامی سیستم‌های موروثی از دور خارج شده و سیستم‌های جدید راه اندازی شود. ابزارهای معماری سازمانی ارتقاء می آبند تا قابلیت پشتیبانی زمان اجرای(runtime) معماری را داشته باشند.

فاز بهینه‌سازی: در این مرحله معماری سازمانی اجرا شده و همه امکانات و ابزارهای لازم برای مدیریت حرفه و فناوری مهیا است، لذا نوبت به بهینه‌سازی فرایندها می‌رسد. فرایندهای کاری بهینه شده‌اند و چابکی در حرفه و فناوری محقق شده است. معماری مطلوب از حالت طرح به واقعیت پیوسته و دیده بانی(monitoring) بصورت خودکار و ماشینی درآمده است. در این مرحله تمرکز بر روی بهینه‌سازی است و کلیه راهیافت‌ها و تکنولوژی‌هایی که قادر به بهبود شاخص بازگشت سرمایه در سازمان باشند، به سرعت پیاده‌سازی می‌شوند.

ارزیابی متدلوژی‌های معماری سازمانی[ویرایش]

منابع[ویرایش]

  • http://www.enterprisearchitecture.ir : منابع منتشره کمیته ملی معماری اطلاعات در شورایعالی اطلاع‌رسانی
  • http://soea.sbu.ac.ir : آزمایشگاه معماری سازمانی سرویس گرا
  • http://isa.sbu.ac.ir هسته پژوهشی معماری سیستم‌های اطلاعاتی، دانشگاه شهید بهشتی
  • “Enterprise Architecture Planning, Developing a Blueprint for Data, Application, and Technology”, By Steven H. Speawak, Steven C.Hill,John Wiley & Sons.
  • A framework for information systems architecture, by john A Zachman, IBM System Journal, VOL 38, NOS۲&۳, ۱۹۹۹
  • Federal Enterprise Architecture Framwork, Version 1.1, September1999, Published by the Chief Information Officers Council of (USA)
  • C4ISR Architecture Framwork,Version 2.0,December 1997,Published by DOD Architectures Working Group(AWG)