ارزیابی آمادگی تغییر یا Change Readiness Assessment – CRA

هدف ارزیابی آمادگی تغییر این هستش که میاد با یه سری فعالیت ها آمادگی سازمان رو واسه توانایی پذیرش تغییرات و نگهداشت سود رو می سنجه.

ارزیابی آمادگی تغییر سه تا مرحله داره :

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

بعدش اینکه ارزیابی تو همه سطوح مختلف سیستم انجام میشه :

  • سطح سازمانی
  • سطح دپارتمان ها / گروه های مختلف
  • سطح شخصی

اما رویکرد رسیدن به ارزیابی آمادگی تغییر به چه شکل هستش ؟ بعبارت دیگه چطور می تونیم تو سیستمی که داریم Change Readiness Assessment رو پیاده کنیم ؟!

تو این شکل که توسط نرم افزار Word طراحی کردم میشه روند مراحل ارزیابی رو دید (خواهشا اگر کپی می کنید منبع رو ذکر کنید چون این مطلب احتمال داره بعدها بروز بشه و مطالب جدیدتری بهش اضافه بشه)

 

مراح ارزیابی آمادگی تغییرات
مراح ارزیابی آمادگی تغییرات

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

در واقع چهار مرحله رو ما پیش رو داریم :

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

دید ۱ + ۴ در نگارش سند معماری نرم افزار Software Architecture Document Based on 4 + 1 View Model

این مدل سازماندهی تفصیلی معماری نرم افزار را در پنج دید مجزا ولی با همبستگی توصیف می کند. به جهت اینکه پیدایش هر امری در نتیجه یک فلسفه  بوده است چرایی پیدایش این مدل را بررسی می کنیم ! علت یک چیز است : درمان مشکل دید طراحی و مدل سازی نرم افزار. پنج بعد دیداری این مدل به صورت همروند می باشند . هر یک از ۵ دید به یک گروه از ذینفعان پروژه مربوط می شود.

دید 1 + 4 در معماری نرم افزار
دید ۱ + ۴ در معماری نرم افزار

۱ ) دید منطقی : نحوه نمایش این مدل را می توان در قالب ERD نمایش داد. نیازمندی های وظیفه مندی ، طراح دید انتزاعی دارد و این انتزاع ها در قالب Object بروز میکند. عملیات اصلی در این دید فرآیند Decomposition است که در نتیجه انتزاع و تجرید رخ می دهد.

مهم : تحلیل گر و طراح اینجا هستند و سرویس ها به کاربر نهایی ارائه می شوند.

۲ ) دید فرآیندی : به تفصیل، جنبه های طراحی همروند و قابلیت انطباق نرم افزار را بررسی می کند. نیازمندی های غیر وظیفه مندی مانند دسترسی پذیری سیستم.

مهم : یکپارچه سازی سیستم در اینجا رخ می دهد + قابلیت تحمل خطا + همروندی فرآیندها

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

مهم : برنامه نویسان در اینجا حضور دارند و مدیریت نرم افزاری در این دید صورت میگیرد.

۴ ) دید فیزیکی : تحویل و نصب نرم افزار را شاهد هستیم و شروع ارتباط اینجا رخ می دهد. نیازمندی های غیر وظیفه مندی هم در اینجا حاضر هستند مثل مقیاس پذیری .

مهم : مهندسی سیستم اینجا رخ می دهد. کَف و توپولوژی سیستم تعیین می شود.

لایه های معماری سازمانی سرویس گرا : سرویس های فرآیندی، ترکیبی و اتمیک

اکثریت قریب به اتفاق لایه های معماری سازمانی سرویس گرا به سه دسته تقسیم می شوند :

  • لایه کسب و کار
  • لایه سرویس
  • لایه نرم افزار و سیستم های اطلاعاتی

در این میان خود لایه سرویس به سه دسته مجزی تقسیم می شود :

  • سرویس های فرآیندی (هم نواساز)
  • سرویس های ترکیبی
  • سرویس های اتمیک (منحصر بفرد)

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

  • نقدی
  • واریز به کارت اعتباری
  • در یک چک

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

