انتشار مقاله مهاجرت به معماری میکروسرویس ها

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

صفحه مقاله در Researchgate

چارچوب بانکی BIAN

بخش اول : آشنایی
شبکه معماری صنعت بانکی یک انجمن مستقل و مجزی از موسسات بانکی و شرکت هایی است که به ارائه ره آوردهای بانکی می پردازند که نزدیک به ده سال است با هدف ارائه بهترین دستاوردهای معماری سرویس گرا ایجاد شده است. اما فایده این چارچوب چه بوده است ؟ استانداردها و منابعی که توسط این چارچوب تولید شده است دو دستاورد مهم را به دنبال داشته است :
اول اینکه هزیته مصرفی جهت تحقیق و توسعه R&D به شدت کاهش داشته است.
دوم اینکه تعامل پذیری روابط در صنعت بانکی رواج یافته است.
سوم اینکه تولید و پیاده سازی سیستم های یکپارچه بانکی (Banking Integrated System) افزایش داشته است.
جالب است بدانید این چارچوب به طور رایگان و به منظور استفاده عموم مردم منتشر می شود بر خلاف بسیاری از سازمان هایی که اسناد چارچوب خود را در قبال هزینه های گزاف در فضای وب منتشر می کنند. نقطه قوت بیان اتکا بر زبان مدلسازی یکپارچه یا همان UML خودمان است بطوری که مدل های تولید شده BIAN مبتنی بر UML می باشند و Web-Based Platform نیز به صورت آنلاین انتشار یافته است. نقطه قوت دیگر BIAN به روزبودن مداوم آن است چرا که طی ۵ سال اخیر ۵ ورژن از آن با بروزرسانی های بنیادین منتشر شده است. نقطه قوت دیگر این چارچوب Service-oriented بودن آنست که نقش بسزایی در پویایی آن داشته است.
بهترین مرجع یادگیری BIAN
بهترین مرجع یادگیری این چارچوب بانکی وب سایت رسمی اش به این آدرس می باشد. بسیاری از مستندات و راهنماهای کاربری در قالب User Guide به منظور استفاده عموم در این وب سایت گنجانده شده است.

اصول و قواعد طراحی در BIAN
اصول و قواعد طراحی در BIAN

اصول و قواعد طراحی در BIAN
ویژگی های کلیدی ورژن ۶ چارچوب BIAN (به این آدرس مراجعه کنید)
نمودار گرافیکی نزدیک به ۱۰۰۰ سناریوی سطح کسب و کار اضافه شده است.
نزدیک به ۲۰۰۰ سرویس و عملیات هر سرویس به صورت کامل تببین شده است.
سناریوهای پیاده سازی معماری نرم افزارهای بانکی مبتنی بر چارچوب سرویس گرا را در خود می بیند.
ویژگی های API های منطبق بر استاندارد ISO20022
اما چالش کار یا به عبارت بهتر پیش نیازهای کار با چارچوب BIAN چیست ؟
از آنجایی که این سند دربرگیرنده مفاهیم عمیق و در سطح Technical است مطالعه آن بدون داشتن دانش در حوزه Enterprise Architecture, Service-oriented  Architecture, interoperability Standards و دانش هایی از این سطح بی نتیجه خواهد بود.
بخش دوم : BIAN و EA
قبل از هر چیز باید مطلع باشیم که BIAN از دل معماری سازمانی مختص حوزه بانکی تبلور داشته است که سطوح متنوع معماری سازمانی را بطور کامل پوشش می دهد. برای اطلاع بیشتر از لایه های معماری سازمانی می توانید به این پست مراجعه کنید.

چشم انداز چارچوب BIAN
چشم انداز چارچوب BIAN

چشم انداز چارچوب BIAN
در شکل زیر من به پوشه Payments وارد شدم که در مسیر Data > BIAN > API Waves > Wave1 > Payments قرار دارد وارد شدم و Class Diagram Payments Index – B2B/B2C را مشاهده می کنیم. نمودار ذیل کلاس دیاگرام فرآیند پرداخت کسب و کار به کسب و کار و کسب و کار به مصرف کننده است. منظور از B2B : Business 2 Business و منظور B2C : Business 2 Consumer می باشد. پکیج ذیل مربوط به بخش پرداخت ها می باشد که دارای دو سرویس دامین می باشد که فرآیند نگاشت روی آن ها صورت می گیرد.


در شکل زیر نیز چشم انداز BIAN نسخه ۶ رو مشاهده می کنید.

چشم انداز چارچوب بانکی BIAN نسخه 6.0
چشم انداز چارچوب بانکی BIAN نسخه ۶٫۰

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

نمونه چارچوب زکمن در مثال دانشگاهی

در شکل زیر می توانید نمونه چارچوب زکمن از منظر دانشگاهی را مشاهده و بررسی کنید.

 

مثال چارچوب زکمن در دانشگاه
مثال چارچوب زکمن در دانشگاه

 

دانلود اصل سند با کیفیت بالا زکمن

ارزیابی آمادگی تغییر یا 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)