گردش‌کار عامل‌محور در برابر ترجمهٔ خطی در بازسازی سیستم‌های میراثی

تصور کنید مسئولیت انتقال یک سیستم بانکی ۴۰ ساله به زبان مدرن را بر عهده دارید، اما تنها منبع شما میلیون‌ها خط کد COBOL است که نویسندگانش دهه‌ها پیش بازنشسته شده‌اند. در این وضعیت، مشکل اصلی ترجمهٔ کد نیست، بلکه «درک» منطقی است که در لایه‌های قدیمی دفن شده است. نرخ شکست بالای مدرن‌سازی مین‌فریم‌ها معمولاً به این دلیل رخ می‌دهد که تیم‌ها با این فرآیند به عنوان یک مسئلهٔ ترجمه برخورد می‌کنند، نه یک مسئلهٔ درک مفاهیم.

به گزارش IBM، برای حل این بحران، شرکت به سمت یک رویکرد عامل‌محور (Agentic) تغییر مسیر داده است. این رویکرد فراتر از تبدیل ساده COBOL به Java است و هدف آن خودکارسازی کل چرخهٔ کشف (Discovery) و بازسازی (Refactoring) است. دهه‌هاست که بانک‌ها، شرکت‌های بیمه، سازمان‌های بهداشتی، خرده‌فروشان و آژانس‌های دولتی برای امنیت بی‌نظیر، قابلیت اطمینان بالا و توانایی پردازش حجم بسیار زیاد تراکنش‌ها به مین‌فریم‌ها تکیه کرده‌اند. اما این سیستم‌ها اکنون میزبان منطق‌های تجاری پیچیده‌ای هستند که ۲۰، ۳۰ یا حتی ۴۰ سال پیش توسط صدها برنامه‌نویس مختلف نوشته شده‌اند و بسیاری از آن‌ها سال‌هاست بازنشسته شده‌اند. در طول زمان، قوانین تجاری جدیدی اضافه شده، قوانین قدیمی تغییر کرده و کارهای دسته‌ای (Batch Jobs) به شکلی پیچیده با تراکنش‌های آنلاین گره خورده‌اند. همان‌طور که در تحلیل قبلی ما درباره‌ی استقرار هوش مصنوعی در عملیات ابری BNP Paribas اشاره کردیم، اکنون این جریان‌های کاری خودکار به سخت‌ترین بخش زیرساخت سازمان‌ها، یعنی هستهٔ قدیمی (Legacy Core)، نفوذ کرده‌اند.

چرخش از هوش مصنوعی زاینده به عامل‌محور

هوش مصنوعی زاینده (Generative AI) — مثل دستیاری که فقط وقتی از او می‌پرسید جواب می‌دهد — در حالت عادی واکنشی است. در این مدل، برنامه‌نویس تکه‌ای از کد COBOL را ارائه می‌دهد و می‌پرسد: «این برنامه چه می‌کند؟» یا «وقتی CUSTOMER-TYPE برابر با 'P' است چه اتفاقی می‌افتد؟». مدل AI منطق را خلاصه می‌کند یا یک نسخه Java از آن تکه کد خاص می‌سازد. در این مدل، انسان همچنان مدیر پروژه است و باید به صورت دستی ده‌ها پرسش کوچک را زنجیروار به هم وصل کند تا بتواند نقشه کلی سیستم را ترسیم کند.

در مقابل، هوش مصنوعی عامل‌محور (Agentic AI) — شبیه به کارمندی است که هدف کلی را می‌گیرد و خودش برای رسیدن به آن برنامه‌ریزی می‌کند — این حلقهٔ پرسش-پاسخ را با یک جریان کاری هدف‌محور جایگزین می‌کند. این تحول در واقع بخشی از یک روند گسترده‌تر است که در آن عامل‌های هوش مصنوعی به‌جای ارائه پاسخ‌های ساده، به سمت اجرای مستقیم وظایف پیچیده در سازمان‌ها حرکت می‌کنند. برنامه‌نویس به جای پرسش‌های خرد، هدفی سطح‌بالا به عامل می‌دهد: «ماژول پردازش کارمزد مشتری را تحلیل کن و آن را برای مدرن‌سازی آماده کن».