اما مزیت این سرویس های هم نواسازی در چیست ؟

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

 

لایه سرویس های ترکیبی : شاهرگ معماری سرویس گرا به حساب می آیند و مولفه های حیاتی کسب و کار سیستم را شامل می شوند. دو تفاوت عمده این لایه با لایه هم نواساز در این است که :

  • سرویس های ترکیبی بخش حیاتی منطق کسب و کار را مدلسازی می کنند.
  • ذینفعان این لایه کارشناسان سازمان هستند و نه مشتریان و کاربران خارجی.
  • منطق حاکم بر سرویس ها از جنس ادبیات و اصول تخصصی است بر خلاف سرویس های هم نواساز که ادبیات و اصولشان برای مشتریان قابل فهم بود.

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

برای استخراج منطق این لایه دو راه داریم :

  • مدل فرآیندی سازمان
  • مصاحبه با متبحران سازمانی
  • مستندات قابل قبول و ۱۰۰ درصد تایید شده

نکته دیگر اینکه سرویس های ترکیبی به دو دسته وظیفه محور و موجودیت محور تقسیم می شوند.

وظیفه محور ها : منطق و اصول کسب و کار را ارائه می کنند.

موجودیت محورها : اطلاعات، مشخصات و عملیات مربوط به یک Entity در سازمان را ارائه می کنند.

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

  • مجزا
  • بر بستر نرم افزاهای موروثی یا Legacy Softwares

منطق نگهداری شده توسط این سرویس ها از دو بخش تشکیل می شود :

  • کسب و کار : مثلا اینکه محاسبه هزینه فیش آبونمان خانگی دارای چه پارامترها،فیلدها یا قید و شرطی است.
  • فناوری : قیود موجود در ارتباط با نحوه ذخیره سازی دیتا در پایگاه های داده و الگوی های ذخیره سازی و …

موارد ارتباط سرویس های اتمیک با Legacy Software ها از این قبیل است :

  • ERP
  • پایگاه های دادده
  • برنامه های پکیج شده
  • و …

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

طرح مدیریت ریسک – Risk Management Plan

ما می توانیم به منظور طرح مدیریت ریسک – Risk Management Plan از طرح RMMM به منظور کاهش ریسک، اجتناب از ریسک و نظارت  و کنترل ریسک استفاده کنیم. در واقع RMMM طرح تسکین پایش و مدیریت ریسک هست که بایستی از قبل آماده باشه. اینو رو هم یادتون باشه ما دو نوع ریسک داریم : الف. غیر فعال ب. فعال

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

