پایگاه خبری راه پرداخت دارای مجوز به شماره ۷۴۵۷۲ از وزارت فرهنگ و ارشاد اسلامی و بخشی از «شبکه عصر تراکنش» است. راه پرداخت فعالیت خود را از دوم اردیبهشت‌ماه ۱۳۹۰ شروع کرده و اکنون پرمخاطب‌ترین رسانه ایران در زمینه فناوری‌های مالی، بانکداری و پرداخت و استارت‌آپ‌های فین‌تک است.
احسان حق‌پناه، مشاور فناوری اطلاعات، مرکز نوآوری ایران زمین و وحید محمودیان، مدیر عامل، مرکز نوآوری ایران زمین / متن حاضر ترجمه مقاله‌ای با همین عنوان از وب‌سایت فینکستِرا با کمی تغییرات برای روان‌تر شدن آن است که با هدف آشنایی مدیران فناوری اطلاعات بانک‌های کشور با محصولات و فناوری‌های موجود و نیز کمک به تصمیم‌گیری آنها در انتخاب فناوری مورد نیازشان، تهیه شده است. رونوشت کامل‌تر و قابل چاپ از این متن اینجا در دسترس است.
مقدمه
آیا شما یک مدیر ارشد اطلاعات، مدیر ارشد فناوری و یا معماری هستید که در تلاش است تا رویکرد فناوری‌های مختلف در دگرگونی بانکداری دیجیتال را درک کند؟
متن حاضر، نگاه یک نفر خودی این صنعت به آنچه در جریان است را نشان می‌دهد. توجه کنید که مطالب ارائه شده در این مقاله، دیدگاه‌های شخصی نویسنده به عنوان یک معمار راهکار در مامبو (موتور هسته بانکداری ابری) و بَک‌بِیس (پلتفرم اُمنی‌چَنل بانکداری دیجیتال) ظرف شش سال گذشته و البته مبتنی بر تجربه ناشی از درگیری در پروژه‌های بانکداری دیجیتال از لایه یک تا لایه نئوبانک، در سراسر جهان است.
امروزه بیشتر بانکها به نحوی درگیر فرآیند دگرگونی دیجیتال هستند خواه پیاده‌سازی راهکارهایی تک‌منظوره (Point Solutions) باشد یا تحمل یک دگرگونی همه جانبه و یا راه‌اندازی مدلهای کسب‌وکاری موازی که ترکیبی از این دو روش است. در هر صورت تحقیقات مکنزی حاکی از آنست که 70 درصد طرح و برنامه‌های تغییرات پیچیده بزرگ مقیاس، به اهداف عنوان شده خود نمی‌رسند.
با توجه به شباهت فناوری‌های پیشنهادی موجود در بازار و همچنین «هزینه نهایی تصاحب» و «زمان ورود به بازار» اهداف کسب‌وکاری، امروزه انتخاب رویکردی درست برای مدیران ارشد اطلاعات، مدیران ارشد فناوری و معماران بنگاه‌های اقتصادی، نه تنها ساده نشده که حتی پیچیده‌تر نیز شده است.
اگر ما به لایه نهان رویکرد فناوری پلتفرم‌های معروف بانکداری دیجیتال نگاه کنیم می‌توانیم به یک پرسش اساسی و عمومی پاسخ دهیم که «خرید فناوری یا ساخت آن؟»
فروشندگان و پلتفرم‌ها
از دید تاریخی، بانکداری هیچگاه مبتنی بر لبه فناوری نبوده و همواره راهکارهای موفق دیگر بنگاه‌های بزرگ اقتصادی را پذیرفته و به کار گرفته است. بنابراین بیشتر راهکارهای بانکداری دیجیتال امروزی، همگی اشتقاقی از پلتفرم‌های توسعه وب و موبایل سنتی هستند.
در ادامه هر یک از این موارد را بررسی می‌کنیم:
- پلتفرم‌های تجربه دیجیتال (Digital Expirence Platforms)
- پلتفرم‌های با کدنویسی اندک (Low – Code Platforms)
- برنامه‌های کاربردی پیش‌ساخته (Pre built Applications)
پلتفرم‌های تجربه دیجیتال
عبارت DXP یک واژه پوششی است که فارستر آن را برای پرتال‌های افقی و سامانه‌های مدیریت محتوای وب ارائه کرد. از دید تاریخی پرتال‌ها برای تجمیع برنامه‌های کاربردی مستقل از هم در قالب یک تجربه کاربری واحد، طراحی می‌شدند و معماری آنها حول مفاهیم وب‌سایت‌ها، صفحات و ویجت‌ها انجام می‌شد. امروزه UX بر پایه سیر کاربری و برنامه‌های کاربردی تک صفحه‌ای پیاده‌سازی می‌شود که به خوبی بر مفاهیم مرتبط با پرتال منطبق نمی‌شود.
از آنجایی که پرتال‌ها عموما بی‌وضعیت هستند، لازم است تا یک سامانه BPM یا یک لایه میانی در معماری سامانه در نظر گرفته شود تا در سناریوهای اومنی‌چنل، وضعیت، حفظ و مدیریت شود. موبایل نیز در این اکوسیستم یک شهروند درجه دوم است و پس از یک تجربه با رویکردهای هیبریدی، امروزه تامین‌کنندگان پلتفرم‌های دیجیتال، کیت‌های توسعه نرم‌افزار ذاتی مستقل به ازای پلتفرم‌های مختلف موبایل را به عنوان محصولات جانبی ارائه می‌کنند.
شرکت‌های آوالوک، بَک‌بِیس و تعدادی دیگر، راهکارهای مدل بانک را که شامل پرتال‌های از پیش آماده، ویجت‌ها و برنامک‌های موبایل مبتنی بر DXP ها است، ارائه می‌کنند.
پلتفرم‌های با کدنویسی اندک
تِمِنُوس یکی از نخستین داوطلبان ورود به بانکداری دیجیتال با راهکار کدنویسی اندک از طریق تصاحب کمپانی Edge IPK در سال 2012 بود که بعدها آن را به تِمِنُوس UXP تغییر نام داد. از آن به بعد کدنویسی اندک روند رو به افزایشی داشته و فروشندگانی مانند آپیان، پِگا، مِندیکس، اُوت‌سیستمز و کاونی پیشروان پلتفرم‌های توسعه برنامه‌های کاربردی موبایل و PaaS های تولید برنامه‌های کاربردی با بهره‌وری بالا و با کمک ابزارهای طراحی دیداری که تجربه امنی‌چنل و همچنین فرآیندها و توابع برنامه‌نویسی کاربردی را بصورت خودکار تولید می‌کند، شده‌اند.
شرکت کاونی همچنین یکی از فروشندگان محصولات مستقل از صنعت است که یک مرجع پیاده‌سازی مدل بانک نیز ارائه می‌دهد.
برنامه‌های کاربردی پیش‌ساخته
تعدادی از فروشندگان فناوری مانند مالازایی، در ارزش افزوده استفاده از پلتفرم‌های توسعه اختصاصی نسبت به برنامه‌های کاربردی سنتی مبتنی بر دات‌نت یا جاوا با قابلیت متناسب‌سازی در سطح پروژه، تردید دارند.
یک نمونه از چنین مواردی گروه IND است که در سال 2014 توسط مای‌سیس تصاحب شد. این فین‌تک مجارستانی، زمانی که تصاحب شد، به بیش از 30 بانک خدمت‌رسانی می‌کرد و از یک رویکرد متناسب‌سازی عمیق و تحویل پروژه‌ها در قیمت پایین و زمان کوتاه ورود به بازار پیروی می‌کرد. در آن زمان، تغییر رویکرد به سمت بنگاه‌های بزرگ اقتصادی، مهم‌ترین دغدغه مای‌سیس بود چرا که مدل کسب‌وکاری آنها متناسب با فروشندگان هسته بانکداری بود؛ یعنی اشتراک‌های سنگین و گران‌قیمت.
این مدل کسب‌وکاری در تقابل با رویکرد و مدل پروژه‌ای IND در آن زمان بود. پس از تصاحب، تصمیم بر آن شد تا راهکار بازتولید شده و اجزای آن ریزدانه‌تر و قابل‌نگهداری‌تر شود و در عین حال همچنان انعطاف‌پذیری و جایگاه در بازار راهکار قدیمی در راهکار بازتولید شده حفظ شود. اورکل از سوی دیگر موفق شد تا با تغییر ساختاری در محصول خود ظرف یکی دو سال، مدل بانک خود را مبتنی بر فناوری سبک و روان اوراکل جت ارائه کند.
مقایسه قابلیت‌ها
به جای فرآیند پیچیده و اغلب جانبدارانه مبتنی بر تهیه RFP که معمولا توسط تحلیلگران هر دو حوزه بانکداری و صنعت انجام می‌شود، ما می‌خواهیم فروشندگان فناوری را بر اساس توانمندی‌های پلتفرم‌هایشان دسته‌بندی و آنهایی که نیازمندی‌های فناوری و کسب‌وکاری آینده را هدف قرار داده‌اند، ارزیابی کنیم.
ما در این ارزیابی از جنبه‌هایی از نرم‌افزار که عموما ذهنی و شخصی (مانند قابلیت استفاده) و یا به پیاده‌سازی مرتبط است (مانند کارایی)، چشم‌پوشی و بر آن دسته از ویژگی‌هایی که حاصل طراحی و معماری راهکار هستند، تمرکز می‌کنیم.
یکپارچگی
سهولت ایجاد سیر مشتری روی چندین کانال
پلتفرم‌های با کدنویسی اندک در ارائه این قابلیت پیشتاز هستند چرا که آنها به نحوی ساخته شده‌اند تا طراحی فرآیندها و رابط‌ها به کمک ابزارهای دیداری انجام شود. بیشتر آنها اومنی‌چنل هستند و رابط کاربری ذاتی برای هر دو پلتفرم وب و موبایل تولید می‌کنند.
از سوی دیگر، پرتال‌ها به گونه‌ای معماری می‌شوند که مناسب برنامه‌های کاربردی مجزا از یکدیگر باشند و به صورت بی‌وضعیت طراحی می‌شوند. بنابراین اومنی‌چنل کردن یک فرآیند، نیازمند سرویس‌های زیرساختی است تا وضعیت را در سیر کاربری حفظ و مدیریت کند؛ مانند BPMها، میان‌افزارها و یا نرم‌افزارهایی که بطور خاص برای این کار توسعه داده شده‌اند.
البته این همه تنها برای وب است و بنابراین برای داشتن تجربه موبایلی نیاز است تا جدا از رابط‌های کاربری وب، رابط‌های کاربری مجزایی برای هر یک از پلتفرم‌های موبایل iOS و Android ایجاد و یا این که از یک تجربه فرعی وب واکنشی استفاده شود.
پلتفرم برنامه‌های کاربردی پیش ساخته، معمولا سیرهای آماده و حاضر را فراهم می‌آورند و در صورتی که شما بخواهید چیزی فراتر از دامنه مدل بانک بسازید و یا در آن تغییری ایجاد کنید، خب! دیگر همه چیز به عهده خود شماست چرا که چیزی از قبل آماده نیست.
مدیریت‌پذیری
سطح چابکی کسب‌وکار در مدیریت پلتفرم بدون نیاز به دخالت فناوری اطلاعات
پلتفرم‌های با کدنویسی اندک و یا برنامه‌های کاربردی پیش‌ساخته، ابزار خاصی برای کارشناسان کسب‌وکار جهت مدیریت پلتفرم ندارند در حالی که پرتال‌ها، ویرایشگرهایی برای صفحات دارند که به دپارتمان بازاریابی و محصول اجازه می‌دهد تا تغییرات در محتوا و یا راه‌اندازی یک کمپین جدید را به سادگی انجام دهند.
با این حال، مسیر واقعی چابکی در کسب‌وکار، دگرگونی سازمانی است که شامل تیم‌های چندکاره و DevOps به‌صورت یک فرهنگ است و نه صرفا تنها یک دپارتمان کسب‌وکار و بازاریابی.
یک نمونه عالی از این رویکرد بررسی موردی مکنزی از دگرگونی چابک ING است که به آنها اجازه داده تا قابلیت‌های جدید را بصورت روزانه، رونمایی کنند.
قابلیت پیکربندی و قابلیت متناسب‌سازی
سهولت در تغییر مدل بانک یا ارائه کارکردهای نوین
بحث و جدل گسترده‌ای درباره اینکه چه چیزی باید قابلیت پیکربندی و قابلیت متناسب‌سازی در نظر گرفته شود، وجود دارد. ما آن را به عهده توسعه‌دهندگان و برنامه‌نویسان می‌گذاریم تا تصمیم بگیرند که ترجیح می‌دهند کد بنویسند یا از ابزارهای دیداری استفاده کنند. نکته مهمی که باید درک شود آن است که استفاده مجدد از کارکردهای مدل بانک محدودیت دارد.
در پلتفرم‌های با کدنویسی اندک، چنین ویژگی‌ای بسیار بالا است چرا که شما می‌توانید مدل بانک را در سطح اجزا تغییر دهید. در پلتفرم‌های مبتنی بر پرتال‌ها، نیاز است تا در سطح ویجت تصمیم گرفته شود که آنها را همان جوری که هستند بپذیرید و یا ویجت‌های اختصاصی خودتان را ایجاد کنید.
راهکارهای با کدنویسی کم چنین قابلیتی را با ارائه یک لایه انتزاعی روی API های پلتفرم‌های وب و موبایل فراهم می‌سازند اما همچنانکه جول اسپولسکی می‌گوید: «همه انتزاعات غیر بدیهی، به درجاتی، رخنه پذیرند.»
همه فروشندگان پلتفرم‌های مبتنی بر پرتال‌ها و برنامه‌های کاربردی پیش‌ساخته نوعی از «نقاط توسعه‌پذیری» را برای اجزای رابط کاربری و سرویس‌های خاص فراهم می‌سازند. ایده نهان پشت این الگو، افزایش امکان پذیرش کارکردهای پیش‌فرض در اجزای از قبل آماده شده است تا در حالتی که تنها بخش‌هایی از منطق کسب‌وکار نیازمند تغییرات است، چنین چیزی با تغییرات جزئی و با سهولت امکان‌پذیر باشد.
مشکلی که در این حالت رخ می‌دهد آن است که رابط کاربری و لایه‌های یکپارچه‌سازی و اتصال بیش از حد مهندسی شده خواهیم داشت که بهینه‌سازی آنها برای فروشندگان سخت و دشوار است. آنچنانکه مارتین فاولر در بحث طراحی پیوسته اشاره می‌کند که طراحی‌های پیشاپیش اغلب شامل هوک‌های توسعه‌پذیری هستند که تغییرات در طراحی‌های آینده را امکان‌پذیر سازد. این رویکرد طراحی پیوسته را سخت و دشوار می‌سازد و باید از آن پرهیز شود.
این روش از کار نه فقط کدهای مدل بانک را تا حد زیادی پیچیده می‌کند؛ بلکه به شدت، سبب ایجاد انبوهی از کدهای باد کرده می‌شود چرا که برای حفظ سازگاری وارون چاره‌ای جز حفظ API های منسوخ شده و قدیمی نداریم. رویکرد و روش جایگزین استفاده از الگوی طراحی ترکیب بر اساس وراثت و افزونه‌ها است.
قابلیت ارتقاپذیری
تلاش‌های لازم و مخاطرات احتمالی در ارتقای پلتفرم و بانک مدل
در هر راهکار دو جزء اصلی هستند که لازم است به وسیله فروشنده بهروزرسانی شود؛ پلتفرم و مدل بانک. در راهکارهای مبتنی بر کدنویسی اندک و پرتال‌ها، ارتقاپذیری هسته پلتفرم معمولا مشکل خاصی ندارد چرا که به‌صورت جعبه سیاه طراحی و پیاده‌سازی شده و از تغییرات دیگر لایه‌ها و اجزا محافظت شده است. اما در ارتقا مدل بانک داستان جور دیگری است.
فروشندگان راهکارهای با کدنویسی اندک مدل بانکها را فقط به عنوان پایه پلتفرم فراهم می‌سازند و به محض اینکه شما چیزی را در آن تغییر دادید، دیگر همه تغییرات بعدی و در هر جایی از سامانه به عهده خود شما است.
در راهکارهای مبتنی بر پرتال‌ها و برنامه‌های پیش‌ساخته، رابط کاربری و افزونه‌های سرویس، معمولا جداگانه مدیریت می‌شوند. این موضوع به شما اجازه می‌دهد تا راهکار را به نسخه‌های جدیدتر مدل بانک ارتقاء دهید.
با این حال در عمل و اجرا، یک به روزرسانی در هر جزئی، نیازمند QA همه کارکردهای سامانه است چرا که API های افزونه، معمولا جزئیات پیاده‌سازی را به دنیای خارج از آن جزء و دیگر اجزا و لایه‌های نرم‌افزاری منتقل کرده و آنها را متأثر می‌سازند و احتمالا سبب تغییرات در آنها نیز خواهند شد.
پرتال‌ها و برنامه‌های پیش‌ساخته معمولا از فریم‌ورک‌های ثالثی برای وب و موبایل استفاده می‌کنند که چرخه حیات خود را دارند و هر تغییر در آنها ممکن است پیاده‌سازی شما را دست‌خوش تغییر قرار دهد و حتی ممکن است شما را مجبور به بازنویسی کدهایتان کنند. یک نمونه شناخته شده منسوخ شدن Liferay Alloy هنگام تعطیل شدن پروژه YUI یاهو است.
نمونه دیگری از این موضوع، وضعیت بسیاری از فروشندگانی است که AngularJS نسخه یک را پیاده‌سازی و به‌کار گرفته‌اند و امروزه در پی آن هستند که با آن چه کار کنند چرا که گوگل Angular نسخه دو را ارائه کرده و این نسخه سازگاری وارون با نسخ قبلی ندارد!
از کجا شروع کنیم؟
از مقایسه قابلیت‌ها برای فرآیند انتخاب خود استفاده کنید و توجه داشته باشید که همه معماری‌ها مصالحه‌ای بین نقاط قوت و ضعف هستند آنچنان که فِرِد بروکس می‌گوید: «هیچ گلوله نقره‌ای وجود ندارد.»
اگر تصمیم دارید تا یک تجربه «اوبر برای بانکداری» به صورت راحت و آماده عرضه داشته باشید، بهتر است در انتظارات خود تجدید نظر کنید. در نظر داشته باشید که اوبر بیش از 100 مهندس را فقط برای توسعه پلتفرم iOS استخدام کرده و نئوبانک‌هایی مانند مونزو، چندین تیم که هر کدام روی بخش‌هایی از برنامک‌شان کار می‌کنند، در اختیار دارند.
قابلیت‌های ذکر شده را اولویت‌بندی کنید به ویژه آنهایی که بر مهارت‌ها و راهبردهای فناوری تیم‌تان منطبق است. هیچگاه در پی عبارت‌ها و واژه‌های مد روز نباشید. در نظر داشته باشید که اگر گوگل از معماری مایکروسرویس استفاده می‌کند بدان معنی نیست که شما هم باید چنین کنید.
حتی یکی از اَوَنْجِلیست‌های مطرح، مارتین فاولر، چنین موضوعی را به چالش می‌کشد چرا که استفاده از معماری مایکروسرویس هزینه‌های اضافی بر شما تحمیل می‌کند: «شما الزاما نباید پروژه‌های جدیدتان را بر اساس معماری مایکروسرویس بنا کنید، حتی اگر مطمئن هستید که برنامه کاربردی شما به‌قدر کافی بزرگ خواهد شد که چنین کاری ارزشش را داشته باشد.»
تحول دیجیتال یک هدف پایان‌پذیر نیست بلکه یک فرآیند ادامه‌دار است. هرچند توانمندی‌های مدل بانک و یا تعهد فروشندگان به تحویل آن توانمندی‌ها، ممکن است تصمیم نهایی را تحت تأثیر قرار دهد، درک این نکته که محدودیت‌های پلتفرم‌ها نقشه راه و راهبرد شما را ترسیم می‌کنند، اهمیت بسیار دارد. به هرحال برای خودتان مسائل و مشکلات جدید نسازید و به فکر راهکارهای درست باشید.
هر چند ما به اهمیت تفاوت در معماری‌های پلتفرم‌های پیشنهادی کاملا واقف هستیم با این حال توجه داشته باشید که هیچ تک راهکار عمومی و جهانی وجود ندارد.
منبع
فینکسترا