عامل برخلاف دستیار ساده، وظایف خود را برنامه‌ریزی می‌کند. او ممکن است برنامه‌های COBOL مرتبط را شناسایی کند، Copybookها و جداول پایگاه‌داده را بیابد، منطق تجاری را توضیح دهد و برای رفتارهای فعلی تست بسازد. در واقع جریان کار از یک حلقه ساده (برنامه‌نویس $\rightarrow$ دستور $\rightarrow$ پاسخ AI) به یک زنجیره پیچیده تبدیل می‌شود: برنامه‌نویس $\rightarrow$ هدف $\rightarrow$ برنامه‌ریزی وظایف توسط AI $\rightarrow$ استفاده از ابزارها توسط AI $\rightarrow$ تحلیل نتایج توسط AI $\rightarrow$ اجرای گام بعدی توسط AI $\rightarrow$ بازبینی توسط برنامه‌نویس.

خط لوله ۸ مرحله‌ای مدرن‌سازی

بر اساس یک راهنمای فنی مفصل که در ۲۷ سپتامبر ۲۰۲۶ منتشر شد، این رویکرد عامل‌محور برای جلوگیری از حذف اتفاقی منطق تجاری در طول تحول، ۸ مرحله سخت‌گیرانه را طی می‌کند:

۱. کشف اپلیکیشن: عامل با ابزارهایی مثل IBM Application Discovery and Delivery Intelligence وابستگی‌ها را ترسیم می‌کند. او شناسایی می‌کند که کدام برنامه‌های COBOL یکدیگر را فراخوانی می‌کنند و به کدام جداول Db2 یا فایل‌های VSAM دسترسی دارند. برای مثال، اگر برنامه‌نویس بخواهد برنامه‌ای مثل FEE200 را مدرن کند، عامل کشف می‌کند که آیا این برنامه توسط ACCT100 فراخوانی شده یا خودش RATE300 و HIST400 را صدا می‌زند. همچنین تعیین می‌کند که برنامه توسط یک تراکنش آنلاین، یک فرآیند دسته‌ای (Batch) یا هر دو استفاده می‌شود. نگاه کردن به یک فایل منبع به تنهایی کافی نیست؛ عامل باید بستر گسترده‌تر کارهای دسته‌ای شبانه تحت کنترل JCL، اجرای CICS و تبادلات پیام MQ را درک کند.

۲. درک کد: هوش مصنوعی سینتکس متراکم COBOL را به انگلیسی ساده تبدیل می‌کند. مثلاً یک دستور IF تو در تو و پیچیده — مانند بررسی اینکه آیا WS-CUST-TYPE = 'P' و WS-BALANCE > 10000 است تا کارمزد ۰.۵٪ محاسبه شود — به این خلاصه خوانا تبدیل می‌شود: «مشتریان ویژه با موجودی بیش از ۱۰,۰۰۰ دلار، کارمزد ۰.۵٪ می‌پردازند». این مرحله برای برنامه‌هایی که ممکن است تا ۵,۰۰۰ خط کد داشته باشند و در طول دهه‌ها توسط چندین برنامه‌نویس نوشته شده باشند، حیاتی است. ابزارهای فعلی AI مین‌فریم IBM از توضیح COBOL و سایر مصنوعات مین‌فریم پشتیبانی می‌کنند و این مفهوم را در وظایف گسترده‌تر توسعه گسترش می‌دهند.

۳. استخراج قوانین تجاری: عامل کد را اسکن می‌کند تا قوانین واقعی تجاری را از سینتکس فنی جدا کند. او می‌تواند مستندات ساختاریافته‌ای تولید کند، مانند:

• قانون تجاری: BR-FEE-001
• شرح: مشتریان ویژه با موجودی حساب بالای ۱۰,۰۰۰ دلار، مشمول کارمزد ۰.۵٪ تراکنش می‌شوند.
• منبع: فایل FEE200.cbl، پاراگراف: CALCULATE-FEE
• ورودی‌ها: CUSTOMER-TYPE ،ACCOUNT-BALANCE ،TRANSACTION-AMOUNT
• خروجی: TRANSACTION-FEE

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

۴. تحلیل اثرات: قبل از تغییر حتی یک خط کد، عامل تمام وابستگی‌ها را گزارش می‌دهد. اگر طول یک فیلد مانند CUSTOMER-ID از ۱۰ به ۱۵ کاراکتر تغییر کند، AI تمام Copybookها، جداول Db2، رکوردهای VSAM، صفحات CICS، کارهای JCL، پیام‌های MQ و اپلیکیشن‌های پایین‌دستی متأثر را شناسایی می‌کند. او یک گزارش ریسک ارائه می‌دهد که وابستگی‌های پرخطر مانند PAYMENT01 یا DAILY-SETTLEMENT-JOB را برجسته می‌کند. AI تصمیم نهایی را نمی‌گیرد، بلکه نقطه‌ای برای شروع بررسی‌های برنامه‌نویس در مناطق پرخطر فراهم می‌کند.