این قطعه کد رو هم نگاه کنیم خالی از لطف نیست (نیست که من قبلنا PHP کد میزدم 🙂 ضمنا این کد در سطح وب موجود است.

<code>

if (Risk is available) then {Risk Managment || Risk Monitoring} Else

{Risk Monitoring}

 

</code>

بطور کلی مدیریت ریسک شامل ۶ مرحله هست :

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

ضمنا ما ۳ نوع ریسک داریم :

  • ریسک پروژه
  • ریسک محصول
  • ریسک کاری

بطور خلاصه RMMM شامل سه مرحله میشه :

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

اجازه بدید با یک مثال کار رو پیش ببریم : ” در طول پروژه استخراج وضع موجود سازمان جهاد دانشگاهی امکان دارد برخی کارمندان از تیم جدا بشن و به قسمت های دیگه پروژه منتقل بشن ”  خوب این شد بخش پالایش ریسک. حالا باید اجتناب از ریسک داشته باشیم، پس باید چه کار کنیم ؟ مشخصه باید وظایف و تسک های هر کدوم از اعضای تیم رو مشخص کنیم و پروژه ای که قراره بهش نیل پیدا کنیم رو روشن کنیم. حالا اگر ریسک اتفاق افتاد و جدایی رخ داد چی کنیم ؟ باید مدیریت انجام بدیم، اینجاست که Management ورود میکنه و ما میایم نیروهای جدید و ماهر و متخصص رو به جای نیروهای قبلی جایگزین می کنیم. (Replacement) پس جواب یک سوال اینجا مشخص میشه و اون اینکه مدیریت پروژه توسط مدیر پروژه (Project Manager) صورت میگیره.

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

  • ریسک ابتدایی
  • ریسک های باقیمانده پس از انجام اقدامات به منظور کاهش ریسک

طبقه بندی ریسک : 

  • ریسک ها در کلیه فازهای متدولوژی ADM حاضرند.
  • اما چرا ریسک ها را طبقه بندی کنیم ؟ به منظور کاهش ریسک ها طبقه بندی بسیار موثر است.
  • یکی از راه های طبقه بندی ریسک، اندازه گیری تاثیری است که بر سازمان می گذارد.

شناسایی ریسک : 

چطور شناسایی کنیم ؟

  • ارزیابی بلوغ سازمان در فاز گذار
  • ارزیابی آمادگی سازمان در فاز گذار
  • مستند سازی ریسک (Risk Documentation)

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

  • طبقه بندی ریسک با توجه به دو عامل :
    • تاثیر ریسک در سازمان
    • فرکانس تکرار در سازمان
  • ارزیابی میزان تاثیر با توحه به معیارها (ستون جدول) و نرخ تکرار (سطر جدول)
  • معیار + نرخ تکرار :
    • ریسک بسیار جدی (Extremely High Risk)
    • ریسک جدی (High Risk)
    • ریسک قابل کنترل (Moderate Risk)
    • ریسک پایین (Low Risk)
  • که به ترتیب با E , H , M , L شناخته می شوند.

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

قبل از بحث و بررسی دو رویکرد عمودی و رویکرد افقی در توسعه فناوری اطلاعات سازمان باید این نکته را ذکر کنیم که معماری سازمانی (Enterprise Architecture) یک رویکرد افقی و مبتنی بر فرآیند است و همین باعث شده است که انعطاف پذیری (Flexibility) در سازمان به حد اعلای خود برسد.

در رویکرد عمودی موارد ذیل لحاظ می شود :

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

اما رویکرد عمودی دچار مشکلاتی نیز هست که با هم بررسی می کنیم :

  • افزونگی اطلاعات (مشکل حیاتی)
  • ذینفعان و کارمندان و مشتریان از سیستم های اطلاعاتی ایجاد شده راضی نیستند.
  • ایجاد سیستم های اطلاعاتی اما بصورت تکه تکه ای (جزیره ای)
  • عدم انعطاف پذیری در برابر تغییرات (No Flexibility toward Changes)
    • چرا که کسب و کار از محدویت های فناوری اطلاعات تاثیر می پذیرد.
  • افزایش هزینه نگهداری سیستم ها (Cost Increase)
  • افزایش زمان نگهداری سیستم ها (Time Increase)
  • عدم وجود قدرت برای برقراری رقابت به دلیل وجود سیستم های اطلاعاتی منفرد بدون قابلیت تعامل با هم (Lack of Interaction)

در رویکرد افقی موارد ذیل لحاظ می شود :

  • تولید و توسعه فناوری اطلاعات بر اساس برنامه ای جامع و مدون می بایست صورت گیرد.
  • سازمان برای به خدمت گرفتن فناوری اطلاعات باید راهبردهای مشخص در تطبیق با راهبردهای سازمانی داشته باشد.
  • تاثیر تغییر فناوری بر کسب و کار و کسب و کار بر فناوری می بایست از قبل پیش بینی شده باشد. (Predict)
  • سیستم های اطلاعاتی (Information Systems) باید در حمایت و پشتیبانی از فرآیند های کسب و کار (Business Process) ایجاد شوند و نه حمایت از وظایف واحدهای سازمانی

اما روش های توسعه افقی در سازمان جیست ؟ 

  • روش های مهندسی نرم افزار : این روش های در تولید و توسعه نرم افزار استفاده می شوند. بعنوان مثال استفاده از متدولوژی RUP یا XP به منظور ساخت نرم افزار
  • برنامه جامع فناوری اطلاعات به منظور تولید و نگهداری و پشتیبانی سیستم های اطلاعاتی که مبتنی بر راهبردها و ماموریت سازمان است و شامل عناصر ذیل است :
    • طرح جامع ارتباطات سیستم ها
    • فهرست سیستم ها و ساب سیستم ها
    • فهرست پروژه ها و RFP ها
    • برنامه اولویت زمان بندی اجرای پروژه ها
  • و معماری سازمانی

مدل ۵ لایه ای NIST

این مدل معماری از ۵ لایه تشکیل شده که اجزی مختلف معماری سازمان رو نمایش میده.

  • لایه معماری کسب و کار
  • لایه معماری اطلاعاتی
  • لایه معماری سیستم های اطلاعاتی
  • لایه معماری دیتا
  • لایه معماری فناوری (سخت افزاری نرم افزاری و ارتباطاتی)

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

NIST
NIST

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

لایه معماری کاری دو تا نقشه داره :

  • نقشه وضع موجود سازمان
  • نقشه وضع مطلوب سازمان

لایه معماری کسب و کار شامل مستندات جامعی از موارد ذیل هست :

  • ساختار سازمان
  • ماموریت های سازمان
  • اهداف کاری سازمان
  • وظایف کاری سازمان
  • فرآیندهای سازمان
  • فعالیت های سازمان
  •  اطلاعات سازمان

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

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

این لایه به این سوالات پاسخ می دهد :

  • چه اطلاعاتی در سازمان تولید می شود ؟
  • چه کسانی به این اطلاعات Access دارند ؟
  • چگونه این اطلاعات برای تصمیم گیری و انجام برنامه ها و فعالیت های کاری روزمره استفاده میشه ؟

چه افرادی در این لایه درگیر هستند ؟

  • مدیریت ارشد
  • مدیریت میانی (مدیران میانی)
  • همه تصمیم گیرندگان سازمانی

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

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

لایه فیزیکی (فناوری) :  پایین ترین لایه معماری سازمان هستش که به توصیف زیرساخت های سطح بالا برای حال و آینده سازمان می پردازه که شامل موارد ذیل میشه :

  • سخت افزار سیستمی
  • نرم افزار سیستمی
  • شبکه
  • فناوری اطلاعات
  • پایگاه های داده

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

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

 

چارچوب ارزیابی OMB

چارچوب ارزیابی OMB ابتدا به منظور پایه گذاری وضعیت معماری سازمانی در فدرال آمریکا طراحی شد. رسالت و هدف بنیادین چارچوب ارزیابی OMB کمک به سازمانها در جهت فهم هرچه بهتر وضعیت موجود و معماری فعلی سازمان است. در واقع مباحثه و گفتگو با سازمانها را در جهت یکپارچگی و بهبود مداوم فرآیندهای تصمیم گیریشان را دنبال می کند. در واقع OMB یک برنامه ریزی استراتژیک و مکانیزم کنترلی است که از هم ترازی فعالیت های کسب و کار سازمان با اهداف و ماموریت سازمان اطمینان حاصل می کند)

