فهرست مطالب :

فصل اول-مقایسه “مدل های معماری سازمانی” با “فراورده های توسعه نرم افزار” – جان زاکمن

۱-۱ مقایسه “مدل های معماری سازمانی” با “فراورده های توسعه نرم افزار” – جان زکمن

۱-۲ خلاصه بحث

۱-۳ نگاهی به گذشته و نگاهی به آینده – جان زکمن

۱-۳-۱ الف: معماری مقابل فرهنگ بود

۱-۳-۲ ب: معماری به عنوان یک موضوع حیاتی درک نشد

۱-۳-۳ پ: نمی دانستیم واقعا چگونه معماری را پیاده سازی کنیم

۱-۳-۴ ت: معماری نیاز به کار واقعی دارد

۱-۴ خلاصه از گذشته

۱-۵ نگاهی به آینده

۱-۵-۱ الف: معماری فرهنگ جدید است

۱-۵-۲ ب: معماری یک موضوع حیاتی شده است

۱-۵-۳ پ: می دانیم چگونه معماری را پیاده سازی کنیم

۱-۵-۴ ت: ابزارها برای کار پیاده سازی معماری فراهم شده

۱-۶ شناخت تفصیلی چارچوب زکمن: جنبه های چارچوب

فصل دوم -آشنایی با متدولوژیهای قدرتمند سیستمهای اطلاعاتی -مدل زاکمن

۲-۱ مقدمه

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

۲-۳ چارچوب

۲-۳-۱ تشریح چارچوب زاکمن

۲-۳-۲ کاملترین چارچوب نظری

۲-۴ جنبه های مختلف هر سیستم

۲-۵ نماهای مختلف هر سیستم

۲-۶ مدل سازمان یا کسب و کار

۲-۶-۱ مدل سیستمی

۲-۶-۲ مدل فناوری

۲-۶-۳ مدل توصیفی

۲-۷ سازمان در حال کار

۲-۸ مزایای چارچوب زاکمن در مقایسه با دیگر چارچوبها

۲-۹ مشخصات کلی چارچوب زاکمن

۲-۱۰ تفاوت محصولات معماری سازمانی با روش‌های دیگر

۲-۱۱ کاربرد معماری سازمانی

۲-۱۲ مجموعه مستندات معماری سازمانی (زمان انجام)

۲-۱۳متدولوژی‌های معماری سازمانی

۲-۱۴ مدل بلوغ معماری سازمانی

۲-۱۰ نتیجه گیری

منابع

مقاله معماری سازمانی و متدلوژیهای توسعه نرم افزار زکمن

چکیده :

جان زکمن یکی از پیشگامان معماری سیستم های اطلاعاتی است که پیشتر در شرکت IBM مشغول بود و هم اکنون هم به عنوان استراتژیست فناوری اطلاعات و معماری سازمانی و مدرس معماری اطلاعات در شرکت زیفا (Zifa) فعالیت می کند. زاکمن با ارائه یک روش و الگوی جامع در زمینه معماری اطلاعات آن را تبدیل به یک چارچوب معماری اطلاعات کرد، که در این چارچوب یک سازمان از زوایای مختلف و در تمامی سطوح مورد بررسی و تحلیل قرار می گیرد. زاکمن معتقد به تحلیل سازمان بر مبنای یک چارچوب معماری است و می گوید: تزریق فناوری اطلاعات به یک سازمان بدون به کارگیری چارچوب معماری، سازمان را در آینده با هزینه های متعدد نگهداری و توسعه سیستم ها، عدم کارایی در راستای ماموریت سازمان و عدم تطابق پذیری با تکنولوژی های روز و هزینه های سنگین تبدیل سیستم ها و داده ها روبه رو می سازد.
در دهه اخیر، فعالیتهای زیادی در رابطه با معماری سازمانی و نیز روشها و استانداردهای آن در سطح دنیا صورت گرفته است. معماری سازمانی به عنوان راه حلی جامع و راهبردی در مدیریت توسعه سیستم های اطلاعاتی از دهه ۱۹۹۰ میلادی با حرکت فزاینده ای مورد توجه قرار گرفته است؛ به گونه ای که در حال حاضر، اغلب کشورهای دنیا، معماری سازمانی را به عنوان روشی استاندارد در شناخت و باز مهندسی سازمان شناخته و مورد استفاده قرار می دهند. در معماری سازمانی برای طراحی آن و طبقه بندی اطلاعات و اجرا نیاز به چارچوب است که موضوع بحث مقاله قرار دارد.

کلمات کلیدی: زاکمن-نرم افزار زکمن-معماری سازمانی – روش زکمن-تحلیل سازمان-مدیریت توسعه سازمان

