معماری نوسازی موجی GITA چگونه کار میکند
ما Mainframe موجود را بهعنوان System of Record حفظ میکنیم و در کنار آن Strangler Fig Pattern را اجرا میکنیم — یعنی هر Domain بهتدریج توسط سرویسهای Java/Kotlin جایگزین میشود. لایه API Encapsulation در روز اول فعال میشود تا کانالهای دیجیتال بلافاصله از سامانههای مدرن مصرف کنند، بدون آنکه منتظر پایان مهاجرت بمانند. Parallel Run Reconciliation Engine ما هر تراکنش را در دو سامانه اجرا و نتایج را تطبیق میدهد.
Parallel Run Integrity
هر تراکنش بهصورت موازی روی Mainframe و سامانه جدید اجرا و نتایج تا سطح فیلد تطبیق داده میشود
Data Lineage کامل
نقشهبرداری end-to-end از منبع داده تا گزارش، با قابلیت replay برای ممیزی و forensic
Strangler Fig Pattern
جایگزینی تدریجی Domain به Domain، با قابلیت Rollback به Mainframe در صورت بروز هرگونه ناهمخوانی
Continuous Observability
متریک، لاگ و trace یکپارچه از Mainframe، سرویسهای جدید و Reconciliation Engine در یک داشبورد واحد
قابلیتهایی که نوسازی Mainframe را قابل اجرا میسازند
هر deliverable در پایان engagement بهصورت مستند، executive-ready و قابل ارائه به هیأت مدیره به شما تحویل داده میشود.
Code Analysis و Dependency Map
Discoveryتحلیل ایستا و پویای کل پایگاه کد COBOL، PL/I و Assembler و تولید نقشه وابستگی قابل کاوش.
COBOL-to-Java/Kotlin Transpiler اختصاصی GITA
Transpilationتبدیل خودکار COBOL به Java یا Kotlin قابل خواندن، نه کد ماشینی غیرقابل نگهداری.
جایگزینی CICS و IMS با Spring Boot
Transactionتبدیل CICS Transactions و IMS DC به Microservices Spring Boot با مرز Domain روشن.
مهاجرت DB2 z/OS به PostgreSQL یا Oracle
DataSchema discovery، تبدیل DDL، مهاجرت داده تاریخی و همگامسازی Real-Time در زمان Cutover.
Batch JCL Modernizer
Batchتبدیل JCL Batchهای شبانه به Apache Airflow DAG با قابلیت مشاهدهپذیری مدرن.
API Encapsulation روز اول
APIپوشاندن CICS و IMS با REST API و رویدادهای Kafka، حتی قبل از شروع ترانسپایل.
Parallel Run Reconciliation Engine
Validationاجرای موازی هر تراکنش روی Mainframe و سامانه جدید و تطبیق دقیق نتایج تا سطح فیلد.
Performance Baseline و SLA Mirroring
Performanceاندازهگیری دقیق Latency و Throughput روی Mainframe و تضمین کف کیفیت معادل در سامانه جدید.
Cutover Plan و Rollback Strategy
Cutoverبرنامه دقیق Cutover با چکلیست ساعت به ساعت و سناریوی بازگشت تضمینشده.
آموزش و انتقال دانش به تیم سازمان
Knowledgeتربیت تیم Java داخلی برای نگهداری بلندمدت — نه وابستگی دائمی به پیمانکار.
برنامه ۱۸ تا ۳۶ ماهه نوسازی موجی
Discovery و Architecture Assessment
۸–۱۲ هفتهتحلیل کامل پایگاه کد COBOL و PL/I، ترسیم نقشه وابستگی، اولویتبندی Domainها و تعیین استراتژی هر یک (Re-host، Re-platform، Re-engineer، Replace، Encapsulate).
API Encapsulation و Wave صفر
۳–۴ ماهپوشاندن سامانههای هستهای با REST API و رویدادهای Kafka — بدون تغییر در Mainframe. کانالهای دیجیتال از همین لحظه از API جدید استفاده میکنند.
موج اول مهاجرت Domain
۴–۶ ماهانتخاب یک Domain با ریسک پایین و ارزش بالا (مثلاً Customer Information File)، ترانسپایل به Java، اجرای Parallel Run و Cutover.
موجهای میانی
۱۰–۱۸ ماهتکرار الگوی موج اول برای Domainهای مهمتر (Account، Loan، Card، GL) با تیم بزرگتر و سرعت بالاتر. هر موج درسهای موج قبل را به کار میگیرد.
موج پایانی و Decommission
۴–۶ ماهمهاجرت آخرین Domainها، خاموش کردن تدریجی CICS و IMS، آزادسازی MIPS و کاهش رسمی لایسنس z/OS.
Hyper-care و انتقال کامل دانش
۶ ماهپشتیبانی ۲۴/۷ سامانه جدید، حضور معماران GITA در کنار تیم سازمان و انتقال کامل مالکیت عملیاتی.
حفظ Mainframe، جایگزینی Big-Bang، یا نوسازی تدریجی GITA
بازخورد از مدیران فنی پروژههای نوسازی Mainframe
«ما ۱۵ سال درباره نوسازی Core Banking حرف میزدیم اما هر بار از ریسک Big-Bang عقب مینشستیم. روش موجی GITA با Parallel Run و Rollback تضمینشده، اولین برنامهای بود که هیات مدیره ما تصویب کرد. اکنون موج سوم را با موفقیت پشت سر گذاشتهایم و هزینه MIPS سالانه ۲۸٪ کاهش یافته است.»
«ترانسپایلر اختصاصی GITA کلید موفقیت ما بود. کد Java خروجی واقعاً قابل خواندن و نگهداری بود — نه آن چیزی که از ابزارهای دیگر دیده بودیم. تیم Java داخلی ما توانست از روز اول کد را Review و توسعه دهد.»
«Reconciliation Engine هر روز برای ما ۲۰ تا ۳۰ ناهمخوانی ریز را گزارش میداد که بدون این ابزار هرگز کشف نمیشد. این شفافیت باعث شد بانک مرکزی به برنامه ما اعتماد کند و Cutover بدون یک تیکت بحرانی انجام شود.»
سؤالهای متداول
01آیا واقعاً میتوان بدون Big-Bang، Core Banking را نوسازی کرد؟
بله. روش Strangler Fig و موجی ما دقیقاً برای پرهیز از Big-Bang طراحی شده است. هر Domain بهصورت مستقل مهاجرت میکند و در دوره Parallel Run، هر دو سامانه فعال هستند. تجربه ما در ۴ بانک ایرانی نشان داده است که این روش، ریسک Go-Live را به یکدهم Big-Bang کاهش میدهد.
02ترانسپایلر COBOL-to-Java شما چه تفاوتی با Micro Focus یا AWS Blu Age دارد؟
ابزارهای متداول کد COBOL را به Java شبه-Assembly تبدیل میکنند که عملاً قابل نگهداری نیست. ترانسپایلر GITA با بهرهگیری از LLM اختصاصی fine-tune شده روی پایگاه کد بانکی ایرانی، کد Java مدرن با Spring Boot، نامگذاری معنادار و الگوهای طراحی استاندارد تولید میکند. خروجی بهگونهای است که تیم Java شما از روز اول میتواند آن را توسعه دهد.
03در دوره Parallel Run، هزینه دو برابر نمیشود؟
بله، در دوره Parallel هزینه عملیاتی موقتاً افزایش مییابد، اما این هزینه در برابر ریسک Cutover ناموفق ناچیز است. ما دوره Parallel را برای هر Domain به ۶ تا ۱۲ هفته محدود میکنیم و پس از رسیدن Reconciliation Accuracy به ۹۹.۹۹۹٪، Cutover انجام و Mainframe برای آن Domain آزاد میشود. بازگشت سرمایه در کل برنامه، در ماه ۳۰ تا ۳۶ اتفاق میافتد.
04اگر در میانه برنامه، Domain خاصی موفق نشد چه میشود؟
هر موج بهصورت مستقل قابل Rollback است. اگر در دوره Parallel Run یا حتی بعد از Cutover، شاخصی از حد آستانه فراتر رود، در کمتر از ۱۵ دقیقه به Mainframe بازمیگردیم. تمام دادههای تولیدشده در سامانه جدید به Mainframe Sync میشود تا یکپارچگی حفظ گردد. این تضمین در قرارداد گنجانده میشود.
05وضعیت تیم COBOL فعلی ما چه میشود؟
ما بهجای کنار گذاشتن تیم COBOL، آنها را به برنامه آموزش Java و Spring Boot دعوت میکنیم. تجربه نشان داده است که توسعهدهندگان COBOL با ۲۰ سال سابقه، به سرعت Domain Knowledge بینظیر خود را به دنیای Java منتقل میکنند و در ۶ تا ۹ ماه به یکی از باارزشترین اعضای تیم Java بدل میشوند.
06آیا دادههای تاریخی DB2 ما در مهاجرت حفظ میشود؟
بله، ۱۰۰٪ دادههای تاریخی منتقل میشود. ما از ترکیب Bulk Load اولیه و CDC مبتنی بر Debezium استفاده میکنیم تا تا لحظه Cutover هیچ تراکنشی از دست نرود. روی ۱۰۰٪ ردیفها تست Integrity انجام میشود و گزارش رسمی برای ممیزی صادر میگردد.
07Performance سامانه جدید نسبت به Mainframe چگونه است؟
Mainframe در پردازش Batch بسیار قدرتمند است، اما در Online Transactions، سامانههای مدرن Java با Caching هوشمند و معماری Reactive معمولاً ۲ تا ۵ برابر سریعتر عمل میکنند. ما قبل از Cutover، Load Test روی ۲ برابر بار Production انجام میدهیم و SLA کف، برابر یا بهتر از Mainframe تضمین میشود.
08انطباق با الزامات بانک مرکزی و ابلاغیههای افتا چگونه تضمین میشود؟
تیم انطباق ما در فاز Discovery، تمام الزامات سازمانهای ناظر را در سند Modernization Blueprint میگنجاند. Data Lineage کامل، Audit Trail غیرقابل تغییر و گزارشهای آماده برای ممیزی، از روز اول طراحی میشوند. در سازمانهای دولتی، استقرار On-Premise و Air-Gapped بهصورت پیشفرض ارائه میشود.
09آیا در دوره نوسازی، توسعه محصول جدید روی Mainframe Freeze میشود؟
خیر. بر خلاف Big-Bang که سالها توسعه را Freeze میکند، روش موجی به شما اجازه میدهد روی Domainهای مهاجرتنیافته همچنان توسعه COBOL داشته باشید و روی Domainهای مهاجرتیافته، Release هفتگی Java انجام دهید. کسبوکار شما در طول کل برنامه فعال و چابک باقی میماند.
10هزینه و زمان دقیق برای بانکی با ۱۵ میلیون خط COBOL چقدر است؟
بر اساس تجربه ما، یک پایگاه کد ۱۵ میلیون خطی معمولاً به ۲۸ تا ۳۶ ماه برنامه نوسازی نیاز دارد. هزینه دقیق بسته به تعداد Domainها، پیچیدگی DB2 Schema، تعداد JCLها و سطح Parallel Run موردنیاز متغیر است. در فاز Discovery (۸ تا ۱۲ هفته) عدد دقیق با تفکیک موج به موج ارائه میشود و در قرارداد با Cap هزینهای تضمین میگردد.
ارزیابی فنی Mainframe خود را با معمار ارشد GITA شروع کنید
۶۰ دقیقه با معمار ارشد ما درباره پایگاه کد، DB2 Schema و اولویتهای کسبوکار صحبت کنید. در پایان جلسه، تخمین اولیه از حجم برنامه و موج پیشنهادی اول را دریافت میکنید — رایگان و بدون تعهد.