تحول از طریق معماری سرویس‌گرا (SOA)/چابک ‌سازی پلتفرم

اختصاصی بانکداری الکترونیک؛

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

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

معماری SOA، به چارچوب‌ها و فرآیندهایی گفته می‌شود که ویژگی‌های برنامه‌های بانکی را به عنوان مجموعه‌ای از خدمات معماری، مرتبط با عملکردهای خاص تجاری آن، فراهم کند. این سرویس‌ها می‌تواند مثل اعتبارسنجی داده‌های مشتری، مشاهده تراکنش‌ها یا انجام سرویس‌های تحلیلی ساده باشند. این روش برای خلق یک معماری بانکی، مبتنی بر استفاده از خدمات مستقل از هر فروشنده (Vendor)، محصول یا فناوری مورد استفاده قرار می‌گیرد.

یک SOA، یک چارچوب استراتژیک است که به تمام سیستم‌های ذی‌نفع (در داخل و خارج بانک) امکان می‌دهد تا به سرویس‌های تعریف‌شده و اطلاعات مرتبط با این سرویس‌ها که می‌تواند بیش از پیش به صورت لایه‌های پردازش و نرم‌افزارهای کاربردی مرکب برای توسعه راه‌حل خلاصه شوند، دسترسی پیدا کنند. SOA اساساً جنبۀ چالاکی را به معماری اضافه می‌کند و به ما امکان می‌دهد تا به جای آنکه دائماً مجبور به توسعۀ مجدد این سیستم‌ها باشیم با استفاده از یک لایه پیکربندی به تغییرات سیستم رسیدگی کنیم.

معماری سرویس‌گرا به پرسنل غیر فنی امکان می‌دهد تا از امکانات موجود در معماری برای خلق محصولات و سرویس‌های جدید بهره بجویند. معماری SOA ابزاری مهم برای چالاک‌سازی یک معماری کارآمد است به شکل شماره 6 نگاه کنید.

اکثر شرکت‌های خدمات مالی در جهان از فرآیندهای مشابهی مثل بهبود خدمات به مشتری و بهبود قابلیت فروش استفاده می‌کنند. استانداردهای SOA کمک می‌کند تا معماری بانک برای سرویس‌دهی بیشتر و بهتر به فرآیندهای مرتبط با مشتری آماده باشد؛ همچنین سرعت اجرایی شدن یک محصول بانکی یا نوآوری‌های مشابه را بالاتر می‌برد. به بانک‌ها اجازه می‌دهد تا بهتر به خواسته بازار پاسخ دهند و برتری رقابتی خود را نسبت به مؤسسات غیر بانکی حفظ کنند.

بانک‌ها می‌توانند از استاندارد‌های SOA برای ارتقاء خدمات بانکی خود استفاده کنند این معماری به آنها اجازۀ ساخت محصولات و خدمات جدید را می‌دهد. معماری SOA با تسهیل در بهبود فرآیندها و استفاده مجدد از اجزای سرویس‌ها، باعث کاهش فرآیندهای تکراری می‌شود و معماری سریع‌تری را در اختیار بانک‌ها قرار می‌دهد و از طرفی به بانک‌ها کمک می‌کند، بتوانند مزیت رقابتی خود را بالاتر برده و بر عوامل داخلی و خارجی خود غلبه کنند و این امر با معماری سرویس‌گرا امکان‌پذیر است.

مزایای SOA

با طراحی و اجرای معماری SOA در بانک، تمامی سیستم‌های آن بدون وقفه یا هزینۀ اضافی با هم کار خواهند کرد و این امکان را می‌دهد تا چند پروژۀ کوچک‌تر با سرمایۀ کمتر اجرایی شود بدون آنکه نگران هزینۀ بالای نگهداری و بازنویسی این سامانه‌ها مانند سامانه‌های قدیمی کربانکینگ باشیم. همان‌طور که در شکل 7 می‌بینید معماری SOA مزایای زیر را می‌تواند در برداشته باشد:

•    توانایی سازگاری بسیار بالا و کارآمد با شرایط و متغیر‌های بازار در یک صنعت که دائماً در حال پیشرفت است استانداردهای مربوط به SOA نگرانی بانک‌ها را در زمینۀ نظارتی و انطباقی را کاملاً از بین می‌برد.

•    سیستم‌های کربانکینگ با استفاده از ابزارهای SOA می‌توانند بالاترین درجۀ کارآیی را تضمین کنند، قابلیت‌های ارتباطی بین سیستم‌های بانکی با حرکت به سوی یک استاندارد مشترک، می‌تواند هزینه‌های نگهداری سیستم‌ها را کاهش دهد و در نتیجه عملکرد پشتیبانی را بهبود بخشد.