۱-۱ مقایسه “مدل های معماری سازمانی” با “فراورده های توسعه نرم افزار” – جان زکمن

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

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

مزایای این مدلها سبب می شود به این سمت برویم که تمام این مدلها (چارچوب زکمن) را بصورت دقیق و صریح تولید کنیم، چرا که این مدلها می توانند پیچیدگی و تغییرات سازمانهای بزرگ امروزی را مهار کنند. البته در حال حاضر، تمام این مدلها ممکن است تولید نشوند. توجه به این نکته ضروری است که این مدلها باید توصیفی از “عملکرد کل سازمان” باشند و نه مربوط به یک “پیاده سازی” خاص. به همین دلیل است که این مدلها را “شالوده” سازمان گویند چراکه از ترکیب و الحاق انها می توان برای هر کاربردی (پیاده سازی) استفاده کرد.

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

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

بهتر است قبل از ادامه بحث، مفهوم “استفاده مجدد” را روشن کنیم و ابهام آن را بر طرف کنیم. منظور از قابلیت استفاده مجدد یک شیء، استعمال آن در “زمینه” و “حوضه” دیگر نیست، یعنی قرار نیست فراورده های قابل استفاده مجدد، در سازمانها و کارکردهای مختلف استفاده شوند، بلکه فقط در همان سازمان و همان کارکرد مربوط می توانند قابل استفاده مجدد باشند. برای مثال، یک کارگاه تولید کاربراتور را در نظر بگیرید، آیا می توان انتظار داشت که محصولات این کارگاه برای انواع مدلهای ماشین فورد یا “فیات” یا … قابل استفاده باشد؟ مسلما نه! کاربراتوری که شما می سازید فقط مناسب یک نوع موتور می باشد، پس “استفاده مجدد” چه مفهومی دارد؟ پاسخ این است که “قابلیت استفاده مجدد” مربوط می شود به چگونگی ساخت کاربراتور، اگر کاربراتور از سوار کردن(الحاق) عناصر پایه ساخته شود، تغییری مختصر در هر کدام از عناصر پایه، می تواند کاربراتور را برای نوع موتور جدیدی قابل استفاده کند بدون انکه کل خط تولید دچار تغییر و تحول شود، اما اگر کاربراتور بصورت یکدست ساخته شود تغییری اندک در آن مساوی با ساخت مجدد قالب(تولید مجدد) خواهد بود.

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

اما چالش اصلی مربوط به این موضوع است که چگونه می توان فهمید یک مدل مشخص، از مدلهای پایه ای معماری سازمانی است یا یک مدل تک منظوره برای یک پیاده سازی خاص.

اولین تست، تطبیق این مدل با سلولهای چارچوب زکمن است. باید ببینیم آیا این مدل دقیقا منطبق بر یکی از سلولهای چارچوب است یا که از ترکیب چند سلول به دست امده است، به عبارت دیگر آیا مدل مورد نظر یک متغییر دارد(هر سلول یک متغییر است) یا چند متغییر؟

مدل تک متغییر به یکی از اشکال زیر است:

مدلی از اشیاء به صورت: شیء- رابطه – شیء (مدل معنائی)

مدلی از فرایندها به صورت: ورودی – فرایند – خروجی (مدل تبدیل)

مدلی از مکانها به صورت: گره – مسیر – گره (مدل شبکه یا اتصال)

مدلی از اشخاص به صورت: شخص – مسئولیت – شخص (مدل جریان کار)

مدلی از رخدادهای زمانی به صورت : رخداد – سیکل زمانی- رخداد (مدل پویا)

مدلی از انگیزه به صورت: اهداف – روش ها- اهداف (مدل قوانین حرفه)

یک مدل ترکیبی(با چند متغییر) از چندین مدل پایه (تک متغییر) تشکیل شده، برای مثال یک مدل ترکیبی می تواند شامل اطلاعاتی باشد که توسط مسیرهایی به مکان هائی منتقل می شود و فرایندهائی روی ان اعمال می شود تا … . پس اگر مدل مفروض، چند متغییر داشت، به طور قطع مربوط به فراورده های فرایند توسعه نرم افزار برای یک پیاده سازی خاص بوده است.

تست بعدی مربوط می شود به عناصر سازنده مدل است. باید چک کنیم که آیا عناصر سازنده و اولیه مدل ما از سلولهای چارچوب بوده اند یا نه؟ یک مثال متداول مدلی است شامل اطلاعات، تعاریف و روابط بین آنها و فرایندی که از این اطلاعات استفاده می کند. حال باید تست کنیم که “اطلاعات” مدل از یکی از مدلهای پایه چارچوب استخراج شده یا که مربوط به اطلاعات یک پیاده سازی خاص است که با فرایندهای دخیل، ترکیب شده؟

