مقدمه

اگر در ایران درباره موتورهای اجرای فرآیند صحبت کنیم، نام Camunda برای بسیاری از تیم‌های فنی آشناست.

اما یک نام دیگر هنوز برای بخش بزرگی از بازار ایران کمتر شناخته شده است:

Flowable

و دقیقاً همین موضوع باعث شده در بسیاری از بررسی‌های BPMS، مقایسه واقعی بین این دو گزینه اصلاً اتفاق نیفتد.

در حالی که هر دو راهکار در حوزه اجرای فرآیندهای کسب‌وکار، BPMN و معماری مبتنی بر موتور فرآیند قرار می‌گیرند، رویکرد معماری آن‌ها یکسان نیست.

پس سؤال درست این نیست که:

«کدام نرم‌افزار بهتر است؟»

سؤال مهم‌تر این است:

«برای معماری آینده سازمان ما، کدام رویکرد مناسب‌تر است؟»

Flowable و Camunda دقیقاً چه هستند؟

قبل از هر مقایسه‌ای باید یک نکته را روشن کنیم.

وقتی می‌گوییم Camunda، باید مشخص کنیم درباره Camunda 7 صحبت می‌کنیم یا Camunda 8.

این تفکیک بسیار مهم است.

Camunda 7 یک پلتفرم BPM متن‌باز با پشتیبانی از BPMN، DMN و CMMN بود.

در مقابل، Camunda 8 بر پایه موتور Zeebe ساخته شده و معماری متفاوتی دارد؛ Zeebe به‌عنوان موتور ارکستراسیون فرآیند Camunda 8، معماری توزیع‌شده‌ای شامل Broker، Gateway، Client و Exporter دارد.

Flowable نیز یک مجموعه موتورهای متن‌باز برای BPMN، CMMN و DMN است که با Java توسعه داده شده و طبق مستندات رسمی، می‌تواند به‌صورت Embedded داخل برنامه یا به‌صورت سرویس و از طریق REST API استفاده شود.

بنابراین مقایسه ساده‌ی لوگوها یا امکانات ظاهری، تصویر دقیقی به ما نمی‌دهد.

مقایسه اول: معماری

شاید مهم‌ترین تفاوت، همین‌جا باشد.

Flowable از ابتدا امکان قرار گرفتن موتور فرآیند درون معماری نرم‌افزار را جدی گرفته است.

یعنی می‌توان موتور را:

• داخل یک برنامه Java قرار داد؛
• به‌عنوان یک سرویس اجرا کرد؛
• از REST API استفاده کرد؛
• یا در معماری‌های بزرگ‌تر به شکل سرویس‌های مستقل به کار گرفت.

این قابلیت‌ها در مستندات رسمی Flowable نیز صراحتاً ذکر شده‌اند.

Camunda 8 از سوی دیگر، معماری توزیع‌شده و مبتنی بر Zeebe را دنبال می‌کند که برای اجرای فرآیندها در مقیاس بالا و معماری‌های سرویس‌محور طراحی شده است.

بنابراین سؤال معماری این نیست که:

Embedded بهتر است یا Distributed؟

بلکه:

معماری سازمان شما به کدام مدل نیاز دارد؟

مقایسه دوم: BPMN، CMMN و DMN

اینجا یک نقطه بسیار مهم وجود دارد.

Flowable به‌صورت رسمی از سه استاندارد اصلی:

BPMN + CMMN + DMN

پشتیبانی می‌کند.

این یعنی سازمان می‌تواند برای:

• فرآیندهای ساختاریافته → BPMN
• مدیریت موارد و کارهای غیرقابل‌پیش‌بینی → CMMN
• تصمیم‌ها و قوانین کسب‌وکار → DMN

از استانداردهای متفاوت اما مکمل استفاده کند.

Camunda نیز در اکوسیستم خود BPMN و DMN را به‌صورت جدی پوشش می‌دهد و Camunda 8 بر پایه Zeebe برای اجرای فرآیندها طراحی شده است.