•    رابط کاربری برنامه‌های استانداردشده امکان ارتباط بیشتر با توسعه‌دهندگان خارج از بانک را فراهم می‌کند و آن را بهبود می‌بخشد.

•    تولید سرویس‌های استاندارد، امکان بهره‌برداری از روش‌های بهینه‌شده و کارا را افزایش می‌دهد و بهبود فرآیند توسعه را تسهیل می‌کند.

مزایای اصلی یک SOA عبارت‌اند از:

1- استفادۀ مجدد از سرویس‌ها و رفتارها یا توانایی به کارگیری مجدد رفتار نرم‌افزار کاربردی از یک نرم‌افزار کاربردی به نرم‌افزار کاربردی دیگر بدون نیاز به حجم قابل ملاحظه‌ای از کدنویسی مجدد یا ادغام. به عبارت دیگر، SOA این امکان را می‌دهد تا به دفعات از همان عملکردهای (رفتارهای) یک نرم‌افزار کاربردی استفاده کنیم، بدون آنکه مجبور به انتقال کد باشیم. به این ترتیب می‌توان رفتار یک نرم‌افزار کاربردی را مورد استفاده قرار دهیم.

2- چالاکی یا توانایی تغییر فرآیندهای تجاری بر روی جریان‌های اطلاعاتی و سرویس‌های موجود، به طور سریع و مورد نیاز، برای پشتیبانی از کسب و کاری که دائماً تغییر می‌کند.

3- نظارت یا توانایی دیده‌بانی نقاط اطلاعاتی و نقاط سرویس به صورت بلادرنگ، برای تعیین سلامت یک سازمان یا بانک. به علاوه، SOA توانایی تغییر و تنظیم پردازش‌ها بر اساس منافع بانک را به صورت بلادرنگ فراهم می‌کند.

4- افزایش برد یا توانایی آشکار کردن پردازش‌های معین بانک برای سایر ماهیت‌های خارجی با هدف همکاری یا پردازش‌های اشتراکی

مشکلات پیاده‌سازی SOA

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

•    عوامل هزینه: معماری SOA نیاز به آن دارد که درک کاملی از عوامل مختلف هزینه‌ای در بانک داشته باشد این مسئله صرف نظر از محدودیت جغرافیایی یا اجرایی کسب و کار است.

•    فرهنگ سازمانی: معماری SOA برای طراحی مناسب برنامه و شناسایی سرویس‌های مشترک همچنین روابط میان رشته‌ای و بین کسب و کاری، نیازمند فرهنگ سازمانی است.

•    سناریوهای احتمالی در آینده: با پیاده‌سازی این معماری ممکن است روند سیستم، دچار اختلال شود برای همین نیازمند فهم بهتر روندها و تأثیری که فناوری‌ها روی آن می‌گذارد است و به همین منظور باید به تجزیه و تحلیل کامل سازمان پرداخت؛ همچنین معماران سازمانی باید برای طراحی استاندارد‌های مناسب، تمامی سناریوهای بالقوه‌ای را که ممکن است در آینده اتفاق بیفتد شناسایی کنند.

•    فهم فنی: تعریف استاندارد SOA، رویکردی جدید برای توسعۀ برنامه‌های کاربردی است؛ بنابراین تمامی ذی‌نفعان با دانش فنی مختلف نظیر سیستم‌ها و خدمات و پروتکل‌ها در اجرا دخیل باشند.

•    به حداقل رساندن مخاطرات: معماری SOA باید از تمامی مقررات نظارتی و کنترل‌های داخلی که برای اجرای ایمن سیستم‌های بانکی و معاملات است پیروی کند.

پیاده‌سازی معماری چالاک آینده

یک معماری چالاک SOA ارتباطات زائد را حذف و فرآیند بانک را ساده می‌کند. بانک‌ها برای ساختن معماری آی‌تی خود نیازمند استانداردهای SOA هستند تا بتوانند منطبق بر استانداردهای BIAN خود را منطبق سازند. در شکل 8 شمایی از سرویس‌های BIAN ارائه شده است. استاندارد BIAN از سه عنصر اصلی تشکیل شده است.

•    بخش کسب و کار بالاترین سطح این طبقه‌بندی است که مجموعۀ گسترده‌ای از قابلیت‌های کسب و کاری که برنامه‌های کاربردی و اطلاعاتی را در یک گروه قرار می‌دهد.

•    بخش کسب و کار مجموعه‌ای منسجم از قابلیت‌ها را در حوزۀ کسب و کاری تعریف می‌کند و با مهارت‌ها و علوم خاص بانکی مرتبط است.