توجه کنید که فراورده های توسعه نرم افزار نه تنها زائد نیستند که بسیار مفید و ضروری هستند، اما جزو مدلهای پایه نمی باشند. در عوض این فراورده ها اگر مشتق از مدلهای پایه سازمان باشند، دارای مزایای زیادی هستند که اشاره خواهد شد. در عوض اگر فراورده ها مشتق شده نباشند و بصورت انفرادی برای هر کارکرد(پیاده سازی) خاص تهیه شوند مشکلات زیر به وجودمی اید:

انها تا زمانی مفید هستند که تغییری اتفاق نیفتد، به محض تغییر در فرایندها(یا اطلاعات یا اشخاص یا ..) باید فراورده را دور انداخته و نمونه جدیدی را منطبق با وضع جدید از نو “تولید” کنیم.

فراورده ها ممکن است شما را گمراه کنند! چرا که گاهی با مدل های پایه اشتباه می شوند، در حالیکه فراورده های توسه نرم افزار، قابل استفاده مجدد نیستند، تمام جنبه ها و حوزه های سازمان را پوشش نمی دهند و خلاصه عنصر پایه برای مشتق شدن دیگر مدلها نیستند.

پیچیده هستند، چراکه دارای تعدادی شیء و رابطه هستند بدون اینکه عناصر اولیه اشیاء و روابط مشخص باشد.

دید شما را محدود می کنند، مدل هایی هستند که می توانند دارای جایگزین های بهتری نیز باشند، ولی چون مدلهای پایه موجود نیستند، حدس ترکیبات ممکن از انها ممکن نیست.

تست آخر اینکه آیا مجموع مدل های مفروض تمام جنبه ها و حوزه های سازمان را در بر می گیرد؟ اگر مدلهای معماری برای محدوده ای از سازمان تهیه شده باشند، یا اگر بعد از ساخت آنها محدوده سازمان گسترش یابد، آنگاه این مدل ها فقط در محدوده مذکور قابل استفاده مجدد می باشند. مفهوم محدوده سازمان بسیار مهم است چرا که چالش اصلی ما مربوط به “سازمان” است نه “سیستم ها”. پس مشخص نمودن حوزه و محدوده سازمان و ساخت مدلهای پایه براساس دید سرتاسری به سازمان باعث بهره وری در زمان و هزینه شده، قابلیت استفاده مجدد و تعامل پذیری را تضمین می کند. هر سازمان می بایست با ایجاد معماری سازمانی به تولید تمامی مدل های پایه که دیدی سرتاسری و همه جانبه از سازمان ارائه می کنند، اقدام کند. اما مشکل اینجاست که مدیران زمانی به اهمیت این موضوع پی می برند که با مشکلی برخورد کرده و نیاز فوری و سریع به مدلهای پایه دارند، اما مدلهای پایه موجود نیستند و تهیه سریع انها هم ممکن نیست.

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

۲-۲ • معماری سازمانی

معماری سازمانی یک نقشه سازمانی است که ساختار مأموریت و اطلاعات موردنیاز سازمان و فناوریهای لازم برای پشتیبانی از آنها را تشریح کرده، فرایند گذار برای پیاده سازی این فناوریها را تعریف می کند (قاسم نژاد مقدم، ۱۳۸۶).

۲-۳ • چارچوب

جان زاکمن، چارچوب معماری سازمانی را چنین تعریف می کند: چارچوب معماری سازمان یک طرح طبقه بندی شده دو بعدی است که یک نمایش توصیفی را از سازمان بیان می کند (Zachman, 1987).

در تشریح مفهوم چارچوب آمده است که، یک چارچوب معماری:

• ابزاری است که می تواند برای توسعه طیفی از معماریهای مختلف به کار رود.
• باید روشی را برای طراحی سیستم های اطلاعاتی و روش اتصال آنها به یکدیگر، ارائه کند.
• باید دارای مجموعه ای از ابزارها باشد که فرهنگ و زبان مشترک را فراهم سازد.
• باید شامل فهرستی از استانداردها باشد که برای توسعه واحدهای ساختاری مورد استفاده قرار گیرد (استادزاده، ۲۳، ۱۳۸۴).

برخی از چارچوبهای رایج، عبارتند از: FEAF، زاکمن، TEAF، DoDAF، TOGAF، C4ISR و… درحال حاضر تعداد محدودی چارچوب معماری در سطح جهان مورد استفاده قرار می گیرند که هر یک با توجه به منشاء ظهورشان مناسب معماری سازمانهای خاصی هستند.