چارچوب OMB چهار  شاخص دارد گه با هم بررسی می کنیم :

  • تغییر (میزان بهینه بودن مدیریت تغییرات سازمان)
  • یکپارچگی (ضمانت استاندارد بودن اینترفیس ها، عملیات درونی، اطلاعات و پیوستگی ایجاد شده توسط معماری سازمانی)
  • هم گرایی (میزان یکپارچگی فناوری اطلاعات بصورتی که در مدل مرجع فنی Technical Reference Model – TRM) تعریف شده است.
  • همراستایی کسب و کار (میزان همسویی و هم ترازی کسب و کار سازمان با ماموریت و و اهداف راهبردی سازمانی)

ضمنا ۶ سطح بلوغ را طی می کند که با هم دنبال می کنیم : (سطح ها از ۰ شروع می شوند یعنی سطح ۰ تا سطح ۵)

  • سطح صفر : هیچ فرآیند آی تی موجود نیست این یعنی هیچ مدرکی دال بر حضور معماری سازمانی نداریم.
    • (No EA Evidence : it’s Such a Disaster, isn’t it ?)
  • سطح یک : فرآیندهای آی تی ابتدایی هستند و حالت مقدماتی دارند.
    • (It process are in Pre-Intermediate Range)
  • سطح دو : از بهترین تجربیات استفاده می کنیم (Best Practice) این یعنی فرآیندهای آی تی رسمی هستند و تکراری
    • (IT Process are Formal and Iterative)
  • سطح سه : عملیاتی شدن معماری سازمانی در سازمان شروع شده است.
    • (It’s Just the Begin Phase, Seat and See What do We Got)
  • سطح چهار : عملیاتی شدن معماری سازمانی در سازمان را شاهد هستیم، این یعنی فرآیندهای آی تی مدیریت شده اند.
    • (We Did it, Didn’t we, just see the result)
  • سطح پنچ : برنامه ریزی فناوری اطلاعات یعنی ITSP در سازمان بهینه شده است.
    • (Improvement is Tangible, just take it and free your self)

