شکل ۲-۵ چرخه پیاده سازی حاکمیت SOA بر اساس چارچوب پیشنهادیIBM[62]
چرخه پیاده سازی حاکمیت SOA بر اساس چارچوب پیشنهادی IBM شامل چهار مرحله برنامه ریزی، تعریف، استقرار و سنجش می باشد.)شکل ۶) این چارچوب طی یک رویکرد تکرار پذیر از طریق تعریف فرایندهای حاکمیت، تعریف رویکردهای توسعه و مدیریت پروژه، تعریف معیارهای ارزیابی سطوح سرویس و اجرای طرح حاکمیت SOA به اجرای حاکمیت معماری سرویس گرا می پردازد.
(Muriankara. ٢٠٠٨, (;( Brown et at ٢٠٠۶.)

چارچوب حاکمیت معماری سرویس گرا در دیدگاه Oracle
مدل حاکمیت SOAاز دیدگاه Oracle تمرکز معماری سازمانی در ابعاد مختلف کسب وکار، برنامه، اطلاعات و تکنولوژی است . بر این اساس Oracle حاکمیت معماری سرویس گرا را تلفیقی از معماری سرویس گرا ، معماری سازمانی و کسب و کار می داند و مدل حاکمیت خود را مبتنی بر تعریف سیاست ها و خط مشی ها در ابعاد مختلف کسب وکاری، سازمانی و تکنولوژی ارائه کرده است. بنابراین تدوین سیاستها و فرایندها در حوزه های معماری، اطلاعات، تکنولوژی، مدیریت پروژه و عملیات به عنوان عناصر کلیدی چارچوب ومدل حاکمیت معماری سرویس گرا از دیدگاه Oracleتلقی میشود (ORACLE,2008). این چارچوب یک فرایند تدریجی را برای حرکت به سمت استقرار حاکمیت SOA مطرح میکند.در این رویکرد که بر اساس بلوغ سرویس گرایی سازمان و منطبق بر مدل بلوغ قابلیت یکپارچگی تعریف شده است یک فرایند تدریجی در ۶ گام مسیر حرکت سازمان را مشخص میکند. این فرایند ۶ مرحله ای پس از معرفی حوزه های حاکمیت ارائه می شود.شکل ۲-۷ نقاط کلیدی برای سیاست گذاری در حاکمیت معماری سرویس گرا را از دیدگاه Oracle نشان می دهد.

۳۶

شکل ۲-۶ نقاط کلیدی برای سیاست گذاری در حاکمیت معماری سرویس گرا را از دیدگاه Oracle[37]
Oracle موفقیت و پذیرش و استقرار معماری سرویس گرا در سطح سازمان را منوط به تدوین سیاست ها و فرایند ها برای همه ی نقاط کلیدی نشان داده شده بالا میداند.در زیر شرح مختصری از هرکدام میدهیم:
معماری
معماری مطلوب یک سیستم منسجم با قابلیت نگهداری و پشتیبانی بالا را فراهم میکند و مارا از اشفتگی زیرساخت دور می سازد.[۴۶] دسته بندی سرویس ها ,مدل داده ای واسط بین سرویس ها ,استفاده از الگوهاو استاندارد ها و قوانین ,شفاف سازی مسئولیت ها ووظایف در حوزه معماری از جمله مواردی است که در سیاستها ی معماری بایستی مدنظر قرار گیرد.اوراکل در چارچوب خود تدوین سیاست های معماری را قبل از حرکت به سمت معماری سرویس گرا ضروری می داند[۳۷]. اوراکل پیشنهاد نموده که استانداردها ,سیاست ها وفرآیند ها به صورت مرکزی و تحت کنترل یک واحد انجام تدوین شود تا از دوباره کاریها و بدفهمی ها جلوگیری شود .بی توجهی به سیاست های معماری در سازمان منجر به ساخت سرویس های غیرقابل استفاه و عدم انعطاف پذیری معماری خواهد شد.
۳۷
تکنولوژی
در این دیدگاه تکنولوژی مشابه سایر مولفه های حاکمیت بایستی به طور شفاف تعریف شده و مدیریت شود تا با ارائه استانداردها و راهکارهای فنی در خصوص توسعه سرویس ها و ارتباط بین انها از توسعه سرویس های ناسازگار با تعامل ضعیف جلوگیری شود.اگر هر یک از تیم های پروژه به طور مجزا از پلتفرم خود بدون یکپارچگی یا اشتراک مولفه ها با سایر تیم ها یا استفاده از معماری استاندارد استفاده کند دیگر شانسی برای ساخت برنامه های مرکب قابل اطمینان و امن وجود نخواهد داست.
اطلاعات با توجه به قواعد و اصول ارتباطی بین داده ها و کیفیت داده ها در برنامه ای مبتنی بر سرویس ضروری است.عدم توجه به اصول و قواعد مرتبط با اطلاعات منجر به کیفیت ضعیف داده و ناسازگاری انها می شود که نهایتا باعث تحلیل نادرست و عدم پوشش نیازمندی های کسب و کاری خواهد شد.
مالی
بواسطه ی تدوین و اجرای این سیاست ها سازمان میتواند :زیرساخت های سخت افزاری و نرم افزاری را به اشتراک بگذارد,چالش های سرمایه را مرتفع سازد,متولی سرمایه گذاری را مشخص کندلذا سیاست های مالی را جز مولفه های اصلی چارچوب حاکمیت SOA معرفی میکند.
پورتفولیو
اوراکل قانونمند کردن سیاست ها و خط مشی ها در چارچوب حاکمیت را در۳ نوع پورتفولیو پیشنهاد میکند که عبارتند از:
پورتفولیوی سرویس های (ابزارها) فنی وکسب و کاری
پورتفولیوی پروژه ها
پورتفولیوی برنامه های کاربردی سازمان مثل ERP
هم سویی بین طرح های استراتژیک کسب و کار و فناوری اطلاعات ضروری است .لذا سیاست ها بایستی از طرح های استراتژیکی که اهداف کسب و کار و فناوری اطلاعات را یکپارچه نموده اند استخراج شود.در صورتیکه سازمان نتواند یک پورتفولیوی مناسب منطبق بر استراتژی های کسب و کار و فناوری اطلاعات تدوین نماید سازمان با حجم زیادی از سرویس ها و برنامه های خریداری شده و … مواجه خواهد شد که مزایای مورد انتظار SOA راحاصل نخواهد کرد.
۳۸
اشخاص
معمولا افراد درگیر در حاکمیت معماری سرویس گرا شامل نمایندگانی از حوزه های مختلف کسب وکار ومالی ومعماری هستند.با توجه به اینکه عدم توجه به اصول مدیریتی سازمان به دلیل ناتوانمندی افراد منجر به کند بودن روند پذیرش معماری سرویس گرا می گردد. لذا اموزش مدیران و کلیه ی ذینفعان معماری سرویس گرا یکی از اصلی ترین موضوعات سیاستگذاری در این حوزه مطرح شده است.اموزش میتواند در خصوص شناخت استاندارد ها , سیاست ها , روال های حاکمیت ,معماری های مرجع ,سند معماری نرم افزار و نقش ها و مسئولیت ها ی تیمهای مختلف در طی توسعه سرویس , تست , استقرار و نگهداری صورت گیرد.
اجرای پروژه
معماری سرویس گرا بر چگونگی اجرای پروزه ها تاثیر به سزایی دارد . برای کلیه ی پروژه ها , چه انهایی که با تکنولوژی SOA سازگار نیستند و چه سیستم هایی که که بامعماری سرویس گرا طراحی میشنود , بایستی سیاست ها و محدودیت هایی اضافه شود تا قابل اجرا باشد .
عملیات
سرویس هایی که در بین واحد های مختلف سازمان به اشتراک گذاشته می شوند پیچیدگی های عملیاتی زیادی دارند که لازم است به عنوان سیاست مشخص به انها پرداخته شود .اجرای سیاست ها ی عملیاتی از دیگر جنبه های حاکمیت SOA است که خیلی از شرکت ها از جمله اوراکل به ان توجه داشته اند.تمرکز این چارچوب برحوزه های مختلف سیاستگذاری و حاکمیتی است و به نقشها و مسئولیتها به عنوان یکی از مولفه های اصلی چارچوب حاکمیت توجه کمتری شده است. به دلیل دسته بندی موضوعی سیاستها و حوزه های حاکمیت ، این چارچوب جامعیت بیشتری نسبت به چارچوب IBM دارد.[۸]
۲-۱۳-۴-چارچوب حاکمیت معماری سرویس گرا در دیدگاه Software AG
Software AG شناخت و کنترل مصنوعات را عاملی برای موفقیت SOA میداند و کلید ان را حاکمیت SOA است [۵۱]. مشابه Oracle و IBM چارچوب ارائه شده توسط Software AG مبتنی بر بهترین تجارب است. این چارچوب بر اساس یک استراتژی پیاده سازیSOA مطرح شده است. این چارچوب اجرای سیاست ها را در طول چرخه حیات سرویس از مرحله طراحی تا اجرا و تغییر امکان پذیر می سازند. این چارچوب نسبت به اجزا و زیرساخت تکنولوژی شرح کاملی اورده است.. از مهمترین مؤلفه های فنی سیستم مدیریت سیاست است که اتوماسیون اجرای سیاستها در چرخه حیات فرایند های مهم ان و مدیریت و اجرای سیاستها، مدیریت سطح خدمات و مدیریت محصولات معماری سرویس گرا هستند. سرویس را بر اساس نقاط کنترلی سیاست تعریف شده در هر مرحله انجام می دهد .(Castaldini,2008) پشتیبانی از استانداردهای معماری سرویس گرا و امنیت ,مدرن سازی سیستمهای قدیمی و توسعه برنامه ها با ترکیب سرویس ها وجوددارد.مسئولیت ها و نقش ها مرتبط با افراد و ذینفعان مختلف برای هر یک از فرایندها ارائه شده است.چارچوب ارائه شده شامل مولفه های زیر است:[۵۱,۵۲[
۳۹
چرخه حیات حاکمیت و چرخه حیات سرویس
چرخه ی حیات شامل سه مرحله ی طراحی , اجرا و تغییر است که حاکمیت مبتنی بر این چرخه اجرا می شود.سه نوع حاکمیت زمان طراحی ,زمان اجرا و زمان تغییر برای این چرخه ی حیات تعریف شده است.که در زیر شرح مختصری اورده شده است.
حاکمیت زمان طراحی
در حاکمیت زمان طراحی عمدتا سیاست ها مربوط به طراحی سرویس ها منطبق بر استانداردها و سیاستهای لازم برای تایید و پذیرش سرویس هاست.[۵۱]
حاکمیت زمان اجرا
حاکمیت زمان اجرا شامل تعریف الزام سیاست های کنترلی برای استقرار و به کارگیری و عملیاتی سازی سرویس هاست.این سیاستها مرتبط با مدیریت کیفیت سرویس,اعتبار سنجی و کارایی سرویس است.سیاستهای زمان اجرا همچنین شامل نظارت بر SLA وتهیه گزارش لازم است.این گزارشات مربوط به عدم تطابق سطح واقعی کارایی سرویس با نیازهای تعریف شد در سند SLA است.
حاکمیت زمان تغییر
حاکمیت زمان تغییر مدیریت سرویس ها دردوره ی تغییر است که معمولا نسبت به حاکمیت زمان طراحی طول عمر بیشتری دارد.
تکنولوژی
۴۰
در حوزه ی تکنولوژی چارچوب ارائه شده توسط AG SOFTWARE شرح نسبتا کاملی از مولفه ها و اجزای زیرساخت ارائه نموده است.ازمهمترین مولفه های فنی سیستم مدیریت سیاست است که اتوماسیون اجرای سیاستها در چرخه ی حیات سرویس را بر اساس نقاط کنترلی سیاست تعریف شده در هر مرحله انجام میدهد.مکانیزم های کنترلی در این حوزه قابل تعریف است و مدیریت و اجرای سیاستها, مدیریت سطح خدمات و مدیریت مصنوعات SOA به عنوان فرایندهای مهم مطرح شده است.[۵۱]
جنبه های مختلف یک مدل حاکمیت SOA دراین چارچوب مطرح شده است. در مقایسه با سایر چارچوب ها جامع تر بوده و به جزییات بیشتری در مورد مولفه ها بالاخص از بعد تکنیکال و فنی پرداخته است. در زمینه ی معیار ها و سنجه های ارزیابی و فرایند های مربوط به ارزیابی , دچار ضعف است و در مقایسه با IBM وORACLE که به صورت مجزا به موضع مدیریت و نظارت در چرخه ی حیات پرداخته اند دارای کمبود است.

چارچوب حاکمیت معماری سرویس گرا در دیدگاه Bieberstein