۲-۳-۱ • تشریح چارچوب زاکمن

جان زاکمن یکی از پیشگامان معماری سیستم های اطلاعاتی است که پیشتر در شرکت IBM مشغول بود و هم اکنون هم به عنوان استراتژیست فناوری اطلاعات و معماری سازمانی و مدرس معماری اطلاعات در شرکت زیفا (Zifa) فعالیت می کند.

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

زاکمن معتقد به تحلیل سازمان بر مبنای یک چارچوب معماری است و می گوید: تزریق فناوری اطلاعات به یک سازمان بدون به کارگیری چارچوب معماری، سازمان را در آینده با هزینه های متعدد نگهداری و توسعه سیستم ها، عدم کارایی در راستای ماموریت سازمان و عدم تطابق پذیری با تکنولوژی های روز و هزینه های سنگین تبدیل سیستم ها و داده ها روبه رو می سازد (عباسی و همکاران، ۲۸،۱۳۸۴).

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

جان زاکمن در سال ۱۹۹۲ در مقاله دیگر خود با افزودن سه جنبه دیگر( افراد، زمان و انگیزه ) کار خود را تکمیل کرده، آن را به عنوان رویکردی نوین در معماری سازمانی ارائه کرد.

چارچوب زاکمن، چارچوبی است برای معماری سازمانی که یک ساختار منطقی ایجاد می کند. چارچوب زاکمن از دو بعد اصلی و پایه تشکیل شده است.

بعد اول (ستونها) بیانگر جنبه ها (Focus) (چه چیز؟ چگونه؟ کجا؟ چه کسی؟ کی و چرا؟) است (توصیفات متفاوت از یک محصول از جنبه های مختلف)، و بعد دوم (سطرها) مبین دیدگاه ذینفعان در سازمان است (برنامه ریز، مالک یا دارنده، طراح، سازنده، پیمانکار و کاربر) . به عبارتی دیگر، این چارچوب یک ماتریس دو بعدی را ارائه می دهد.

۲-۳-۲ • کاملترین چارچوب نظری

چارچوب زاکمن از نظر تئوری یکی از کاملترین چارچوبهای معماری موجود است . این چارچوب با پوشش دادن تمامی جنبه ها و دیدگاههای ممکن در رابطه با سیستمهای اطلاعاتی یک سازمان، به ساختاری کاملاً نرمال در این رابطه دست پیدا می کند.

مبانی و مفاهیم مطرح در این چارچوب بسیاری از چارچوبهای معماری دیگر را تحت تاثیر قرار داده، یکی از مطرح ترین چارچوبهای معماری حال حاضر به حساب می آید. (صمدی، ۱۳۸۴: ۶۸).

چارچوب زاکمن معروفترین قالب برای تدوین معماری سازمانی است و به عنوان یکی از متدولوژی های قدرتمند برای توسعه سیستم های اطلاعاتی مطرح است. برخی از شرکتها نیز بر اساس چارچوب زاکمن یک متدولوژی پیشنهاد کرده اند.

۲-۴ • جنبه های مختلف هر سیستم

داده(چه چیز؟): هر یک از سطرهای این ستون به درک و پردازش داده*های سازمانی می پردازند. جزییات مدل سازی همراه با پایین رفتن در سطرها، افزایش می یابد.

چه چیز در سازمان جریان دارد؟ چه چیز برای سازمان مهم ، حیاتی و گلوگاهی است؟ برای مثال: جریان کاری، اطلاعات، موجودیت های کسب و کار، محصولات، مواد اولیه، دستورکارها، بخشنامه ها، فرمهای سفارش، داده ها و ارقام.

کارکرد (چگونه؟): سطرهای موجود در ستون کارکرد، فرایند ترجمه مأموریت سازمان به عملیات جزئی تر لازمه آن را، تشریح می کنند.

روندهای کاری، در هر سطح چگونه انجام می شود؟ کدام ماموریتهای سازمان مهم است؟ این مأموریتها چگونه انجام می شوند؟ برای مثال: وظایف، مأموریتها، فرآیندها، جریانهای کاری، حوزه های مسئولیت و سیستم های کاربردی در این خانه ها می گنجد.

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

افراد (چه کسی؟): ستون چهارم شرح می دهد که چه کسانی در حرفه درگیر هستند. این ستون به ویژه از نظر امنیت، دارای اهمیت است.

