كه داراي اجزايي است كه قابليت استفاده مجدد را دارند.
همان‌طور كه قبلاً ذكر شد، فرآيندهاي سازمان‌ها طيف‌هاي مختلفي دارند كه از عمليات ساده يك يا چند گامی فاقد ساختار مشخص گرفته تا فرآيندهاي كلان و مركزي سازمان را شامل مي‌شوند. مايكروسافت، يك معماري براي سيستم مدیریت فرآیند کسبوکار خود در نظر گرفته است كه بتواند تمامي طيف‌هاي فرآيندهاي سازماني را پوشش دهد (شکل 2-13)[37].

شکل 2-13 مدل معماری مفهومی سیستم مدیریت فرآیند کسبوکار مایکروسافت[37]
سرویسدهنده تعاملی: یک سرویسدهنده تعاملی (مانند Microsoft Office SharePoint Server) برای خودکارسازی فرآیندهای فردی یا تیمی بهکار میرود، و به کاربران کمک میکند تا وظایف فردی (مانند بازبینی یا تائید یک مستند) در یک سازمان و یا وظایف تیمی آنها با یکدیگر با اتوماسیون بالا انجام گیرد. همچنین سرویسدهنده تعاملی با قابلیت سرویسدهی به تیمهایی با پراکندگی جغرافیایی، قابلیت اشتراکگذاری مستندات و مدیریت محتوای آن‌ها در چرخهحیاتشان را ارائه میدهد.
سرویسدهنده فرآیند: یک سرویسدهنده فرآیندی (مانندMicrosoft BizTalk Server) قابلیتهای خودکارسازی و پایش فرآیندها را ارائه میدهد. این قابلیتها در خودکارسازی فرآیندهای میان تیمی استفاده میشوند؛ در این نوع فرآیندها انواع سیستمهای اطلاعاتی و شرکای تجاری مطرح میشوند. این سرویسدهنده قابلیت اتصال و یکپارچگی با سیستمهای نامتجانس دیگر را دارد و ابزارهایی را ارائه میدهد که از طریق آنها میتوان کارایی کسبوکار سازمان را از طریق برخی مقیاسها در هر لحظه اندازهگیری نمود. به این کار پایش فعالیتهای کسبوکار نیز گفته میشود.
فناوریهای هر دوی این سرورهای لایه میانی بر اساس چشمانداز یک مدل برنامهنویسی یکپارچه (بر اساس Microsoft.NET و چارچوبهای متداول) ساخته شدهاند؛ و همچنین به عنوان ابزار مشترکی برای توسعه و نظارت بر فرآیندهای کسبوکار میباشند.
2-4-2-1 بخش‌هاي اصلي مربوط به يك BPMS [1]
(Process)Workflow Engine: موتور گردش كار مورد استفاده در BPMS مي‌بايست امكان طراحي بر اساس BPMN را فراهم كرده و امكان ايجاد اسكريپت‌ها (و در صورت امكان نمودار) BPEL را در جهت هماهنگ نمودن سرويس‌هاي مورد نياز فراهم آورده و قابليت ارزيابي نمودارهاي طراحي شده را دارا باشد.
Human Interaction: بعضي از BPMSها امكان تعامل ميان كاربر و فرايند را از طريق فرم‌هايي كه به صورت خودكار و يا به صورت دستي توليد مي‌شود فراهم مي‌كنند، بدون پشتيباني اين قابليت امكان تعامل كاربر (ورود اطلاعات و مشاهده نتايج) با فرايند در حال اجرا وجود ندارد.
Business Rule Engine: به منظور امكان تعريف و استفاده از نودهاي شرطي در نمودار BPM، وجود يك موتور قاعده با قابليت تشخيص عبارت Boolean(False,True) و عبارت‌هاي تناسب (=) الزامي است.
Enterprise Service Bus (ESB): گذرگاه سرويس، زيرساختي است كه موتور مربوط به سرويس‌هاي مختلف بر روي آن سوار شده و قابليت تحليل سرويس‌هاي مختلف در آن فراهم مي‌گردد و امكان يكپارچه‌سازي سيستم موجود را با ساير سرويس‌هاي موجود در سازمان كه استانداردهاي مربوطه را پشتيباني مي‌كنند، فراهم مي‌كند.
Portal: به منظور فراهم شدن امكان تعاملات كاربري با سرويس‌هاي پياده‌سازي شده، و مديريت اجراي صفحات واسط كاربري، معمولاً از برنامه‌هاي كاربردي مبتني بر وب استفاده مي‌شود.
Application/Web Server: بستري است كه امكان برقراري ارتباط و استفاده از سيستم نهايي را فراهم مي‌آورد و تمامي ابزارهاي BPMS آن‌را شامل مي‌شوند.
2-4-2-2 بخش‌هاي جانبي مربوط به يك سيستم BPMS [1]
process simulation: در تعدادي از BPMSها امكاني جهت شبيه‌سازي و آزمون اجرا گردش فعاليت‌هاي سازمان در جهت شناسايي نقاط ضعف و تنگناهاي مربوط به منابع سيستم وجود دارد.
Form Generator: در بعضي از سيستم‌ها فرم‌ها به صورت خودكار با توجه به فرايندهايي كه ترسيم شده است، توليد مي‌شوند. البته فرم‌هايي كه از اين طريق توليد مي‌شود معمولاً بسيار ساده بوده و كاربر پسند نمي‌باشند.
:Form Designer در تعدادي از BPMSها امكاني گرافيكي در جهت طراحي فرم‌هاي دلخواه به عنوان واسط كاربري وجود دارد.
:Report Designer اين ابزار امكان طراحي گزارشات مورد نياز را فراهم مي‌آورد.
:Monitoring Tools اين ابزار امكان پايش، هر فرايند را در حين اجرا فراهم مي‌آورد و با استفاده از اين قابليت مي‌توان مرحله اجراي هر نمونه از فرايند را كنترل كرد.
Enterprise Content Management(ECM): اين ابزار امكان مديريت مستندات، مديريت ركوردها، مديريت… را فراهم مي‌آورد.
Access Control: اين ابزار امكان كنترل دسترسي براي كاربران و گروه‌هاي تعريف شده را فراهم مي‌آورد.