اما بلوغ معماری سازمانی چه مواردی را در بر می گیرد ؟

  • توسعه محصولات معماری سازمانی EA Product Development
  • توانایی برنامه معماری سازمانی در فراهم نمودن پیشنهادهای سرمایه گذاری مشخص به عنوان بخشی از فرآیند برنامه ریزی مالی
  • کنترل سرمایه گذاری (Investment Control)

چارچوب توگف – TOGAF

توگف در واقع روشی برای طراحی و رسیدن به حالت مطلوب سازمان هست و شامل مجموعه ای از استانداردها هست که با همراهی مجموعه ای از ابزارها و سازه بلوک ها با تکیه بر واژگانی مشترک سعی در این مهم دارد. در توگف راهبردهای کسب و کار به عنوان ورودی فاز دیدگاه معماری در نظر گرفته شده است و دارای معماری بنیادین در قالب مدل مرجع فناوری (Technical Reference Model) هست و دارای یک متدولوژی عملی پیاده سازی به نام ADM هست که در واقع قلب تپنده این چارچوب هست.

نسخه جدید توگف در ۲۰۰۹ با پشتیبانی کامل از Service Orientation ارائه شد و این تحولی بزرگ و مزیتی رقابتی برای این چارچوب شمرده می شود. از جمله مفاهیم اصلی در توگف پیوستار سازمان، مخزن معماری و قابلیت معماری هست که بعدا مفصل باید بحث بشن.

توگف شامل ۴ دیدگاه هست :

  • معماری کسب و کار : راهبردی های کسب وکار، حاکمیت، سازماندهی، فرآیندهای مهم کسب و کار
  • معماری برنامه های کاربردی :
  • معماری دیتا : ساختار منطقی وفیزیکی دارایی های دیتا، مدیریت دیتا
  • معماری تکنولوژی : قابلیت های سخت افزاری و نرم افزاری (شبکه و …)

ارکستریشن یا هم نواسازی در تقابل با کاریگرافی یا رقصندگی

در هم نواسازی ما دو تا عنصر اصلی داریم :

  • رهبر ارکستر
  • نوازندگان ابزارها (شما فرض کن سنتور که من عاشقشم)

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

اما تو رقصندگی ما چی داریم ؟

  • یه رقصنده داریم
  •  یه گروه از رقّاصان صحنه

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

هم نواساز سرویس (Service Orchestration) یک فرآیند کسب و کار قابل اجرای متمرکز منفرد (به مانند رهبر ارکستر) را ارئه می کند که نقش هماهنگی تعاملات فی ما بین سرویس های مختلف را بر عهده دارد.