•    بخش سرویس‌ها بهترین سطح این دسته‌بندی است و هر بخش قابلیت‌های کسب و کاری منحصر به فردی را تعریف می‌کند.

فناوری‌هایی که تصورات قدیمی را در مورد چشم‌انداز، انعطاف‌پذیر بودن فرآیند و سرعت تحویل و پایین آوردن هزینه‌های پشتیبانی را تغییر می‌دهد معماری کسب و کار بانکی را متحول می‌کند.

یک معماری چالاک SOA باعث از بین رفتن روابط موازی می‌شود به شکل شمارۀ 9 توجه کنید در حال حاضر، معماری بانکی محصولات را در قسمت‌های مختلف قرار داده است و آنها به صورت مختلف فراخوانی می‌کند که این مسئله باعث پیچیده‌تر شدن لینک‌ها و ارتباطات با هم می‌شود. ادغام بخش‌های مختلف باعث تولید محصولات متنوع‌تر می‌شود و معماری بانکی را بسیار ساده‌تر می‌کند در نتیجه قابلیت ارتباط و همکاری بهتری بین عملکردهای اصلی و سرویس‌های داخلی برنامه فراهم می‌آورد. این امر پیچیدگی فعالیت‌های کربانکینگ و هزینه‌ها را افزایش می‌دهد. یک معماری چالاک می‌توان محصولات جدیدی را بدون آنکه روی سرویس‌ها و رابطۀ بین آنها تأثیر بگذارد ایجاد کرد و آن را به صورت یکپارچه انجام داد.

آینده معماری چالاک

استانداردهای SOA در آینده، برنامه‌های کسب و کار و فناوری‌های مختلف را تغییر می‌دهند و مفاهیم جدیدی از انعطاف‌پذیری فرآیند، بینش، سرعت تحویل و پشتیبانی را عرضه می‌کنند.

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

توصیه‌هایی برای بانک‌ها

برای انتخاب روش تحول مناسب باید شکاف‌ها و تغییرات فرآیند بین وضعیت مورد نظر و معماری فعلی شناسایی شود.

بسته به استراتژی‌ها و اهداف کربانکینگ، بانک‌ها می‌توانند یکی از چهار رویکرد را برای تحول در معماری اتخاذ نمایند:

•    معماری SOA معماری سازگار با فعالیت‌های اصلی بانک و کاهش هزینۀ ادغام است، چشم‌انداز سرویس مشترک باعث توسعۀ معماری می‌شود که با نیازهای فعلی و آینده بانک همسو است.

•    چالاکی رو به جلو: بانک‌ها به جای اصلاح اساسی سیستم‌های کربانکینگ می‌توانند با سفارشی‌سازی گام به گام بدون آنکه محصولات قدیمی‌تر را تغییر دهند از مزایای رقابتی آن استفاده کنند. همچنین بانک باید مشخص کند آیا این تغییر از فرآیندهای کسب و کاری و محصولات کربانکینگ قبلی پشتیبانی می‌کند یا خیر؟

•    کربانکینگ بر بستر کلاود (ابری): برای مسئله خدمات ابری بانک‌ها از گزینه‌های مختلف مثل قیمت‌گذاری، یکسان‌سازی فرآیندها، برنامه‌ها، زیرساخت‌ها و پلتفرم‌ها استفاده می‌کنند. این روش شاید باعث بالا رفتن ریسک در بانک بشود چرا که برخی از سرویس‌ها بر بستر کلاود انجام می‌شود. مثل بازیابی خرابی و ذخیرۀ اطلاعات

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

اتخاذ یک روش کاملاً مشخص برای نیل به موفقیت بسیار ضروری است و برای این کار می‌باید دستورالعمل استراتژیک در بانک آماده باشد به شکل 12 نگاه کنید.

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

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

•    بانک‌های ردۀ متوسط بودجه کمتری دارند و نیازکمتری به سفارشی‌سازی دارند برای این دسته می‌توان از راه‌حل‌هایی مبتنی بر خرید پکیج‌هایی با تعداد آپشن کمتر استفاده کرد مثل راه‌حل )پکیج بانکی)Bank-in-a-Box  که رویکردها را به سرعت اجرایی می‌کند.

•    بانک‌های رده پایین به کمترین سطح سفارشی‌سازی نیاز دارند و می‌توانند مدیریت مرکز داده خود را به شرکت‌های معتبر واگذار کنند. راه‌حل ابری یکی از این راه‌حل‌هاست.

عوامل کلیدی موفقیت