۵. بازسازی (Refactoring): به جای بازنویسی کورکورانه، عامل به جداسازی قابلیت‌های تجاری کمک می‌کند. با استفاده از ابزارهایی مثل Z Refactoring Assistant، عامل شناسایی می‌کند که آیا یک برنامه ۷,۰۰۰ خطی را می‌توان به توابع مستقل مانند «اعتبارسنجی مشتری»، «اعتبارسنجی حساب»، «محاسبه کارمزد»، «پردازش پرداخت»، «پردازش حسابرسی» و «گزارش‌دهی» تقسیم کرد یا خیر. این کار اجازه می‌دهد یک برنامه یکپارچه (Monolithic) قبل از تحول به سرویس‌های مستقل تبدیل شود و ریسک شکست در پروژه‌های «بازنویسی کلی» کاهش یابد. معماری می‌تواند به مدلی حرکت کند که در آن یک API محاسبه کارمزد بین هسته COBOL موجود و یک سرویس جدید کارمزد قرار گیرد.

۶. تبدیل: تنها پس از شفاف شدن بستر و زمینه، تبدیل COBOL به Java صورت می‌گیرد. برای مثال، منطق کارمزد به یک متد Java با استفاده از BigDecimal برای دقت محاسباتی تبدیل می‌شود. پژوهش‌های IBM Research در سال ۲۰۲۶ (Bhardwaj et al.) نشان می‌دهد که ارائه خلاصه‌های زبان طبیعی از برنامه‌های COBOL، دقت این ترجمه‌ها را به‌ویژه در موارد دشوار به‌طور چشم‌گیری افزایش می‌دهد. این تایید می‌کند که هرچه درک از اپلیکیشن اصلی بهتر باشد، شانس تحول صحیح بالاتر است.

۷. تست با کمک AI: عامل بر اساس شاخه‌های اصلی کد COBOL، تست‌های JUnit می‌سازد تا ثابت کند سرویس جدید Java دقیقاً همان نتایج تجاری را تولید می‌کند. او سناریوهای تست خاصی را شناسایی می‌کند، مانند:

• مشتری ویژه با موجودی > ۱۰,۰۰۰ دلار
• مشتری ویژه با موجودی = ۱۰,۰۰۰ دلار
• مشتری ویژه با موجودی < ۱۰,۰۰۰ دلار
• مشتری استاندارد
• مبالغ تراکنش صفر یا حداکثری
• انواع مشتریان نامعتبر

ابزار IBM watsonx Code Assistant for Z این قابلیت‌ها را برای تولید Java و JUnit فراهم کرده است. با این حال، این فرآیند باید فراتر از تست‌های واحد (Unit Tests) رفته و شامل تست‌های یکپارچگی، رگرسیون، عملکرد، امنیت و تست پذیرش کاربر (UAT) شود.

۸. ادغام در DevOps: عامل در خط لوله‌های Git و CI/CD فعال است. اگر نیازی به افزودن یک قانون اعتبارسنجی برای پرداخت‌های بین‌المللی بالای ۲۵,۰۰۰ دلار باشد، عامل می‌تواند برنامه‌های پردازشی را جست‌وجو کند، تحلیل اثرات را انجام دهد، تغییر کد را پیشنهاد دهد، تست‌های واحد را تولید کند و تغییرات را برای بازبینی کد آماده کند. این سیستم با بیلد‌های خودکار، اسکن کد و فرآیندهای تایید سازمانی ادغام می‌شود.

حفاظ‌های انسانی در چرخه

به دلیل حساسیت داده‌های مالی و بهداشتی، استقرار خودکار پذیرفته نیست. معماری پیشنهادی بر تایید انسانی در هر نقطه کلیدی تاکید دارد:

• تحلیل اپلیکیشن توسط AI $\rightarrow$ بازبینی برنامه‌نویس مین‌فریم
• استخراج قوانین تجاری توسط AI $\rightarrow$ بازبینی برنامه‌نویس/تحلیل‌گر تجاری
• پیشنهاد بازسازی توسط AI $\rightarrow$ بازبینی معمار سیستم
• تبدیل کد توسط AI $\rightarrow$ بازبینی کد (Code Review)
• تست خودکار $\rightarrow$ تایید انسانی $\rightarrow$ استقرار

این رویکرد اصل «حداقل دسترسی» (Least Privilege) را در مورد عوامل AI اعمال می‌کند. سازمان‌ها باید به‌طور دقیق کنترل کنند که عامل به کدام کدهای منبع دسترسی داشته باشد، کدام داده‌ها را بخواند، آیا اجازه تغییر کد دارد، آیا می‌تواند Pull Request ایجاد کند و آیا مجاز به استقرار هر چیزی است یا خیر.

