راه حل مدرن سازی برای سیستمهای قدیمی با استفاده از معماری باز

به گزارش پایگاه خبری بانکداری الکترونیک،«راه حل مدرن سازی برای سیستمهای قدیمی با استفاده از  معماری باز» مقاله ای  به قلم کنستانتین ماریان ماتی استاد دانشکده سایبرنتیک اقتصادی، آمار و انفورماتیک، آکادمی مطالعات اقتصادی  رومانی  است.

وی از دانشگاه سایبرنتیکز، آمار و اطلاعات اقتصادی در 2005 در رشته سیستمهای IT برای مدیریت فرایندهای اقتصادی (SIMPRE) دانش آموخته شده است.  وی در حال حاضر مدیر پروژه در عملکردهای مین فرم در IBM رومانی است. همچنین دانشجوی دکترا در رشته دانش اقتصادی است. مهارتهای اصلی او عبارتند از رهبری مدیریت پروژه، مدیریت بازرگانی، رهبری و راهنمایی بانکداری، متخصص IT&C در کسب و کارهای مبتنی بر برنامه نویسی. بخش هایی از مقاله وی را با هم میخوانیم:

*****************************************

 باید به درستی مشخص شود ترجیحات کاربران بانکی در خصوص قابلیت اطمینان بخشی نرم افزار و مدرن بودن سیستم چیست و برای مثال برخی کاربران ازکارکردن با صفحات نمایش فرمت قدیمی لذت می­برند و البته عده­ای دیگر طرح­های جدید را می­پسندند.

همچنین باید مشخص شود محدودیت­های مربوط به استفاده از سیستم­های قدیمی چیست و چگونه می­توان این سیستم­ها را ارتقا داده یا جایگزین کرد. گستره تحقیق روبرو ارائه راه حلی برای مدرن سازی سیستم­های بانکی با استفاده از روش معماری سرویس­گراست. این تحقیق بر اساس مدرن سازی سیستم­های قدیمی  ساخته شده و در COBOL/400 تحت مجموعه IBM iSeries است. فرایند مدرن سازی از روش معماری خدمت­گرا با استفاده از فناوریهای جاوا بهره می­برد.

یکی از بزرگترین معماهای مدیران ارشد بانکی چنین است:« آیا  سیستم­های کنونی را با نمونه­ هایی بهتر عوض خواهیم کرد یا خیر؟ اگر چنین است آیا توانایی تقبل هزینه ­های آن را داریم؟»

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

 دلیل اینکه چرا سیستم­ های قدیمی هنوز مشغول فعالیت هستند آن است که هزینه­ ها و خطرات جایگزینی آنها بسیار زیاد است و اگر تغییراتی ایجاد شود ممکن است عملکرد یک سیستم داخلی با شکست روبرو شود. البته دلیل دیگری هم وجود دارد که مربوط به منطق تجاری است. این  اپلیکشن­ ها در اوایل دهه 1970 میلادی ایجاد شدند و با نیازهای تجاری منطبق بودند. بنابراین کدگذاری این منطق تجاری در سیستم بسیار پیچیده است و ممکن است در صورت جایگزینی با خطر شکست روبرو شود.

 در سال 2008 میلادی یکی از تحلیل­گران گروه تاور (TowerGroup) اعلام کرد نه تنها از سوی فناوری بلکه از نقطه نظر تجاری نیز فشارهایی برای تغییر سیستم وجود دارد. رقبا از ساختارهای آزاد جدیدی استفاده می­کنند که قابلیت گزارش دهی هوشمند، جمع آوری داده­ها و یکپارچه سازی پایگاه­ هایی مانند تبلت، نوت بوک و تلفن­ های هوشمند را دارد. این امر سرعت اثربخشی تجاری را می افزاید و همچنین سیستمی بهتر برای فرایند تصمیم گیری ارائه می­کند.

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

 برای آنکه بتوانیم به این سوال پاسخ دهیم باید محدودیت­های مربوط به استفاده از سیستم­ های قدیمی را بشناسیم.

•  سیستم­های قدیمی بر اساس نیازهای آن زمان طراحی شده اند و قرار نبوده برای سال­های متمادی ( بیش از 15 سال) فعال باشند.
•  این سیستم­ ها هنگام ساخت، برخی از محدودیت­ ها داشته­ اند ( به عنوان مثال، کم هزینه بودن، دسترسی به منبع و غیره).
•   سیستم­های کنونی با ویژگی­هایی مانند پیچیدگی، اجزای تجاری و اهداف تجاری شناخته می­شوند.
•  باز نویسی نرم افزار، گرانبها و وقت گیر است و البته نباید فراموش کرد که پر خطر نیز هست ( ممکن است هنگام قبول آزمایش،  اشکالات زیادی اتفاق بیفتد و از همه مهمتر، ممکن است هنگام انجام آن کسب و کار تغییر کند. مزیت اصلی آن است که  بانک می­تواند برنامه نرم افزاری در اختیار داشته باشدکه ملزومات به خصوصی را رعایت می ­کند.
•  
•  دومین گزینه مربوط به سیستم­های جدید برگرفته از سیستم­های قدیمی (COTS) است که آماده استفاده هستند و فقط باید بر اساس کسب و کار بانک تخصصی سازی شوند. خطرات نگهداری چنین محصولاتی مانند هزینه­های اصلاحات، معمولاَ بالاتر از سیستم­ های دیگر است. مزیت­شان این است که نرم افزار قبلا استفاده شده و  SLAها (موافقت نامه­ های سطح خدمات) را می­توان برای خدمات پشتیبانی به کار برد. معمولا SLA ها به موقع عکس العمل نشان می­ دهند ( تیم پشتیبانی طرف سوم باید در بازه زمانی خاصی مقدار معینی ملزومات بانکی را پاسخگو باشد) و البته زمانبندی حل مشکل آنها نیز دقیق است ( گروه پشتیبانی باید مشکلات یا خطاها را در بازه زمانی تعیین شده ای حل  کند). اگر SLA رعایت نشود،  تهیه کننده نرم افزار با جریمه روبرو می شود. درباره COTS نیزخطر اجرای بسته نرم افزاری وجود دارد. تا به حال 2 خطر کلی درباره جایگزین کردن سیستم های کنونی با COTSها شناخته شده است: شیوه نگهداری سیستم های جدید مانند سیستم های قدیمی آشنا نیست. دوم آنکه هیچ ضمانتی وجود ندارد که سیستم جدید مانند سیستم قدیمی کار کند.
•  
•  آخرین روش، انتقال از سیستمهای قدیمی به محیط ساختار خدمت گرا را بررسی می کند که انعطاف پذیرتر است. علاوه براین داده های اصلی سیستم و قابلیت عملکرد آن حفظ می شود. گزینه های متعددی برای انجام این انتقال وجود دارد که از میان آنها به انتقال اتوماتیک با ابزاری مانند IBM Rational HATS ( میزبان دسترسی به خدمات انتقال) و استفاده از  الگوهای مدل کنترلگر است مانند جاوا یا روشهای جدید مانند الگوهای (MVP).

فصل مشترک این روشها آن است که هر بار یک سیستم قدیمی تغییر می­ کند، اقداماتی که گفته می شود باید در نظر گرفته شوند: ارزیابی، انتقال، تغییر رمزهای کامپیوتر بدون تغییر عملکردهای آن و توانمند سازی وب.

ادامه مقاله را در بانک مقالات یا اینجا بخوانید.