منظور از معماری سرویس گرا در بانکداری الکترونیک چیست؟ (+ با مثال ساده)


Warning: Undefined variable $custom_content in /home/asreba/public_html/wp-content/themes/AsreBank/functions.php on line 24
در معماری SOA شما تعدادی ماجول یا واحد نرم افزاری دارید که می‌توانند برای انجام کارهای مختلف چیدمان شوند و کارکردهای متفاوت شما را پاسخگو باشند.

عصر بانک؛ “معماری سرویس گرا” به عنوان یکی از آخرین دستآوردها در تولید نرم افزار، به نظر می رسد،  در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود که در ذهن تعدادی از معماران آن وجود داشت و آن ” نرم افزار به عنوان سرویس” بود.

معماری سرویس گرا در بانکداری الکترونیک

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

 

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

 

این معماری توسط دو شرکت IBM, Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب  و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانندUDDI,WSE بوده اند.

معماری سرویس‌گرا  ( Service-oriented Architecture)، رهیافتی‌ست برای ساخت سامانه‌های توزیع‌شده که کارکردهای نرم‌افزاری را در قالب سرویس ارائه می‌کند.

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

یکی از روندهای صنعت بانکداری الکترونیک ،  معماری SOA یا Service Oriented Architecture است ، به این معنا که این معماری در تعریف کسب و کار بانک‌ها کاربرد خواهد داشت. سرویس گرایی در واقع رهیافتی‌ست برای ساخت سامانه‌های توزیع‌شده که کارکردهای نرم‌افزاری را در قالب سرویس ارائه می‌کنند. بدین معنا که از این سرویس‌ها هم می‌توان برای فراخوانی در نرم‌افزارهای دیگر و هم برای ساخت سرویس‌های جدید استفاده کرد. سامانه‌ای که بر معماری سرویس‌گرا استوار است، کارکرد را به عنوان مجموعه‌ای از سرویس‌های سازگار دسته‌بندی می‌کند که می‌توانند در چندین سامانه مجزا استفاده شوند.

 

مثال ساده از SOA

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

 

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

 

ارتباط معماری SOA با عقود اسلامی

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

 

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

فواید SOA  برای مشتریان بانکها

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

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

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

SOA  و اوراق بهادار

 

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

 

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

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

تغییر معماری نرم افزاری بانک‌ها کافی است؟

 

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

یک مشتری می‌تواند درخواست کند که مایل است منابعش را در صنعت پتروشیمی یا کشاورزی یا… سرمایه گذاری نماید. یا مثلا مشتری مایل است که هفتاددرصد از سپرده‌هایش در صنعت و مابقی در کارهای عام المنفعه یا خیریه به کار گرفته شود.

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

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

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

SOA  در بانکداری اسلامی

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

تهدیدات مهاجرت به معماری سرویس گرا

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

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

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

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

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

برگرفته از مصاحبه آقای دکتر ولی الله فاطمی با روزنامه دنیای اقتصاد

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.