در حالی که تلاش‌های بسیاری برای معماری فناوری اطلاعات در بحث سازمانی صورت گرفته است، اکثر راه‌حل‌ها تنها یک لایۀ جدید از فناوری را بر روی فناوری‌های موجود قرارداده‌اند، با این امید که فناوری جدید بتواند مشکلات را برطرف کند. تعداد اندکی از بانک‌ها حاضر به پذیرش ریسک و مواجه شدن با مشکلات کربانکینگ خود هستندSOA، عملاً به اصلاح و ترمیم معماری‌های موجود مربوط می‌شود، با در نظر گرفتن اینکه اکثر سیستم‌های مهم به عنوان سرویس و خلاصه کردن این سرویس‌ها در یک حوزه (Domain) واحد که درآن راه‌حل‌ها را تشکیل می‌دهند. SOA بهترین روش ممکن برای اصلاح معماری‌های آسیب‌دیده به حساب می‌آید.

با استفاده گسترده از استانداردهایی نظیر سرویس‌های وب، SOA به عنوان بهترین روش برای ایجاد چالاکی معماری در ساختار بانکی معرفی می‌شود (البته اگر SOA را به طور صحیح انجام شود). از سویی این زیرساخت یک روش معتبر برای حل بسیاری از مشکلات معماری است که بانک‌ها امروز با آنها مواجه هستند. مشکلی که این ساختار با آن دست به گریبان هستند، افرادی هستند که SOA را پیاده‌سازی می‌کنند، بسیاری از پروژه‌های SOA به خرید فناوری تبدیل شده‌اند؛ مثل یک پکیج معماری SOA، ولی عملاً SOA نیستند. این وضعیت تنها باعث افزایش مشکلات می‌شود.

در عین حال، برای پیاده‌سازی موفق SOA باید آن را به بخش‌های کوچک و افزایشی تقسیم کرد که سانک را به سمت ارزش مطلق SOA حرکت می‌کند و این ارزش مطلق زمانی که با مفاهیم نوظهوری نظیر محاسبات ابری به کار برده شود، قدرتمندتر نیز خواهد شد.

ما می‌توانیم این ترکیب را به صورت «SOA کوچک» و «SOA بزرگ» تفکیک کنیم. SOA بزرگ، اهداف استراتژیک بزرگ‌تر SOA را در بر می‌گیرد: حرکت همزمان تمام بخش‌های آی‌تی به سمت چیزی که بسیار چالاک‌تر است و به آسانی تغییر می‌کند؛ مثلاً می‌توانیم به تجزیة تمام سیستم‌های مرتبط با بانک به صورت یک جزء کاربردی ابتدایی و بازسازی آنها به صورت سرویس‌ها و اضافه کردن یک لایه پیکربندی پردازش برای تشکیل راه‌حل‌ها اشاره کنیم. با در نظر گرفتن این واقعیت که ساختار بانک صدها و گاهی اوقات هزاران سیستم را می‌تواند شامل باشد این پروژه می‌تواند سال‌ها طول بکشد.

SOA کوچک تنها یک نمونه از یک SOA بزرگ است. در واقع SOA کوچک هنوز SOA به حساب می‌آید؛ اما دارای یک محدوده زمانی، اهدافی که به خوبی تعریف شده‌اند و همچنین یک بازگشت سرمایه‌ای است که باید با آن انطباق پیدا کند. استفاده از SOA کوچک برای رسیدن به SOA بزرگ است. برای نمونه، می‌توان یک پرتال برای همکاران و شرکای بانک را با استفاده از شیوه‌های SOA ایجاد کرد که در طول شش ماه قابل راه‌اندازی است و سرمایة خود را تنها در مدت سه ماه برمی‌گرداند. یک مزیت آشکار و یک پروژة کوچک و عملی که در مدت یک سال به پایان خواهد رسید.

در حالی که SOA کوچک عملی به نظر می‌رسد، SOA بزرگ تا حدود زیادی به دلیل آنکه بیش از حد پیچیده است و پیگیری آن بیش از حد پرهزینه است، رها می‌شود. واقعیت این است که به هر دوی آنها نیاز داریم؛ اما باید بدانیم که چگونه هر دوی آنها را به کار گیریم.

برای تغییر موفق در معماری، ارزیابی پارامترهای کلیدی کسب و کاری و فناوری اطلاعات و انتخاب رویکردهای مناسب بر اساس نیاز، بسیار مهم است به شکل 13 نگاه کنید.

دکتر شهرام تقی پور؛ تحلیلگر و طراح ارشد سامانه های بانکی
منبع: ماهنامه بانکداری آینده

لینک کوتاهلینک کپی شد!
ممکن است شما دوست داشته باشید
ارسال یک پاسخ

27  −    =  20