اما نکته مهم اینجاست:

قبل از انتخاب موتور، باید بدانیم سازمان ما واقعاً با چه نوع مسئله‌ای مواجه است.

اگر تمام مسائل سازمان را صرفاً «Workflow» ببینیم، حتی بهترین موتور هم نمی‌تواند مشکل معماری فرآیند را حل کند.

مقایسه سوم: یکپارچه‌سازی با نرم‌افزارهای سازمان

در معماری مدرن، BPMS نباید جزیره‌ای جدا از سیستم‌های سازمان باشد.

ERP، CRM، سامانه منابع انسانی، سامانه مالی، درگاه‌ها، سرویس‌های داخلی و APIهای خارجی باید بتوانند با موتور فرآیند ارتباط داشته باشند.

Flowable روی Java و REST APIهای گسترده بنا شده و مستندات رسمی آن پوشش گسترده APIها را توضیح می‌دهد.

Camunda 8 نیز APIهای REST و gRPC و مدل Client/Worker را در معماری Zeebe ارائه می‌کند.

بنابراین در اینجا باید سؤال دیگری مطرح شود:

آیا BPMS قرار است مرکز یک جزیره باشد یا بخشی از معماری نرم‌افزاری سازمان؟

این تفاوت در پروژه‌های بزرگ بسیار تعیین‌کننده است.

مقایسه چهارم: وضعیت متن‌باز و مدل تجاری

Flowable Engine به‌صورت رسمی تحت Apache 2.0 ارائه می‌شود و کد آن در GitHub در دسترس است.

در سمت دیگر، مدل Camunda در نسخه‌های جدید تغییراتی داشته است.

برای مثال، Camunda اعلام کرده که از نسخه 8.6، استفاده Production از Camunda 8 Self-Managed نیازمند مجوز تولید است.

این موضوع به معنی خوب یا بد بودن یک مدل تجاری نیست.

اما برای سازمانی که در حال انتخاب یک موتور فرآیند است، مدل مجوز، هزینه مالکیت و نحوه استفاده از محصول باید از همان روز اول در معماری تصمیم‌گیری دیده شود.

پس Flowable بهتر است یا Camunda؟

این سؤال عمداً پاسخ یک‌کلمه‌ای ندارد.

چون انتخاب موتور فرآیند باید بر اساس:

• معماری سازمان
• نوع فرآیندها
• نیاز به Case Management
• مدل توسعه نرم‌افزار
• نحوه استقرار
• نیازهای یکپارچه‌سازی
• مقیاس
• مدل مجوز
• مهارت تیم فنی
• و مسیر توسعه آینده

انجام شود.

اما یک نکته برای بازار ایران اهمیت زیادی دارد:

Flowable هنوز به اندازه Camunda شناخته‌شده نیست.

و کمتر شناخته‌شدن، نباید با کمتر مناسب بودن اشتباه گرفته شود.

بررسی Flowable در کنار Camunda می‌تواند دامنه انتخاب سازمان‌ها را گسترده‌تر کند و از تصمیم‌گیری صرفاً بر اساس شهرت یک نام جلوگیری کند.

یک سؤال مهم‌تر برای سازمان‌های ایرانی

اگر امروز قرار باشد یک پروژه BPMS جدید را از صفر شروع کنید:

آیا فقط گزینه‌هایی را بررسی می‌کنید که قبلاً در ایران نامشان را شنیده‌اید؟

یا واقعاً معماری، استانداردها، مدل توسعه، هزینه مالکیت و مسیر آینده را کنار هم قرار می‌دهید؟

شاید زمان آن رسیده باشد که در بازار ایران، Flowable را نه به‌عنوان یک نام ناشناخته، بلکه به‌عنوان یک گزینه جدی برای ارزیابی معماری BPMS بررسی کنیم.