2-5 مدیریت فرآیند کسبوکار و معماری سرویسگرا
در رابطه با ادغام و ترکیب مدیریت فرآیند کسبوکار و معماری سرویسگرا متخصصین این دو حوزه نظریههای مختلفی داشته که در ادامه به برخی از آن‌ها میپردازیم[47]:
طبق نظر مایکل پولین47 ادغام مدیریت فرآیند کسبوکار و معماری سرویسگرا طی سه الی پنج سال آینده رخ خواهد داد زیرا معماری سرویسگرا از مفاهیم فناوری اطلاعات خارج شده است و در قالب کسبوکار ظاهر خواهد شد. همچنین بنا بر نظر جان مایکسلون48 ادغام مدیریت فرآیند کسبوکار و معماری سرویسگرا در حال شکلگیری است چرا که دولتهایی همچون آمریکا و اروپا سرمایههایی را به این موضوع اختصاص دادهاند و طی دو سال آینده ارتباط این دو با یکدیگر کاملاً مشخص خواهد شد. از طرفی طبق نظر میکو ماتسومورا49 اتصال قوی بی
ن مدیریت فرآیند کسبوکار و معماری سرویسگرا وجود دارد و بهتر است به جای ادغام از کلمه مزدوج استفاده شود، زیرا هر دوی آن‌ها درباره کسبوکار فناوری خوب سخن میگویند. پس اگر این دو جفت شوند، آنگاه فناوری کسبوکار کاملتر خواهد شد.
از طرفی برخی بر این باورند که مدیریت فرآیند کسبوکار و معماری سرویسگرا مکمل یکدیگرند به طوری که در [8] اشاره شدهاست معماری سرویسگرا رابطه تنگاتنگی با مدیریت فرآیند کسبوکار دارد؛ و بررسی ارتباط و چگونگی تعامل این رهیافتها میتواند موضوع جالبی برای پایاننامههای متعددی در دنیا باشد. همچنین بنا به نوشته [48] معماری سرویسگرا و مدیریت فرآیند کسبوکار اگر به مانند یک واحد شوند آنگاه مفیدتر ظاهر میگردند زیرا در اهداف عمومی مشترک هستند و چالاکی سازمان را افزایش میدهند و نتایج کاراتری را به دنبال دارند.
مفاهیم فرآیند کسبوکار میتوانند به راحتی با سرویسهای تکنیکی دانه دانه درون سرویسهای مرکب ترکیب و پیادهسازی شوند. همان‌طور که مفاهیم کسبوکار یا توالی فرآیندها تغییر میکنند، سرویسها نیز میتوانند مجدداً ترکیب و به ترتیب قرار گیرند یا حتی میتوانند برای تولید نیازمندیها جایگزین شوند. [41]
اگرچه معماری سرویسگرا و مدیریت فرآیند کسبوکار متمم هستند ولی نسبت غیرمستقیمی با هم دارند. مدیریت فرآیند کسبوکار مجموعه سطوح بالای اصول و قوانین مدیریت و معماری سرویسگرا مجموعه سطوح پایینتر قواعد تکنیکی میباشد[8].
مدیریت فرآیند کسبوکار برای بالا بردن قابلیت انعطاف به طراحی فرآیند نیاز دارد. بنابراین سیستمهای جامع برنامههای کاربردی به رشد خودکار فرآیندهای قابل انعطاف نیاز دارند. این جامعیت نیازمند ایجاد استقلال بین فرآیندها و پیادهسازی سرویس است تا اتصال محکم بین یکپارچگی برنامههای کاربردی کسبوکار را حذف نماید؛ لذا لزوم این اتفاق ظهور معماری سرویسگرا است[49].
در [50] یک چارچوب یکپارچه برای سیستمهای مدیریت فرآیند کسبوکار و معماری سرویسگرا با هدف به حداکثر رساندن افزایش چابکی فرآیندهای کسبوکار به صورت بلادرنگ ارائه نمودهاند. دیدگاه کلی چارچوب پیشنهادی آن‌ها از ترکیب چهار گروه پویای فرآیند کسبوکار (محتوای کسبوکار، هوش کسبوکار، ریسکهای محیط داخلی و خارجی) مشتق شدهاست.
از طرفی تکنولوژیهای معماری سرویسگرا و مدیریت فرآیند کسبوکار یک راهحل مطلوب برای یکپارچهسازی سیستمهاست. خدمات وب در معماری سرویسگرا توابع را به عنوان سرویس با هدف برطرف کردن مشکلات یکپارچهسازی سیستمها و حمایت از فرآیندهای کسبوکار کپسوله میکند. مدیریت فرآیند کسبوکار هماهنگکننده سرویسهای وب برای پیادهسازی فرآیندهای کسبوکار با هدف بهینهسازی فرآیندهای کسبوکار است [51].
یک سرویس معمای سرویسگرا یک جزء نرمافزاری است که برای استفاده عملکردی متقابل مناسب است. مدیریت فرآیند کسبوکار در رابطه با اجرای وظایف خوش تعریف در حالت سازمانیافته است. معماری سرویسگرا در مورد نمایش دادن برنامه کاربردی و سیستم عملکردی به عنوان سرویسهای کسبوکار خوش تعریف میباشد. بنابراین مدیریت فرآیند کسبوکار به طور طبیعی مکمل معماری سرویسگراست. هر دوی این رویکردها به تنهایی قابل پیاده‌سازی است ولی هر دوی آن‌ها با هم منافع متقابلی را به همراه خواهد داشت[52].
امروزه فرآیندهای کسبوکار دائماً در حال تغییر میباشند. به این ترتیب محدوده زمانی از طراحی تا استقرار کوتاه میشود. مدیریت فرآیند کسبوکار این اجازه را به ما میدهد تا به این هدف دست یابیم. توسعه مدیریت فرآیند کسبوکار در معماری سرویسگرا سبب انعطافپذیری بیشتر شده چرا که در آن خدمات به صورت بلادرنگ کشف و پوشش داده میشوند[53].