چه کسی و یا کسانی در این رویدادها نقش دارند؟ بازیگران چه کسانی هستند؟ مدیران، کارکنان، نقشهای سازمانی، نقشهای فرآیندی، نقشهای سیستمی، واسط های کاربر، هر کدام می توانند به نوبه خود بازیگر اصلی باشند.

زمان (چه وقت؟): ستون پنجم، تأثیر زمان را بر سازمان، شرح می دهد. فهرستی از رخدادها و زمانهای تاثیرگذار، زمانبندی کسب و کار، نمودارهای توالی و ترتیب عملیات، ترسیم توالی عملیات میان مؤلفه ها و زمان بندی واقعی کار در سازمان، ترتیب افزایش جزئی نگری در این ستون را نشان می دهند.

انگیزه (چرا؟): این ستون بر ترجمه هدفها و راهبردهای حرفه به نتایج و ابزارهای خاص متمرکز است و می تواند برای دربرگیری همه محدودیتهایی که بر تلاشهای سازمانی اعمال می شوند، گسترش یابد.

باید دانست که ستونها، مجزا نیستند بلکه اجزای منطقی سازنده آنها دارای ارتباطات معنایی با هم هستند (فتح اللهی، ۱۳۸۴).

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

بنابراین با تقاطع این دو مؤلفه (جنبه ها و نماها) است که می توان به مدل سازی جامع معماری سازمان پرداخت. این مدل سازی باید بتواند تمام موارد و مناسب پیدا و پنهان سازمان را مورد موشکافی قرار داده، در سطوح مختلف این کار را انجام دهد.

۲-۵ • نماهای مختلف هر سیستم

حوزه (Scope ): منظور اصلی از سازمان را تصویر می کند. این سطر، دیدگاه برنامه ریز یا سرمایه گذاری است که قصد دارد، هزینه و عملکرد کسب وکار یا سازمان مورد نظر خود را تخمین بزند. اعضای هیئت مدیره، سهامداران یا اعضای هیئت امنا، نمونه هایی از افراد دارای این دیدگاه هستند. تقریبا همه اطلاعاتی که در این سطر می آیند، به صورت متن آزاد است.

۲-۶ • مدل سازمان یا کسب و کار:

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

۲-۶-۱ • مدل سیستمی:

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

۲-۶-۲ • مدل فناوری :

برای آنکه معماری تحقق یابد، نیاز دارد توسط فناوری پشتیبانی شود. در این سطر است که استانداردهای پیاده سازی سیستم ها، برگزیده می شوند.

۲-۶-۳ • مدل توصیفی:

توسط کسانی تهیه می شود که به عنوان پیمانکار در اجرای سیستم های اطلاعاتی پیش بینی شده در سطر پیش، فعالیت می کنند. در اینجا باید معماری سیستم های اطلاعاتی، متناسب با فناوری که از سوی شرکت مجری برگزیده شده، تبدیل به طراحی سطح پایین شود.

این سطر، به معنای کامل آن به مهندسی نرم افزار مربوط می شود و افراد سهیم در آن همان کسانی هستند که در نظر عامه مردم به آنها برنامه نویس گفته می شود (اگرچه باید دانست چنین پیمانکاری باید گروهی مرکب از همه کارشناسان مهندسی نرم افزار اعم از تحلیلگر سیستم، طراح، معمار، برنامه نویس، آزمایشگر و … داشته باشد).

۲-۷ • سازمان در حال کار:

البته این یک مدل نیست. این سطر در بسیاری از روشهای انجام معماری دیده نشده است، چرا که از راه زبان و نمودار قابل بیان نیست. این سطر نشان دهنده دیدگاه کاربران سازمان است.

بنابراین با تقاطع این دو مؤلفه، یعنی جنبه ها و نماها است که می توان به مدل سازی جامع معماری سازمان پرداخت. این مدل سازی باید بتواند تمام جنبه های پیدا و نهان سازمان را مورد موشکافی قرار داده، در سطوح مختلف مدل سازی انجام شود. بنابراین، شکل کامل چارچوب معماری سازمان شامل شش ستون عمودی به عنوان مؤلفه های جنبه ای و شش سطر افقی به عنوان مؤلفه های نمایی سازمان است.

۲-۸ • مزایای چارچوب زاکمن در مقایسه با دیگر چارچوبها

در یک دسته بندی صریح می توان گفت چارچوب زاکمن نسبت به همه چارچوبهای دیگر، دست کم دارای سه مزیت عمده است:

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

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

فایل کامل این تحقیق ۴۶ صفحه بصورت ورد WORD می باشد.
در تمامی ساعات شبانه روز >> پرداخت آنلاین و دانلود آنلاین پروژه