tag:blogger.com,1999:blog-21358763535146212882011-08-30T17:36:23.877+04:30شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.comBlogger191100tag:blogger.com,1999:blog-2135876353514621288.post-20490847751388636272011-08-14T15:16:00.000+04:302011-08-14T15:16:38.323+04:30<div dir="ltr" style="text-align: left;" trbidi="on"><div style="text-align: right;">بعد از مدتها غیبت می خوام توی این پست خلاصه ای از یافته های تزم رو بگم. موضوعی که روش کار کردم معماری امنیت و ارتباطش با معماری سازمانی بود. راستش انگیزه زیادی برای اینکار وجود داشت با توجه به تجربیات قبلی. امنیت یکی از دغدغه های مهم سازمانهاست و معماری سازمانی هم به عنوان یک چارچوب در سازمند کردن دغدغه ها باید بهش بپردازه. خصوصا چارچوبهای معماری سازمانی که برای پاسخگویی به دغدغه های ذینفعان اغلب مولفه ای رو پیش بینی کردند بایستی امنیت رو هم پوشش بدند به شکل مناسبی. توی پروژه هایی که قبلا توی ایران اجرا می کردیم همیشه سازمانها می گفتند امنیتش کجاست؟ ما هم اگه بر اساس دودف کار می کردیم می گفتیم توی همه محصولات امنیت مورد توجه قرار گرفته ولی بازم همیشه می گفتند خوب میشه یه جا جمعش کنید و نشون بدید بالاخره امنیت ما رو چجوری دیدید. و همیشه ما جواب درستی نمی تونستیم بدیم. حوزه امنیت یه جورایی استانداردهای خودش رو داره و به دلایلی مدیریتش هم جداگانه دیده میشه. چون اینکه چه کسی به چه اطلاعاتی دسترسی داشته باشه یه جورایی قدرت می ده به اون فرد یا واحد سازمانی و به همین دلیل مساله امنیت فقط یه موضوع تکنیکی نیست و یه مساله سیاسی هم هست توی سازمانها. شاید به همین دلیله که برخورد چارچوبهای مختلف معماری سازمانی با امنیت متفاوته. برخی از چارچوبهای معماری سازمانی امنیت رو بطور صریح یک مولفه تعریف می کنند مثل چارچوب دی ان دی ای اف و برخی چارچوبهای دیگه مثل دودف در متن سایر محصولات بهش می پردازند. من توی تزم روی این موضوع متمرکز شدم که اصلا معماری امنیت از کجا اومده و چارچوبهای مختلف چجوری دیدند امنیت رو و اینکه چرا این نگاه چند گانه به معماری امنیت وجود داره و نهایتا هر یک از رویکردهای موجود به امنیت چه نتایجی برای سازمانها می تونه در بر داشته باشه. اینکه معماری امنیت از کجا اومده رو میشه با بررسی تاریخچه معماری امنیت فهمید. این واژه از دهه 70 و 80 هم با مفهوم تکنیکی مورد استفاده قرار گرفته که بیشتر بحث معماری امنیت شبکه و پایگاه داده&nbsp;مورد نظر بوده و مفهوم معماری امنیت به عنوان یک رویکرد جامع در&nbsp;یکپارچگی امنیت بعد از مطرح شدن&nbsp;معماری سازمانی&nbsp;توسط زکمن مورد توجه قرار گرفته و اولین بار در اوایل دهه نود توسط وزارت دفاع ایالات متحده معماری امنیت به عنوان یک طرح جامع&nbsp;امنیت که توش از راهبردهای امنیت فناوری اطلاعات تا سازماندهی مسولیتهای امنیت و رویه های امنیتی بحث شده. بنابراین معماری امنیت با این مفهومش یه جورایی متاثر از معماری سازمانیه. ولی سوال اینجاست که چرا مثل بقیه معماری ها مثل معماری داده، معماری سیستم و معماری شبکه به عنوان یک زیرمعماری استاندارد در نیومده و هر چارچوبی یه جور باهاش برخورد کرده. من 2 تا تحلیل دارم برای این موضوع: 1- معماری امنیت ضرورتش بعد از معماری های دیگه احساس شده چون اولین دغدغه ایجاد سیستمهای یکپارچه و ایجاد دسترسی توسط شبکه های اطلاعاتیه و دغدغه امنیت یه جورایی از نظر زمانی بعد از ایجاد سیستمها بطور جدی احساس می شه. 2- مسئله امنیت ابعاد غیر فنی زیادی داره و تا حدی سیاسی-فرهنگی هم محسوب میشه و حتی ملیتهای مختلف برخورد متفاوتی باهاش دارند پس تعریف اون به صورت استاندارد مشابه معماری داده و سیستم به راحتی امکان پذیر نیست و اصولا امنیت در هر محیط و سازمانی باید بطور بومی تعریف بشه. بنابراین با&nbsp;مقوله معماری امنیت&nbsp;برخوردهای مختلفی شده. بر اساس یافته های مرور ادبیات بطور کلی چند رویکرد در تدوین معماری امنیت میشه مشاهده کرد. 1- رویکرد تدوین معماری امنیت بطور یک فرآیند مستقل از معماری سازمانی که معمولا در سازمانهایی اتخاذ میشه که سازمان مدیریت امنیت فاوا در اونها مستقل از مدیریت سیستمها و ... است. 2- رویکرد تدوین معماری امنیت مرتبط با معماری سازمانی که خودش چند شکل مختلف داره : 2-1- استفاده از مفاهیم معماری سازمانی برای تعریف معماری امنیت (مثلا استفاده از چارچوب زکمن برای تعریف چارچوب معماری امنیت) 2-2- استفاده از محصولات معماری سازمانی برای تدوین معماری امنیت و 2-3- تدوین معماری امنیت به عنوان بخشی از معماری سازمانی. در این&nbsp;رویکرد اخیر هم چارچوبهای معماری هم که برای مسائل و سازمانهای مختلف ایجاد شدند برخورد متفاوتی داشتند با این مقوله. اگه برای دسته بندی رویکرد چارچوبها از متاچارچوب گرم استفاده کنیم میشه گفت چارچوبها امنیت رو در خود چارچوب، متدولوژی معماری، متامدل معماری، محصولات معماری و ... مورد توجه قرار دادند. مثلا چارچوب دودف در متامدلش به امنیت پرداخته و دی ان دی ای اف براش محصول هم داره و یا ای تو ای اف فقط بعنوان یک مولفه در چارچوب معماری به امنیت پرداخته. هر کدوم از این استراتژیها می تونند پیامدها و دستاوردهای متفاوتی برای سازمانها داشته باشند که در تز بطور مفصل بحث کردم و اگه علاقه مند بودید بحثش رو ادامه می دم</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-2049084775138863627?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com3tag:blogger.com,1999:blog-2135876353514621288.post-5725993517936219332010-10-07T01:06:00.000+03:302010-10-07T01:06:36.074+03:30<div dir="ltr" style="text-align: left;" trbidi="on"><div dir="rtl" style="text-align: justify;">این ترم یک درسی داریم به نام طراحی سیستمهای مدیریت قواعد کسب و کار که توسط لارش فرنبرو تدریس میشه. راستش برام جالب بود این درس. چون ما توی پروژه های معماری سازمانی این بحث قواعد کسب و کار رو به عنوان یکی از ابعاد معماری سازمانی داریم و معمولا کار زیادی براش انجام نمی دادیم. توی معماری بر اساس چارچوب زکمن که فقط از دیدگاه طراح کسب و کار یه کمی از راهبردها و اهداف راهبردی و این حوزه ها صحبت می گردیم و اگه خیلی می خواستیم کامل کار کنیم از مدل <a href="http://www.omg.org/spec/BMM/1.1/PDF">BMM, OMG</a> استفاده می کردیم برای اینکار ولی توی حوزه تعریف قواعد کسب و کار، کار خوبی انجام نمی شد. چون خروجیهاش کاربرد زیادی برای کسب و کار یا پیاده سازی سیستمها نداشت. یادمه حتی ما وقتی مبتنی بر چارچوب DoDAF کار می کردیم و محصولات OV-6a , SV-10a که خاص قواعد کسب و کار و سیستم هستند رو تولید می کردیم محصولات پیشنهادی DoDAF برای OV-6a همون انگلیسی ساختیافته بود و برای SV-10a هم زبان مدلسازی مثل درخت تصمیم و اینها مطرح می شد که ما معمولا به دلیلی که بالا اشاره کردم سراعش نمی رفتیم. جالب هستش برام توی این درس که استادش اتفاقا معماری سازمانی هم درس می ده بر اساس <a href="http://www.amazon.com/Enterprise-Architecture-Integration-Technologies-Communications/dp/1580537138">کتاب اخیر فینکل اشتاین</a>، ببینم چه نسخه ای برای حوزه قواعد کسب و کار داده میشه. از اول ترم بحثهای مختلفی مطرح شد از جمله: </div><div dir="rtl" style="text-align: justify;">1- مدلسازی مفهومی کسب و کار (Conceptual Model) که یه جورایی موجودیتها و روابط بین اونها رو از منظر قواعد کسب و کار توصیف می کنه </div><div dir="rtl" style="text-align: justify;">2- همینطور مدل Term-Fact که همون انگلیسی ساختیافته خودمون بود توی OV-6a در چارچوب DoDAF اینها بقول خود لارش برای پوشش به دیدگاه های کسب و کار بکار می رند (که به اعتقاد من برای پوشش به دیدگاه برنامه ریز کسب و کار باید استفاده از BMM هم مدنظر قرار بگیره با توجه به اینکه توی BMM جایگاه قواعد کسب و کار که مربوط به دیدگاه مالک کسب و کار هستش )</div><div dir="rtl" style="text-align: justify;">3- استفاده از ابزارهای پیاده سازی قواعد کسب و کار مثل <a href="http://www.swi-prolog.org/">Prolog </a>که برنامه نویسی&nbsp;Declarative&nbsp;&nbsp;رو برای مدلسازی قواعد و تعریف روابط تجربه کردیم</div><div dir="rtl" style="text-align: justify;">4- پیاده سازی قواعد کسب و کار با استفاده از ابزارهای جدید و پیشرفته مثل <a href="http://www.visual-rules.com/">Visual Rules</a> و برقراری ارتباط اون با سیستمهای مدیریت پایگاه داده مثل SQLServer رو یاد گرفتیم</div><div dir="rtl" style="text-align: justify;"><br /></div><div dir="rtl" style="text-align: justify;">و در نهایت چیزی که امروز جمع بندی کردیم از مقوله های ارائه شده این بود که اگر رویکرد اجرای پروژه های بعد از معماری سازمانی برای پیاده سازی سیستمها استفاده از این فناوری ها باشه، خوب مدلسازی قواعد کسب و کار در معماری سازمانی می تونه بسیار مفید باشه. حتی اگه رویکرد استفاده از ابزارهای خیلی پیشرفته هم مطرح نباشه استفاده از مدلسازی قواعد کسب و کار تا حد زیادی به افزایش دقت در پیاده سازی قواعد کسب و کار و سهولت در نگهداشت اون منجر میشه. البته استراتژی استفاده از ابزارهای پیاده سازی قواعد کسب و کار بر اساس مسائل مختلفی مثل معماری نرم افزار، پیچیدگی قواعد کسب و کار، نرخ تغییرات اونها، ویژگیهای کیفی سیستمها و ... می تونه متفاوت باشه که میشه توی <a href="http://www.amazon.com/Business-Rules-Information-Systems-Aligning/dp/0201743914">کتاب مورگان(Morgan)</a> بیشتر راجع بهش مطالعه کرد. همچنین جمع بندی دیگه ای که من داشتم و مورد تأیید لارش هم بود اینه که برای پوشش به مراحل مختلف مدلسازی قواعد از دیدگاه کسب و کار، منطق سیستمی و فناوری های پیاده سازی متدولوژی یکپارچه و مدونی وجود نداره. حتی زبان مدلسازی و ابزارهای استانداردی که همه مراحل رو پوشش بده هنوز وجود نداره گرچه OMG فعالیتهای خوبی داره انجام می ده و این موضوع رو به &nbsp;پیشرفت هستش. من شخصا استفاده از مدلسازی کسب و کار و ابزارهای پیاده سازی پیشرفته رو برای تولید و نگهداشت سیستمهایی با قواعد پیچیده و متعدد و نرخ تغییرات بالا (مثل سیستم حقوق و دستمزد یا سیستمهای مالی و بانکی) مفید می دونم. گرچه باید در استفاده از روش و استاندارد و ابزارهای پیاده سازی دقت فراوانی کرد و ازتجارب موفق و آزمایش شده استفاده کرد. البته با توسعه معماری سرویس گرا استفاده از موتورهای مدیریت قواعد کسب و کار (Rule Engine) خیلی مفید و کاربردی به نظر می رسه. اینه که توسعه&nbsp;سیستمهای سرویس گرا&nbsp;با رویکرد مدلسازی قواعد کسب و کار الان مورد توجه قرار گرفته که می تونید مطالب خوبی در <a href="http://www.amazon.com/Business-Management-Service-Oriented-Architecture/dp/0470027215/ref=pd_sim_b_3">کتاب مدیریت قواعد کسب و کار و معماری سرویس گرا نوشته آقای&nbsp;یان گراهام (Ian Graham)</a>&nbsp;ببینید.</div></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-572599351793621933?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com2tag:blogger.com,1999:blog-2135876353514621288.post-58309817113258758002010-10-02T03:33:00.004+03:302010-10-02T03:54:02.396+03:30<div style="text-align: justify;">امروزه مفهوم Enterprise 2.0 که مبتنی بر قابلیتها و فناوریهای WEB 2.0 شکل می گیره توی دنیا خیلی جدی مطرحه. ارکان و بخشهای اصلی این نوع Enterprise مفاهیم نوینی هستند که بر پایه نسل دوم اینترنت یعنی اینترنت بین افراد تعریف می شن. اگر نسل اول اینترنت رو اینترنت بین صفحات بدونیم، نسل دوم، اینترنت بین افراد هستش که تبلورش ایجاد شبکه های اجتماعی مثل فیس بوک و ... هستش و الان حتی نسل سوم اینترنت و بالتبع اون Enterprise 3.0 رو اینترنت اشیاء تعریف میکنند. که توی این نوع اینترنت این اشیا هستند که توی شبکه با هم قرار می گیرند و تعامل می کنند مثلا موتور اتوموبیل شما به کمپانی سازنده اش متصل میشه و از طریق نرم افزار عیب یابی،عیبش رو پیدا میکنه و اگه بشه بصورت تنظیم نرم افزار مشکل رو حل کرد خودش برنامه رو دانلود می کنه و خودش رو تنظیم می کنه و مشکل حل میشه. Enterprise 2.0 در واقع شکل گیری شبکه هایی برای ثبت و به اشتراک گذاری اطلاعات و دانش بصورت غیر رسمی در سازمانها است که در خلال اون دانش و اطلاعات بصورت غیر رسمی و غیر ساخت یافته شکل و ساختار پیدا می کنه. نمونه های این نوع سازمانها، سازمانهایی هستند که افراد اطلاعات رو در ویکیها و وبلاگهای شخصی ثبت و تگ گذاری می کنند و بدین ترتیب مجموعه غیر ساخت یافته ای از اطلاعات پدید میاد که میشه از اون استفاده کرد به نفع سازمان. مسأله ای که وجود داره اینه که در این نوع از سازمان، تعاریف و مرزهای رسمی و سنتی سازمانی تغییر می کنه. فرض کنید اطلاعات سازمانی توی بلاگ شخصی یکی از کارمندان آزادانه ذکر بشه در صورتی که سازمان نخواد اون اطلاعات به یک مشتری یا رقیب یا هر کس دیگه ای برسه. یا مثلا اطلاعات راجع به افراد با نفوذ سازمان منتشر بشه. خوب شکل مدیریت و هدایت این سازمانها متفاوت هستش و باید باشه. در اینجا این مسأله مطرح میشه که اصولا معماری Enterprise 2.0 چجوری باید انجام بشه. آیا از همون ارکان معماری سازمانی معمولی میشه استفاده کرد یا چارچوب و مفاهیمش متفاوته. این ایده یکی از دوستان خوبم اقای احمدی بود. به هر حال این موضوع جای کار زیاد داره و حتی در شکل جدیدتر Enterprise 3.0 شیوه معماری چجوری میشه؟ اگر علاقه مند باشید می تونیم روی این موضوعات بحث کنیم.</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-5830981711325875800?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com0tag:blogger.com,1999:blog-2135876353514621288.post-9217864023112643392010-09-04T22:11:00.002+04:302010-09-04T22:14:01.227+04:30با سلام به همه دوستان عزیز. من یه دوره ارشد سیستمهای اطلاعاتی رو در دانشگاه لوند شروع کردم و می خوام در این فضای جدید دوباره نوشتن بلاگ رو شروع کنم. امیدوارم بتونم مطالب جدیدی رو به رویکردهای قبلی اضافه کنم.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-921786402311264339?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com6tag:blogger.com,1999:blog-2135876353514621288.post-78695590500524155292010-03-29T19:21:00.002+04:302010-03-29T19:33:58.300+04:30سلام این اولین پست در سال 1389 هستش. راستش 1 سالی هست که دارم به موضوع معماری سازمانی مسأله محور با رویکرد حل مشکل فکر می کنم. نظرات آقای فتح اللهی رو هم خوندم توی پست قبلی. به نظر من توی ایران این رویکرد مسأله محور بودن معماری سازمانی در حال حاضر بهتر جواب می ده. چون واقعا شرایط در سازمانهای ما به قدری متغیره که سخت میشه زیرساختهای معمارانه رو شناخت و اصول معماری سازمانی رو در موردشون بکار برد. من می خوام یک رویکرد حل مسأله در معماری سازمانی رو مطرح کنم که البته یه جورایی می تونه نمود همون سطح بلوغ یک در مدل بلوغ معماری باشه. یعنی استفاده از معماری سازمانی بصورت موردی و حسی برای برخی مسائل سازمان. فکر می کنم سازمانهای ما باید سطوح بلوغ رو به ترتیب بگذرونند. چون اصلا مفهوم بلوغ هم همینه. چطور میشه توقع داشت تو سازمانهایی که حتی تعریف درستی از فرآیندها ندارند یک نظام مدیریت تغییر یکپارچه بر اساس مدلهای معماری پیاده سازی بشه. ولی در موارد خاص میشه با رویکرد معماری سازمانی مسأله محور فواید معماری رو در سازمانهای به اثبات رسوند تا سطح بلوغ سازمان به تدریج بالاتر بره و معماری به عنوان یکی از فرآیندها و رفتار سازمان تبدیل بشه. دارم مرور ادبیات انجام می دم روی این رویکرد اگه بتونم به عنوان مقاله مطرحش کنم شاید بد نباشه. لطفا نظر بدید راجع به این رویکرد. اگه یادتون باشه استفاده از روش ال اف ای برای تعریف اهداف معماری هم دقیقا در راستای همین رویکرد مطرح کردم. مشکلاتی مثل ابهام در ارزش آفرینی فناوری اطلاعات برای کسب و کار، مشکل یکپارچه نبودن اطلاعات، نبود توجیه فنی و اقتصادی برای سرمایه گذاری در زیرساختهای فناوری اطلاعات و ... می تونن با رویکرد معماری حل بشن و بتدریج کارکرد معماری سازمانی رو در سازمانها نشون بدن.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-7869559050052415529?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com1tag:blogger.com,1999:blog-2135876353514621288.post-48442170176154359022010-01-31T15:19:00.002+03:302010-01-31T15:31:29.820+03:30یکی از ریسکهای مهم پروژه های معماری سازمانی ریسک ناشی از مسائل مربوط به نیروی انسانی است. معمولا برای مدیریت این حوزه از ریسک، موضوعی با عنوان مدیریت تغییرات در پروژه های معماری سازمانی اجرا میشه. چون اصولا همیشه به دنبال معماری بحث تغییرات پیش میاد و مقاومت سازمان در برابر تغییرات طبیعیه. چون اصولا سازمانها مشابه هر سیستمی بعد از مدتی کار کردن به تعادل می رسند. و دلشون نمی خواد این تعادل به هم بخوره. مدیریت تغییرات در واقع با هدف پیش بینی تغییرات مورد نیاز در کلیه ابعاد سخت و نرم از جمله نیروی انسانی در معماری سازمان باید از ابتدای کار تا انتهای گذار انجام بشه. برنامه مدیریت تغییرات می تونه شامل یکسری فعالیتهای فرهنگ سازی مثل آموزش، مشارکت افراد در معماری، برگزاری همایش و سمینار و این جور فعالیتها باشه تا تغییرات در نظام و سازماندهی نیروی انسانی به طوری که منفعت افراد با اهداف و جهت گیریهای معماری سازمانی همسو بشه. مثلا اگر در یک پروژه ای به این نتیجه رسیدیم که یک فرآیندی رو میشه در وضع مطلوب بصورت مکانیزه انجام داد و نیروی انسانی مربوطه تقلیل داده می شه خوب میشه قبل از انجام این تغییر برای نیروی انسانی مربوطه شغل و جایگاه جدید در نظر گرفت و بتدریج با آموزش اونها رو برای تصدی مشاغل جدید آماده کرد و این برنامه تغییر شغل اون افراد رو که می تونه حتی یک ارتقا براشون محسوب بشه، با برنامه تغییر فرآیند همزمان مدیریت و اجرا کرد. یا مثلا اگر فرآیندی قراره در وضع مطلوب برونسپاری بشه و نیروهای انجام دهنده بیکار بشن خوب مثلا میشه اون نیروها رو در قالب یک شرکت وابسه ساماندهی کرد و اجرای فرآیند رو به خودشون واگذار کرد. اینجوری هم راندمان کاری اونها بالا میره و هم ممکنه درآمدشون بیشتر بشه. خلاصه که توجه به همسو کردن افراد و منافع اونها در هر برنامه تغییر سازمانی، از الزامات موفقیت اون برنامه هستش. چون آخر موضوع این افراد هستن که باید در معماری جدید و مطلوب ایفای نقش بکنند و ضامن موفقیت اون برنامه هستند. توجه به دلایل شکست پروژههای مهندسی مجدد فرآیندها و بکارگیری توصیه های مطرح شده در اون حوزه می تونه برای معماران سازمان مفید واقع بشه.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-4844217017615435902?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com2tag:blogger.com,1999:blog-2135876353514621288.post-7989382031168174562010-01-20T21:43:00.009+03:302010-01-31T15:19:37.739+03:30همونطور که قبلا هم عرض کردم، فرهنگ سازی روی محصولات معماری و ایجاد یک چشم انداز مشترک از آینده ترسیم شده در وضعیت مطلوب، می تونه به ایجاد عزم سازمانی برای اجرای نتایج معماری کمک کنه. اما یکی از دلایل اجرا نشدن نتایج معماری، بر می گرده به نقص محصولات که می تونه عملی نبودن راه حلهای ارائه شده در معماری مطلوب باشه. مثلا زیرساخت شبکه مورد نیاز برای موفقیت راه حل، ممکنه پهنای باند زیادی بخواد و این موضوع قابل حصول نباشه خوب طبیعتا نتایج پیاده نمی شن. یا اینکه مثلا ممکنه هزینه تمام شده برای مالکیت راه حلها قابل پرداخت توسط سازمان نباشه و راه حلهای بدون توجه به محدودیتهای سازمان معماری شده باشند. مشکل دیگه می تونه، عدم وجود قابلیت بروزرسانی و تغییرات محصولات معماری است. که در صورت بروز تغییرات در سازمان می تونه منجر به بایگانی شدن محصولات معماری بشه. به هر حال مشاور مجرب و متخصص در حوزه معماری سازمانی که با استفاده از ابزارها و استانداردهای نوین به فرآیند معماری سازمانی کمک کنه، می تونه این خطر رو کاهش بده. موضوع مهم دیگه نادیده گرفتن عوامل انسانی مثل فرهنگ سازمانی، سطح دانش و مهارت کارکنان در سازمان و همسو نبودن منافع افراد با اهداف معماریه. این عامل خیلی عامل مهمی هست که سعی می کنم در پست بعدی بیشتر بهش بپردازم.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-798938203116817456?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com0tag:blogger.com,1999:blog-2135876353514621288.post-72849306955512050332009-12-26T00:03:00.002+03:302009-12-26T00:27:42.939+03:30خوب عملی نشدن معماری سازمانی از اون ریسکهای شناخته شده و معروف معماری سازمانی هست. آقای اس پی واک هم در کتابش به موضوع تبدیل محصولات معماری سازمانی به کتابچه و قرار گرفتن در قفسه های سازمان اشاره کرده. در کشور خودمون هم از این موارد بسیار وجود داره. راستش نمیشه یک طرف رو مقصر دونست. به نظر من اگر این ریسک محقق بشه عوامل مختلفی مطرحه. از آماده نبودن سازمان برای معماری سازمانی می تونه دخالت داشته باشه تا خوب تدوین نشدن محصولات معماری و نقص کار مشاور. من سعی میکنم توی این پست کمی به این موضوع بپردازم. امیدوارم دوستان با تجربه تر کمک کنند تا بحث بیشتر باز بشه. من فکر می کنم یک آفتی که همه پروژه ها و مباحث بلندمدت از جمله معماری سازمانی رو در کشور تحت الشعاع قرار داده دولتی بودن اقتصاد ما و کوتاه بودن عمر مدیریت در دولتها است. به عبارت دیگر چون همه امور یه جوری با دخالت مستقیم دولت انجام میشه و تغییرات در مدیریت دولتی یک تابع سیاسیه بنابراین مدیران خیلی فرصت انجام کارهای بلند مدت رو ندارن و فقط به اقداماتی می پردازند که در دوره کوتاه مدیریتشون بتونه لیاقتشون رو نشون بده. موضوع معماری سازمانی از اون مباحثیه که عواید . اصلیش در بلند مدت عاید سازمان می شه و در واقع وقتی ارزش افزوده داره که نتایج اون در سازمان نهادینه بشه. به هر حال این موضوع به عنوان ریسک در همه برنامه های معماری سازمانی وجود داره. یکی از راه های مدیریت این ریسک اینه که برنامه معماری رو طوری مدیریت کرد که در دوره های کوتاه مدت نتایج جالب توجه برای مدیران هم داشته باشه. یا میشه روی فرهنگ سازی در لایه های مختلف سازمانی کار کرد که اگر مدیریت هم تغییر کرد اون برنامه ها توسط بدنه سازمان دنبال بشند. یک مدیر باهوشی به من گفت اگر بتونی یکی از 3 مساله مهمی رو که روی میز یک مدیر قرار داره ، با معماری حل کنی اون مدیر حتما از این برنامه حمایت می کنه. به نظرم برای مدیریت این ریسک اقدامات دوطرفه در سمت مشاور و کارفرما باید انجام بشه. در تاپیکهای بعدی سعی می کنم به دلایل دیگه اجرا نشدن نتایج معماری سازمانی مثل وجود اشکال در محصولات معماری سازمانی، عدم بروزرسانی محصولات، نپرداختن به موضوعات و پیشنیازهای انسانی و ... بپردازم. لطفا در هر مورد مشارکت کنید.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-7284930695551205033?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com3tag:blogger.com,1999:blog-2135876353514621288.post-75582968450960923312009-12-22T19:00:00.002+03:302009-12-22T19:16:42.280+03:30سلام من بعد از مدتها باز اومدم<br />از مشکلات و چالشهای معماری سازمانی اگر بگذریم، یکی از نکات مهم مطرح در معماری سازمانی، بحث اینه که اصلا اجرای یک پروژه معماری سازمانی چه نتایجی برای سازمان در بر داره و مهمتر اینکه چطور میشه ارزیابیش کرد. خوب یه سری نتایج کلی در خصوص معماری گفته میشه که مثلا فرآیندها رو بهبود میده، کسب و کار و فناوری اطلاعات رو همسو میکنه، یکپارچگی و تعامل پذیری بین سیستمها ایجاد میکنه، یا به قول اس پی واک منجر به افزایش کیفیت داده در سازمان میشه و هزارتا ادعای دیگه که میشه براشون مثال اورد و به طور شهودی بررسی شون کرد ولی چقدر میشه محکم و مستدل اثباتشون کرد؟؟؟ خوب آقای شکرمن سعی کرده توی یکی از کتابهای اخیرش به این مساله بپردازه و سعی کرده منافع مادی و اثرات اقتصادی معماری سازمانی رو ارزیابی کنه. البته تلاشش قابل تحسین است ولی خیلی عملی نیست. لااقل در ایران اینطوریه. میدونید معماری سازمانی یه دریاست از مدیریت راهبردی توش بحث میشه تا مسائل فنی سیستمی یا شبکه. چطور میشه توی این طیف وسیع دنبال اثرات و نتایج گشت و اون رو ارزیابی کرد. توی یکی از جلسات ارائه معماری سازمانی برای یکی از شرکتهای آبفا، یکی از مدیران سوال ظریفی پرسید. گفت شما میگید معماری سازمانی خوبه و ما باید انجامش بدیم و توی سازمان ما مفیده. خوب چطور اثباتش می کنید؟ چطور طرح اقتصادی برای اثبات منافعش ارائه می کنید؟ سازمان ما پروژه های مختلفی داره چرا باید پولش رو طرف این پروژه کنه؟ خوب دیدم حرفش خیلی حرف حسابه. امروز دیگه با این اوضاع اقتصادی خیلی نمیشه به دلیل پیروی از مد و انجام کارهای لوکس رفت سراغ معماری سازمانی. همونطوری که میبینید کلی از سازمانها متوقف کردند کارها رو به دلیل مشکلات اقتصادی. آیا میشه مثلا یک طرح تجاری برای پروژه معماری سازمانی ارائه کرد که توش نرخ بازگشت سرمایه هم قابل محاسبه باشه؟ اگه بشه خوب خیلی خوب میشه. من در جواب اون مدیر آبفا گفتم: خوب شما الان در این حوزه پیشتاز هستید و من خیلی نمی تونم بگم شرکتهای مشابه شما که این پروژه رو اجرا کردند کدوم شاخصهاشون چقدر بهبود پیدا کرد. ولی اگه بخواد یه کار علمی و خوب انجام بشه. باید چند تا داوطلب با ایمان به معماری سازمانی در حوزه آبفا پیدا بشن که بشه براشون پروژه رو اجرا کرد و بعد در یک کار تحقیقی تأثیر اجرای پروژه رو در اونها بررسی و جمع بندی کرد تا بشه به بقیه نوید این رو بدیم که اجرای این پروژه تا بحال این نتایج رو داشته و انشاالله برای شما هم خواهد داشت. آخه توی ایران همه میخوان بدونن کسی قبلا حاضر شده ریسک کنه و انجام بده یه کار جدید رو یا نه. به هر حال این حوزه ارزیابی نتایج معماری از اون بحثهایی که پیشرفت توی اون منجر به افزایش پروژه ها و پیشرفت این مبحث در لایه های مدیریتی میشه. مثلا موضوعی با عنوان تثیرات معماری سازمانی در حل مشکلات و چالشهای بحران اقتصادی میتونه این حوزه رو پر رونق تر از گذشته کنه.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-7558296845096092331?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com5tag:blogger.com,1999:blog-2135876353514621288.post-38917528287721703152009-02-11T19:23:00.003+03:302009-02-11T19:41:46.636+03:30اونهايي كه در فرآيند معماري سازماني به هر دليلي با تغييرات زياد مواجه شدند و مجبور شدند مرتبا مدلها رو تغيير بدن، الان آه از نهادشون بلند ميشه. نگهداشت كلمه خيلي قشنگيه و واقعا هم براي معماري لازمه. ولي چطور؟ خوب مي دونيد كه خيلي از ابزارها مثل System Architect، Metis, Enterprise Architecture, ....<br />ايجاد شدند براي نگهداشت راحتر مدلها ولي چقدر اين ادعا درسته و اونها چقدر موفق بودند بايد از معمارها پرسيد. خوب مي دونيد كه توي فرآيند معماري نظامهاي مختلفي وجود داره مثل مدلسازي فرآيند، مدلسازي داده و ... اين ابزارها براي نظامهاي شناخته شده اي مثل مواردي كه گفتم به دليل تجارب قبلي نسبتا موفقند مثلا محصول شركت پاپكين، نه تله لاجيك نه ببخشيد آي بي ام، قادر هست مدل داده اي منطقي رو به فيزيكي تبديل كنه، يا مثلا از مدل فرآيندي ترسيم شده با BPMN يك خروجي زيباي BPEL بده ولي ارتباط اين مدلها چي؟ مصيبت بزرگ توي هماهنگي اين مدلها با همه. ارتباط فرآيند با داده چيه؟ ارتباط داده با قواعد چيه؟ و ... شايد هر كدوم از اينها رو بشه يه جورايي توصيف كرد و حتي با تلاشي نه چندان مختصر مخزن معماري سازماني رو هم رام كرد كه اينها رو براتون يه جورايي ساپورت كنه ولي هماهنگي همزمان اينها با هم چطور؟ اصلا چي بايد بر اساس چي تغيير كنه؟ مسأله خيلي پيچيده تر از اين حرفا ميشه. من سعي كردم يه چيزايي تو پروژه هاي قبليم با محصول SA با همكاري آقاي مرادي به صورت اتوماتيك دربيارم ولي راه باقيمانده بسيار درازه. آخه يك مخزن بايد تفكرات مطرح تو يك چارچوب رو خوب حمايت كنه. در واقع يك مخزن معماري سازماني مدل مكانيزه چارچوب معماريه. ولي آيا مثلا ابزاري مي شناسيد كه چارچوب زكمن رو كامل و دقيق پوشش بده؟ اصلا به نظر من مسأله توي چارچوب معماري حل نشده كه توي مخزن مشكل پيش مياد. مدل منطقي بايد توي چارچوب حل بشه و مخزن فقط مثل يه بچه خوب بايد اون مدل رو حمايت كنه. در اين زمينه چارچوب نظامي آمريكا خيلي بهتر عمل كرده. با توجه به تجارب استفاده از اين چارچوب پيش بيني CADM به عنوان مدل داده اي خود معماري خيلي فكر خوبي بوده. به هر حال اگه مشكل مخزن و تازه مسأله ارتباط اون با ساير ابزارهاي سازماني به راه حلهاي خوبي منجر نشه، معماري سازماني با چالش جدي در جهان روبرو ميشه. تو يك وبلاگ استراليايي از قول يك منتقد معماري خوندم: " شما معمارها همش ميگيد ابزار، نگهداشت، يكپارچگي در محصولات ولي همتون تا ميخواهيد يه مدل نشون بديد سريع نرم افزار Word يا Power point رو باز مي كنيد و مدلها رو اونجا نشون مي ديد." به نظر من اين انتقاد ها رو بايد جدي گرفت و فكري براش كرد.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-3891752828772170315?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com4tag:blogger.com,1999:blog-2135876353514621288.post-34442628058235537412009-02-11T15:25:00.002+03:302009-02-11T15:51:52.143+03:30سلام من برگشتم. راستش يه مدته كه شديدا از لحاظ فكري با چارچوب معماري درگير شدم. خوب پيش از اين هم خيلي ها خيلي چيزها راجع به چارچوب معماري گفتند و ما هم كلي به حساب خودمون از اين چارچوبها استفاده كرديم. البته بحث كامل و مفصلي آقاي شكرمن در كتاب خودش كه اخيرا ديدم به زبان فارسي هم ترجه شده، داره ولي از اونجايي كه قرارمون اينه كه اينجا كمتر به تئوري بپردازيم و بيشتر مباحث عملي رو مطرح كنيم، مي خوام چند تا پست رو به اين موضوع اختصاص بديم البته اگه مشاركت كنيد خيلي ممنون ميشم. خوب ميگن چارچوب نحوه تفكر معمار نشون ميده و افكار همه رو منظم ميكنه تا سازمان رو به مؤلفه هايي خوش تعريف بشكنند و با توصيف روابط اين مؤلفه ها يكپارچگي رو در مدلهاي نهايي معماري ايجاد كنند و همچنين نگهداشت مدلها رو تسهيل كنند. خوب اينا حرفاي خوبين ولي با نگاهي به چارچوبها متوجه تفاوت جدي اونها ميشيم. چارچوب زيبا و انتزاعي و البته در عمل خشك زكمن كجا و چارچوب خوش دست و روان دولت فدرال كجا!!! خوب ميشه گفت هر چارچوبي خواستگاهي داره و با هدف خاصي ايجاد شده. يعني در واقع ايجاد كنندگان اون ديدند چطور براي يك مسأله خاص مي تونند مؤلفه هاي خوش تعريف ايجاد كنند و معماري رو بر اون اساس بچينند. خوب چارچوب زكمن يه ديدگاه منطقي و شبيه جدول مندليف داره و به قول خودش نرماله و به نظر من هيچ چيزي مثل چارچوب زكمن مفهوم معماري را منتقل نمي كنه. اما نگاهش كه ميكنيد ميگيد خوب باهاش چكار ميشه كرد اين كه در يك سازمان اين ديدگاه ها و اين ابعاد وجود دارند درست ولي به چه دردي مي خوره و چكار عملي ميشه باهاش كرد؟ خوب خود زكمن هم ميگه اين چارچوب اصلا متدولوژي خاصي رو مطرح نمي كنه و فقط يك نگاه ساختاري به اجزاي معماري سازمان هست. جالبه كه در نظرات زكمن راجع به متدولوژي برنامه ريزي معماري سازماني ارائه شده توسط اسپيواك، مي بينيم كه ميگه "من قبل از مطالعه اين متدولوژي نمي تونستم تصورش رو بكنم كه اين چارچوب به چه دردي مي تونه بخوره!". پس نگاه زكمن يه جور نگاه مفهومي و انتزاعي بوده و نه عملي البته اين موضوع هيچ از ارزش كار زيبا و ارزشمند اون كم نميكنه بلكه شايد حسن اونه كه به عنوان مادر اغلب چارچوبها مطرحش كرده. به هر حال يه سؤوال اساسي كه مطرحه اينه واقعا مولفه هاي سازمانهاي مختلف از ابعاد گوناگون نظير ماهيت توليدي يا خدماتي بودن، دولتي يا خصوصي بودن، نوع كسب و كار، نظامي يا غير نظامي بودن و ... ميتونه در كشورهاي مختلف و شرايط متنوع يكي باشه؟ آيا هميشه ميشه گفت اين ديدگاه در دسته بندي موضوعات در قالب چارچوب خوش تعريف ترين نگاهه؟ من شخصا در برخي پروژه ها حس مي كنم لازمه يه چارچوب منطقي كه منبعث از منطق و نوع تفكر معمار راجع به اون سازمانه مطرح بشه و كار معماري رو بر اون اساس انجام داد. نمي دونم واقعا چطور يك معمار مي تونه يك موتور توليد كننده چارچوب براي خودش داشته باشه. شايد اين نگاه يه خورده زيادي انتزاعي باشه . نمي دونم.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-3444262805823553741?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com1tag:blogger.com,1999:blog-2135876353514621288.post-66051288426288336252008-08-23T11:49:00.002+04:302008-08-23T12:08:18.416+04:30آقاي فتح اللهي نكته ي بسيار مهمي رو يادآوري كرد. موضوع خبرگي و توانمندي نيروي انساني در همه فازهاي معماري لازمه علي الخصوص در فاز ترسيم وضعيت مطلوب. تقريبا همه چيزي كه نصيب سازمان ميشه بر ميگرده به توانمندي نيروي انساني در وضع مطلوب. همونطور كه ميدونيد معماري سازماني همه حوزه هاي كسب و كار رو اعم از مالي، نيروي انساني، توليد، بازاريابي، پشتيباني و ... شامل مي شه و كساني كه ميخوان در معماري كسب و كار وضع مطلوب رو ترسيم كنن بايد كاملا به اين حوزه ها مسلط باشند (البته پيش بيني گارتنر هم اينه كه تا چند سال آينده توانايي معماران سازمان بيشتر در حوزه تحليل و معماري كسب و كار خواهد بود). از طرفي چند سال طول ميكشه كه يك نيروي انساني بتونه در هر يك از حوزه ها خبرگي پيدا كنه. راه حل ممكن براي حل اين معضل اينه كه اولا تيم معماري تا حد امكان آشنايي با كليه حوزه پيدا كنند و بتدريج شروع به عميق شدن در حوزه هاي مورد علاقشون بكنند. در كنار اين موضوع استفاده از مشاورين خبره كسب و كار در هريك از موضوعات تخصصي خيلي كارگشا ميتونه باشه خصوصا مشاورين خبره معتبر و شناخته شده در همون تيپ سازماني كه داريد معماريش مي كنيد. مثلا اگر در حوزه نفت كار مي كنيد كساني به عنوان مشاور مثلا مالي استفاده بشند كه در حوزه مسائل مالي نفت معتبر و توانمند هستند. اينجا نقش تيم ثابت معماري اينه كه خوب بتونند بين نظرات مشاورين مختلف يكپارچگي برقرار كنند و يك زبان مشترك بين همه ايجاد كنند كه خيلي هم كار آسوني نيست. البته مسئله استفاده از مشاور در حوزه معماريهاي فني مثل نرم افزار و سخت افزار و شبكه تا حدي آسونتره. چون اين حوزه ها استانداردهاي مشخصي دارند و بيشتر مسايل مطرح در اون از جنس تكنيكي و كمي شده هستند.<br />مسئله اثبات معماريها و ايجاد مقبوليت و اعتبار معماريها در سازمان هم يكي از چالشي ترين مسائل انتهاي فاز مطلوب محسوب ميشه كه دفعه بعد بيشتر سعي ميكنم بهش بپردازم.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-6605128842628833625?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com1tag:blogger.com,1999:blog-2135876353514621288.post-37747905109238064372008-08-13T11:28:00.004+04:302008-08-14T11:05:39.101+04:30راجع به مشكلات ايجاد مدلهاي مطلوب خيلي ميشه حرف زد. اولين مشكل اينه كه واقعا راه رسيدن به مدلهاي مطلوب اصلا يك راه روتين و يكنواخت نيست و به خيلي چيزا بستگي داره. مهمترين چيزي كه توي رسيدن به مدلهاي مطلوب تأثير گذاره همون تحليل مشكلات اول در فاز آماده سازي پروژه است. همون اهدافي كه براي پروژه تعيين شده ميگه كجاها بايد بهبود ايجاد كرد. مثلا اگه هدف معماري كاهش هزينه توليد محصول يا خدمت باشه مسلما بايد مدلهاي مطلوب فرآيندي به گونه اي اصلاح بشن كه اين هدف رو پوشش بدن. حالا ارزيابي اينكه چقدر پوشش دادن اين هدف رو بماند. يا مثلا اگه يكپارچگي اطلاعاتي هدف بوده خوب قطعا مدل داده اي مطلوب بايد پاسخگوي اين هدف باشه. پس رسيدن به مدلهاي مطلوب اصلا فرآيند مشخصي نداره. فقط ميشه يه سري خطوط راهنماي كلي براش تعيين كرد. مثلا يكي از مراجع رسيدن به مدلهاي مطلوب استفاده از بهترين تجارب (Best Practices) است. ميشه براي ترسيم وضعيت مطلوب با توجه به سطح بلوغ سازمان و هزار تحليل ديگه، از تجارب موفق در حوزه معماري هاي كسب و كار، سيستم، داده و فناوري استفاده كرد. من در همه اين حوزه هاي تونستم از تجارب موفق استفاده كنم. مثلا استفاده از الگوهاي استاندارد مدل داده اي، مدل APQC براي فرآيندهاي پشتيبان سازمان، معماري نرم افزار بر اساس ERP ها و غيره. مسأله مهم ديگه براي مدلهاي وضعيت مطلوب يكپارچگي مدلها است. يعني اينكه اگر جايي فرآيندي اصلاح ميشه بايد اثر اين تغيير در مدل داده اي، سيستمهاي اطلاعاتي، شبكه و ... ديده بشه. اصل كار معماري همينه كه راه حل هاي يكپارچه رو براي نيازمنديهاي شناسايي شده براي سازمان ارائه بده.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-3774790510923806437?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com1tag:blogger.com,1999:blog-2135876353514621288.post-75198955085607764342008-07-30T01:14:00.003+04:302008-07-30T01:35:45.667+04:30سلام من برگشتم. از وقفه طولاني مدت پوزش ميخوام. ميخوام يه خورده از مشكلات دسته اول بگم. خوب اگه محصولات معماري رو به 3 دسته محصولات و مدلهاي وضع <span style="color:#000000;">موجود، مطلوب و گذار تقسيم</span> كنيم براي اينكه محصولات درست و مناسبي براي هر حوزه داشته باشيم مسائل و مشكلات متفاوتي پيش رو هست.<br /><strong><span style="color:#000099;">مشكلات موجود براي دستيابي به مدلهاي وضع موجود:</span></strong> معمولا مدلهاي وضع موجود بر اساس اطلاعات مصاحبه با مديران و كارشناسان سازمان، مطالعه اسناد سازماني و پرسشنامه هاي توزيع شده بدست مياد. خوب هر كدوم از اينها آفت هايي دارند مثلا در مورد اطلاعات مصاحبه ها فرد طرف مصاحبه مهمه كه اطلاعاتش چقدر درست و قابل استناد هست و اصولا شخصيت معتبري در سازمان به حساب مياد يا نه؟ حب و بغض سازماني داره؟ و ... از يه طرف مصاحبه كننده هم مهمه كه آيا تجربه و تسلط لازم رو براي گرفتن اطلاعات و درك مطالب داره يا نه. توصيه ميشه فرد مصاحبه كننده با اون حوزه ايي كه ميخواد مصاحبه كنه بخوبي آشنا باشه تا بتونه اعتماد مصاحبه شونده رو براي دادن اطلاعات خوب جلب كنه. اسناد سازماني مورد استفاده در شناخت وضعيت موجود هم بايد بررسي بشه كه توسط چه تيمي و با چه هدفي ايجاد شدن؟ چقدر معتبر و مورد استناد سازمان هستن؟ چقدر با واقعيتهاي جاري سازمان تطابق دارند؟ بروز هستن يا نه؟ در مورد پرسشنامه تجربه در سازمانهاي ايراني نشون داده خيلي اطلاعات مفيدي نميده. چون ما ايرانيها اصولا با نوشتن مشكل داريم و نتايج اين روش با بي حوصلگي، قصد رفع تكليف، ترس از عواقب اطلاعات مستند شده و ... همراهه بنابراين در سازمانهاي با سطح بلوغ بالا جواب ميده كه تو ايران خيلي كم هستند.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-7519895508560776434?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com2tag:blogger.com,1999:blog-2135876353514621288.post-82257854349424089862008-01-19T14:56:00.000+03:302008-01-19T15:04:06.263+03:30<div dir="rtl" align="right">براي دسته بندي مشكلات معماري بد نيست به نظر دكتر اسپيواك هم اشاره كنم اسپيواك در فصل 2 كتاب خودش (EAP) مي گه: يك پروژه معماري وقتي موفقه، كه شرايط زير موجود باشه:<br />1. معماري سازماني كامل انجام شده باشه. درصد بالايي از سازمان‌هايي كه تلاش مي‌كنن معماري‌ها و طرح‌هاي سازمان خود را تعريف كنن، هرگز اين فرآيند را كامل انجام نمي دن.<br />2. طرح هاي ايجاد شده پياده‌سازي بشن. معماري‌ها و طرح‌هاي كامل شده بايد مجوز اجرا داشته باشن و بعد پياده‌سازي بشن. طرح‌هايي كه كامل شدن ولي در قفسه‌ها باقي موندن، قطعا نمي تونن موفق باشن.<br />3. معماري‌ها براي راهبري توسعه نوين مورد استفاده قرار مي‌گيرن، بنابراين بايد نگهداشت و بروز بشن. معماري‌ها، خروجي‌هاي جامع براي راهبري و هدايت توسعه سيستم‌ها هم به صورت كوتاه مدت و هم بلند مدت هستند. معماري‌ها به عنوان استانداردهايي بكار مي رن كه بايد از اونها پيروي كرد. براي‌ اين كه معماري‌ها معتبر و مفيد باقي بمونن بايد نگهداري و بروز رساني بشن.</div><div dir="rtl" align="right">بنا براين همون دسته بندي خودمون هم تقريبا خوبه مورد اول مربوط ميشه به تدوين محصولات يا همون پروژه معماري سازماني و موارد دوم و سوم به اجراي نتايج يا به عبارت ديگه فرآيند معماري سازماني اشاره داره كه بعد از تدوين محصولات و نتايج مطرح ميشه. اسپيواك مطالب خوبي در زمينه مورد اول يعني مشكلات پروژه معماري سازماني ارائه كرده. سعي ميكنم بيشتر با استفاده از نظرات ايشون و برداشتهاي خودم بهش بپردازم البته با توجه به شرايط سازمانهاي ايراني.</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-8225785434942408986?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com2tag:blogger.com,1999:blog-2135876353514621288.post-62014683545550821002008-01-10T14:48:00.001+03:302008-01-10T15:15:34.343+03:30<div align="right">ضمن تشكر از نظرات ارزشمند دوستان، تصميم گرفتم يه بحث جديد با عنوان بالا باز كنم. واقعا چه چالشهايي براي موفقيت يك پروژه يا بهتر بگيم فرآيند معماري سازماني وجود داره؟ از ديدگاه من يك پروژه معماري سازماني وقتي موفقه كه اولا خروجي ها و نتايجش به اندازه كافي درست و ارزشمند باشند و دوما اين خروجيها اجرا بشند. با اين تفكر ميشه مشكلات رو به دودسته تقسيم كرد<br />اول- مشكلات موجود براي رسيدن به محصولات به اندازه كافي خوب<br />دوم- مشكلات موجود براي اجراي نتايج معماري<br />كه هر دو شون به يك اندازه ميتونن خطرناك ومشكل آفرين باشند. با اين نگاه سعي ميكنم در هر دو حوزه نظراتي رو مطرح كنم. از دوستان خواهش ميكنم در اين بحث شركت كنند و كمك كنند به نتايج بهتر برسيم.</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-6201468354555082100?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com3tag:blogger.com,1999:blog-2135876353514621288.post-11690294803480804582008-01-03T14:22:00.000+03:302008-01-04T22:21:31.129+03:30<div align="right"><span >بطور كلي هر پروژه معماري به صورت عام اهدافي رو دنبال مي كنه يا به عبارت ديگه فوايد عامي داره كه مي تونيد اين اهداف رو مفصلا در </span><a href="http://www.enterprise-architecture.info/"><span >سايت آقاي شِِكِرمن</span></a><span > مطالعه كنيد.<br />اهداف پروژه معماري سازماني يك سازمان بخصوص بايد از تحليل مشكلات و منظور اون سازمان از اجراي پروژه در بياد. پس همونطوري كه قبلا هم گفتم اولين گام تحليل مشكلات سازمانه. اگه يك سازماني باشه كه مثلا فناوري اطلاعات در اولويت نيست و به عنوان هزينه به فناوري اطلاعات نگاه ميشه نه عامل توانمند ساز، خوب تو اين سازمان بايد سعي كنيم مشكلات اساسي مديريت ارشد رو پيدا كنيم و بررسي كنيم آيا ميشه با اين فناوري حلشون كرد؟ اگه بتونيم به مديريت ارشد ثابت كنيم دغدغه هاش رو شناختيم و براي رفعشون راه حل داريم و مثل يك سرمايه گذاري بهش اثبات بشه اگه فلان قدر پول خرج كنه براي اين طرح، فلان+بهمان قدر در مدت مشخصي به نفعش ميشه، قطعا هم جايگاه فناوري اطلاعات در اون سازمان تعيين ميشه و هم پروژه معماري راهش رو درست پيدا ميكنه. يه راه ديگه مطالعه تطبيقي روي كاربرد فناوري اطلاعات در كسب و كارهاي مشابه بين المللي يا رقيبان هست. اگه بتونيم كابردهاي موفق فناوري اطلاعات رو در حوزه كسب و كار سازمان پيدا كنيم و بشكل مناسبي به مديريت ارشد ثابت كنيم روند جهاني در كسب و كاري كه داره مديريتش ميكنه استفاده از فناوري اطلاعاته، اين راه هم ميتونه خيلي كارساز باشه. دكتر اسپيواك (ارائه كننده متدولوژي EAP) هم پيشنهاد كرده بازديد از سازمانهاي مشابه و موفقيت اين پروژه ها مي تونه مؤثر باشه.<br />اگه تو يه سازماني سيستمهاي متعددي وجود داره و سازمان فهميده كه فناوري اطلاعات مي تونه براش مفيد باشه اما تا به حال نتايج موفقي براش نداشته، خوب بايد سعي كنيد بر تأثيرات معماري سازماني در حوزه يكپارچه سازي، انعطاف پذيري و تعامل پذيري سيستمها، تمركز كنيد. يا نشون بديد اگه معماري انجام بشه سيستمها در راستاي تحقق اهداف كلان سازمان شكل مي گيرند. خانم مليسا كوك بحث خوبي رو در </span><a href="http://www.amazon.co.uk/Enterprise-Information-Architecture-Hewlett-Packard-Professional/dp/0134402561"><span >كتاب خودش</span></a><span > مطرح كرده موضوع رويكرد توسعه سيستمهاي عمودي در روشهاي سنتي و رويكرد افقي در روشهاي مبتني بر معماري سازماني. اين بحث هم ميتونه كمكتون كنه تا بتونيد تفاوت رويكرد معماري سازماني رو در توصيف سيستمهاي اطلاعاتي سازمان شفاف كنيد. خانم مليسا كوك ميگه در روشهاي سنتي (رويكرد عمودي)، طراحان سيستم سراغ كاربر (مستقر در واحدهاي سازماني اجرايي) مي رفتن و سيستم رو بر اساس نظرات اون مي ساختند به اين ترتيب هر واحدي بر اساس وظيفه مندي خودش و نيازهاي اطلاعاتي خودش سيستمهاش روش تعريف مي كرد ولي در رويكرد افقي، نيازهاي مديران مياني و ارشد سازمان كه منافع كلان سازماني رو مبتني بر زنجيره ارزش و همكاري واحدهاي مختلف در تحقق اين زنجيره، پي گيري مي كنند در نظر گرفته ميشه و سيستمها بر اون اساس ايجاد مي شن. در نتيجه اگه مثلا (اين مثال نقل از علي فتح اللهي دوست عزيزمه) اطلاعات مشتريان هم در واحد فروش و هم در واحد خدمات پس از فروش بكار ميره توليدش در يك سيستم پيش بيني ميشه و سيستم ديگه با تعامل به اين اطلاعات دسترسي پيدا ميكنه.<br />اگه در سازمان ديگه اي ريشه مشكلات در زيرساختهاي شبكه و ... هست خوب بايد رو اين تمركز كرد كه همه مؤلفه در معماري بصورت متناسب و هماهنگ با هم توصيف ميشن. مثلا معماري شبكه بر اساس نيازمندي كه سيستمهاي اطلاعاتي در آينده ايجاد مي كنن توصيف ميشه ولي در عين حال در معماري سيستمهاي اطلاعاتي هم راه حلهاي امكان پذير براي شبكه در نظر گرفته ميشه.<br />اگه سازماني مشكل بالا بودن هزينه داره و ميخواد با فناوري اطلاعات هزينه ها رو كم كنه، بايد تمركز پروژه رو بر حذف كارهاي زايد (اصلاح فرآيندها)، استفاده بهينه از نيروي انساني از طريق تعريف نظامهاي ارزيابي عملكرد كاركنان و ...، استفاده بهينه از منابع سازماني با استفاده از اطلاعات دقيق و بهنگام و ... قرار داد.<br />در آخر استفاده از رويكرد (LFA(Logical Framework Approach رو براي تعريف اهداف معماري سازماني توصيه مي كنم. خودم اين روش رو در چند پروژه استفاده كردم. خيلي مفيد بوده. اگه اطلاعات كاملتر خواستيد مطرح كنيد.</span></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-1169029480348080458?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com1tag:blogger.com,1999:blog-2135876353514621288.post-65321716663845343562007-12-30T18:48:00.000+03:302008-01-04T22:43:15.449+03:30<div align="right">متاسفانه در حوزه معماري سازماني هم مثل اغلب حوزه هاي مشابه (ايزو، ...) در كشور تمركز بر راه حل يعني معماري سازماني وجود داره نه مشكلاتي كه معماري ميتونه حل كنه. معمولا در سطح جهاني اول يك مشكل و مسأله تعريف ميشه بعد ميرن دنبال راه حل. ولي در كشور ما خيلي ها نمي دونن اصلا مشكل سازمان چيه ولي شنيدن مثلا مهندسي مجدد فرآيندها خوبه، معماري سازماني مفيده و ... و به همين دلايل پروژه تعريف مي كنن. خوب پيمانكارهاي اين حوزه هم تو اين بازار خراب از پروژه بدشون نمياد لذا پروژه هاي معماري رو معمولا بدون هدف مشخص و صرفا بر اساس يك سري كليات اجرا مي كنند. نتيجه اين موضوع هم ميشه وضعي كه الان پروژه هاي معماري سازماني در كشور دارن. خيلي از سازمان ها بخاطر مد شدن اين مفاهيم ميرن سراغ تعريف پروژه، بعضي ميخوان چيز جديدي ياد بگيرن، بعضي ها هم مي خوان با تعريف اين پروژه ها مسؤوليت خودشون رو بندازن گردن پيمانكار پروژه و روزگارشون رو تا عوض شدن مدير فعلي و اومدن مدير جديد بگذرونند. از همه اينا كه بگذريم بهتره اول پروژه معماري سازماني يا اول هر پروژه اي، ابتدا يك تحليل مشكل انجام بشه و بعد بر اساس درخت مشكلات اهداف پروژه تعيين بشه و واقعا مشخص بشه پروژه چطور و با چه مكانيزمي مي خواد مشكلات رو حل كنه. اگه اين موضوع رو بتونين براي كارفرماها روشن و دقيق كنين اونا هم انتظاراتشون از پروژه منطقي و واقعي ميشه. مثلا برخي از مشكلات سازمان ممكنه ريشه در مديريت ضعيف نيروي انساني، اهميت ندادن به نيروي انساني و هزارتا چيز ديگه داشته باشن كه واقعا يك پروژه معماري با شرح خدمات معمول اين پروژه ها در ايران نمي تونه مستقيما اونا رو حل كنه. درسته معماري يك مخزن از كليه متغيرهاي سازمان ارائه مي كنه كه ميتونه براي بهبود در همه حوزه ها بدرد بخوره ولي اين آيا جواب انتظارات كارفرمايي رو كه مي خواد همه مشكلاتش بعد از گذشت 8 يا 10 ماه از شروع پروژه حل بشه، برطرف ميكنه؟ تعيين اهداف معماري اثر مستقيم و زيادي در چارچوب، متدولوژي، عرض و عمق معماري و حتي نوع تخصصهاي نيروي انساني پروژه داره. بنابراين به عنوان اولين گام در تعريف پروژه در مرحله تدوين سند چشم انداز، طرح مديريت پروژه، پيوست فني قرارداد يا هر اسمي كه روي خروجي فاز آماده سازي مي ذاريد، بايد انجام بشه. معمولا براي پروژه هاي معماري سازماني اهداف و گرايشهاي خاصي به صورت پيش فرض در بعضي چارچوبها و روشها وجود داره. مثلا چارچوب وزارت دفاع آمريكا چند تا هدف رو مثال زده : مهندسي مجدد فرآيندها ، حاكميت فناوري اطلاعات و ... كه ميتونه به عنوان گرايشهاي مطرح در پروژه مطرح باشه. ميشه از اين الگوها ايده گرفت ولي انجام يك تحليل مشكل دقيق قويا توصيه مي شه. اگه مطلب تكميلي مي خواهيد در اين زمينه بپرسيد جواب مي دم. سعي مي كنم دفعه بعد يه خورده بيشتر اين موضوع رو باز كنم.</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-6532171666384534356?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com3tag:blogger.com,1999:blog-2135876353514621288.post-20331012668253624392007-12-28T23:25:00.000+03:302008-01-04T22:34:24.179+03:30<div align="right">در اين وبلاگ سعي دارم از مسائل و چالش هاي عملي معماري سازماني صحبت كنم. تا كنون مطالب تئوري و علمي بسياري چه در سطح جهاني و چه در كشور در اين حوزه ارائه شده و تقريبا راجع به مفاهيم معماري سازماني مطالب خوبي وجود داره ولي اينكه واقعا چطور ميشه اين مطالب رو در عمل پياده سازي كرد چالشي است كه هم در سطح جهاني و در كشور به صورت شديدتر وجود داره. با توجه به تجربه اندكي كه خودم در پروژه هاي اجرايي كسب كردم سعي مي كنم به چالش هاي اساسي اين حوزه بپردازم. اميدوارم اين وبلاك جايي باشه براي تعامل كساني كه بصورت عملي به دنبال تحقق اهداف معماري سازماني هستند.</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/2135876353514621288-2033101266825362439?l=ea-in-practice.blogspot.com' alt='' /></div>شهرام جلالي نياhttp://www.blogger.com/profile/14046624058820294861noreply@blogger.com1