در واقع Orchestrator یا هم نواساز دو تا وظیفه داره :

  • فراخوانی سرویس ها Service Invoke
  • ترکیب سرویس ها Service Combine

در واقع در Service Orchestration سرویس های چندگانه رو توسط یک Fixed Logic کنار هم قرار میدیم. این  Fixed Logic تو یه جای منفرد تشریح میشه. مثالش هم BPEL process هست. BPEL process شامل یه Logic هستش که می تونه چندین سرویس رو فراخونی کنه و Response هاشون رو یه عنوان یه Single Response Service ارائه کنه.

Orchestration زمانی مفید مواقع میشه که روی تمامی Actor های فرآیندمون کنترل داشته باشیم زمانی که همه اون Actor ها داخل یه Domain Control حاضر باشن و ما بتونیم جریان جریان کار رو دیکته کنیم. (dictate the flow of activities).

مساله دیگه اینکه هم نواسازی نسبت به رقصندگی دو تا مزیت داره :

  • قابلیت اطمینان Reliability
  • قابلیت تغییر Modifiability : ساخت و تغییر  process workflows و ترکیب سرویس های پیچیده (complex service compositions) در visual BPM tools که داخل پلت فرم های هم نواسازی هست آسون تره.

از سوی دیگه دیگه اینکه هم رقصندگی نسبت به هم نواسازی دو تا مزیت داره :

  • عملکرد Performance : هم نواساز هنگام تفسیر اسکریپت های جریان کار دچار یه سربار عملکرد (performance overhead) میشه
  • هزینه Cost : رقصندگی بر خلاف هم نواساز نیاز به زبان میانی یا زبان خاصی نداره

 

مدل مرجع فنی Technical Reference Model

از آنجایی که کتابخانه مرجع معماری سازمانی باید شامل مدل های مرجع هم باشد و TRM هم یک مدل مرجع است، TRM را با هم در TOGAF بصورت شماتیک بررسی می کنیم :

TOGAF دو تا مدل مرجع داره :

  • مدل مرجع فنی TRM
  • مدل زیرساخت اطلاعاتی جامع و یکپارچه IIIR

در واقع TRM دو تا بخش داره :

  • مدل
  • طبقه بندی

مدل و طبقه بندی برای چه ؟ برای سرویس های سکوهای عمومی

هر دو تا مدل بالا می تونن داخل پیوستار معماری سازمانی Enterprise Architecture Continuum مطرح بشن (مفصل درباره این Enterprise Architecture Continuum باید صحبت کنیم).

TOGAF_TRM
مدل مرجع فنی توگف

یک سری نکات را در رابطه با مدل مرجع فنی بررسی می کنیم :

  • بنیان مستحکم چارچوب TOGAF هستش.
  • نقش ADM اینجا چی هست ؟ ADM میاد میگه چطور میشه از این معماری بنیادین واسه یه مرکز خاص استفاده کرد و توسعه اش داد (Development)
  • TRM نیازهای محاسباتی که حالت General دارن رو نمایش میده
  • TRM بخش های Constructor که حالت General دارن رو نمایش میده
  • تعریف استانداردهای فناورانه که واسه Implement بخش های Constructor نیاز هست رو بر عهده داره
  • Product Direction رو انجام میده
  • Strategies رو نمایش میده
  • Open Sys Standards رو نمایش میده

TRM دو بخش اصلی داره :

  1.  Terms Description +  Information Systems Structure Segments Define
  2. A model with a Big Picture of Number 1 Class
TRM با دید سطح بالا
TRM با دید سطح بالا

شکل زیر مدل مرجع فنی رو که با نرم افزار Rational System Architect طراحی شده رو نشون میده :

مدل مرجع فنی طراحی شده توسط Rational System Architect
مدل مرجع فنی طراحی شده توسط Rational System Architect

این شکل هم رو نشون میده که سطوح چهارگانه سرویس در اون مشخص شده

  • محیط سرویس
  • موضوع سرویس
  • استاندارد سرویس
  • مشخصات سرویس

 

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

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