بازتعریف نقش برنامه‌نویس مین‌فریم

این تحول باعث حذف برنامه‌نویسان COBOL نمی‌شود، بلکه نقش اصلی آن‌ها را تغییر می‌دهد. برنامه‌نویس از جست‌وجوی دستی در هزاران خط کد، به یک ارکستراتور تبدیل می‌شود که خروجی‌های AI را هدایت، بازبینی و اعتبارسنجی می‌کند. متخصصانی که دانش دامنه (Domain Knowledge) دارند ارزشمندتر می‌شوند چون تنها آن‌ها می‌توانند به سخت‌ترین سوالات پاسخ دهند: آیا AI وابستگی خاصی را نادیده گرفته است؟ آیا Java تولید شده قابل نگهداری است؟ آیا سرویس جدید همان ویژگی‌های عملکردی سیستم Z اصلی را دارد؟ آیا تست‌ها کافی هستند؟ نقش آن‌ها از نوشتن دستی هر خط کد به چرخه «درک $\rightarrow$ هدایت $\rightarrow$ بازبینی $\rightarrow$ اعتبارسنجی $\rightarrow$ تایید» تکامل می‌یابد.

واقعیت ابر ترکیبی (Hybrid Cloud)

مدرن‌سازی لزوماً به معنای خروج کامل از مین‌فریم نیست. یک معماری ترکیبی اجازه می‌دهد پردازش‌های هسته تراکنشی (COBOL, CICS, Db2, IMS, MQ) روی IBM Z باقی بمانند و قابلیت‌ها از طریق API به لایه‌های ابری، وب، موبایل، تحلیل داده و AI متصل شوند. هوش مصنوعی عامل‌محور با مستندسازی رابط‌ها و تولید مصرف‌کنندگان (Consumers) Java لازم برای اتصال این دو جهان، این فرآیند را تسهیل می‌کند. این جریان مهندسی تضمین می‌کند که سازمان‌ها در عجله برای رفتن به ابر، دهه‌ها دانش تجاری پالایش‌شده را دور نریزند. هدف، ترکیبی از مین‌فریم، ابر، DevOps و تخصص انسانی است که توسط یک ارکستراتور عامل‌محور مدیریت می‌شود.

استراتژی پیاده‌سازی عملی

سازمان‌ها باید از دادن میلیون‌ها خط کد COBOL به یک عامل AI به صورت یک‌باره اجتناب کنند. یک نقطه شروع ایمن‌تر شامل موارد زیر است:

• پایلوت در مقیاس کوچک: یک اپلیکیشن را که به خوبی شناخته شده است انتخاب کرده و وابستگی‌های آن را ترسیم کنید.
• اعتبارسنجی: از AI برای توضیح برنامه‌ها استفاده کنید و آن توضیحات را با دانش برنامه‌نویسان باسابقه تطبیق دهید.
• جداسازی قابلیت: یک قابلیت تجاری کوچک — مانند محاسبه سود، واجد شرایط بودن مشتری یا مسیریابی تراکنش — را شناسایی کرده و آن را بازسازی کنید.
• اندازه‌گیری: نتایج را بر اساس زمان ذخیره شده، دقت قوانین تجاری شناسایی شده، میزان اصلاحات مورد نیاز برای کد AI و تغییرات در عملکرد ارزیابی کنید.

این رویکرد روشمند، مدرن‌سازی را از یک بازنویسی پرریسک «بیگ بنگ» (Big Bang) به یک جریان کاری مهندسی قابل مدیریت تبدیل می‌کند. ارزش نهایی هوش مصنوعی عامل‌محور، توانایی بازنویسی کدهای قدیمی نیست، بلکه توانایی کمک به انسان‌ها برای درک درست کدهاست تا بتوانند تصمیم بگیرند در مرحله بعد چه اتفاقی باید بیفتد.

گام بعدی شما

• اگر در سازمان خود با سیستم‌های Legacy سروکار دارید، به جای بازنویسی کلی، ابتدا یک «پایلوت کوچک» برای نقشه‌برداری وابستگی‌ها اجرا کنید.
• از مدل‌های زبانی برای تبدیل تکه‌های کد به «توضیحات زبان طبیعی» استفاده کنید و آن‌ها را با دانش برنامه‌نویسان قدیمی تطبیق دهید.
• یک قابلیت تجاری کوچک (مثل محاسبه سود) را شناسایی کرده و سعی کنید آن را به صورت یک سرویس مستقل بازسازی کنید.

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