که دارای اجزایی است که قابلیت استفاده مجدد را دارند.
همان‌طور که قبلاً ذکر شد، فرآیندهای سازمان‌ها طیف‌های مختلفی دارند که از عملیات ساده یک یا چند گامی فاقد ساختار مشخص گرفته تا فرآیندهای کلان و مرکزی سازمان را شامل می‌شوند. مایکروسافت، یک معماری برای سیستم مدیریت فرآیند کسبوکار خود در نظر گرفته است که بتواند تمامی طیف‌های فرآیندهای سازمانی را پوشش دهد (شکل 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