2-5-1 مرور برخی متدولوژیهای معماری سرویسگرا
در راستای معماری سرویسگرا متدولوژیهایی مطرح شده است که در ادامه به مرور تعدادی از آن‌ها پرداخته و آن‌ها را شرح میدهیم.
متدولوژی SOAD50 : تکنیکی جهت بازنمایی و بازشناسی سرویسها میباشد که توسط شرکت آیبیام در سال 2004 ارائه شدهاست و مجموعهای از رهنمودها جهت انجام تحلیل و طراحی سرویسگرایی است. این متدولوژی بر تکنیکهای تحلیل و طراحی شیگرایی، معماری سازمانی و مدیریت فرآیندهای کسبوکار استوار است. فرآیند طراحی و تحلیل سرویسگرایی در سه فاز شناسایی و تعریف سرویسها، طبقهبندی سرویسها و مدلسازی، مستندسازی سرویسها نشان داده شدهاست[54].
متدولوژی SOMA51 : این متدولوژی نیز توسط شرکت آیبیام ارائه شده و دارای فرآیندی سه مرحلهای است. در مرحله اول شناسایی سرویسها، مرحله دوم دقیق کردن تعریف سرویسها و در مرحله سوم محقق سازی سرویسها انجام میشود. این متدولوژی مدلی تکراری افزایشی است که بازدارندگی ریسک را موجب میشود و ریشه در مدل حلزونی دارد[55]. در سال 2008 این متدولوژی ارتقاء پیدا کرده و شامل هفت فاز ارائه شد که میتوان این فازها را در شکل 2-14 مشاهده نمود[56]. روند گردش کار به این شکل است که از مرحله تغییر و مدلسازی کسبوکار آغاز شده و سپس به حوزه مدیریت راهحل وارد میشود و از آنجا به حوزههای شناسایی، تعیین، تحقق و پیادهسازی بر اساس ورودی و خروجیها میشود و در آخر به استقرار، پایش و مدیریت ختم میشود. در این متدولوژی تجزیه و تحلیل سیستم با نگاهی واحد به کل (درشتدانه) آغاز و سپس به سوی تجزیه و تحلیل عناصر سازنده آن (ریزدانه) حرکت میکند. به عبارتی ابتدا کل سیستم به اجزاء سازندهاش شکسته، تحلیل و طراحی شده و سپس در مورد هر جزء همین فعالیت
صورت میگیرد. فرآیند شکستن سیستم به اجزاء سازندهاش تا ریزترین عنصر ادامه مییابد. این مدلسازی سبب کاهش درز در فرآیندها و بهبود قابلیت ردیابی میشود[56].

شکل 2-14 توالی انجام فرآیندها در چرخهحیات SOMA [56]
در این متدولوژی سرویسها بر اساس میزان اهمیت، وابستگی میان سرویسها و توجه به ریسکهایی که در تولید سیستم را به مخاطره میاندازد اولویتبندی میشوند. زیرمجموعهای از سرویسها طی فازهای شناسایی و تعریف سرویسها مطرح، استخراج و پیادهسازی انتخاب میشوند. سرویسهایی که انتخاب نشدهاند در تکرارهای بعدی محقق میشوند[56]. الگوی معماری در توسعه مبتنی بر سرویسگرایی از نگاه متدولوژی فوق به این شکل است که برای هر سیستم مبتنی بر معماری سرویسگرا هفت لایه تعریف که برای هر هفت لایه باید تصمیمهای معماری لحاظ گردد.
در شکل 2-15 این هفت لایه نشان داده شدهاست[56].

شکل 2-15 لایههای معماری سرویسگرای پیشنهادی SOMA [55]
متدولوژی52