Нельзя один раз внедрить интернет-банк и на этом остановиться — банку обязательно нужны доработки: через полгода изменятся требования регулятора и понадобятся новые сервисы, а через пять лет критично устареет интерфейс.
У банков есть два варианта развития ПО: либо подсесть на контракт с вендором, который будет дорабатывать решение, либо улучшать интернет-банк самостоятельно. Иметь свою лабораторию удобно — это ускоряет процесс улучшений, банк перестаёт зависеть от вендора и ждать своей очереди доработок. Как подойти к формированию внутренней цифровой экспертизы, рассказываем в нашей статье.
Читайте в статье:
1. Зачем банку инхаус-компетенция?
2. Каким путём банки могут развивать свои цифровые каналы
3. Что нужно для создания инхаус-компетенции?
4. Открытый или частично открытый код
5. Выбираем архитектуру решения
6. На каком языке должно быть написано ПО
7. Дополнительные критерии выбора вендора
8. Чек-лист: выбираем оптимальное решение
Зачем банку инхаус-компетенция?
Внутренняя команда разработки, или инхаус-лаборатория, позволяет быстро развивать цифровые каналы — от готовности работать с клиентами онлайн зависит успешность банков на рынке.
По данным исследования консалтинговой компании Bain, которая проанализировала 50 ведущих европейских и ближневосточных банков, банки-цифровизаторы получают три преимущества перед традиционными.
По данным исследования консалтинговой компании Bain, которая проанализировала 50 ведущих европейских и ближневосточных банков, банки-цифровизаторы получают три преимущества перед традиционными.
Преимущества цифровых банков
- Клиенты более лояльны к цифровым банкам. Цифровизация позволяет клиентам быстрее, дешевле и проще получать доступ к продуктам и услугам, и улучшает пользовательский опыт.
- HR-рейтинг цифровых банков выше — их сотрудники видят карьерные перспективы, больше нацелены на лидерство и вовлечены в работу.
- Акционеры технологичных банков зарабатывают больше.
Каким путём банки могут развивать свои цифровые каналы
1. Разработать новое решение с нуля
— Долго, дорого, сложно
Этот вариант доступен в основном банкам из топ-10, у которых есть возможность собрать команду разработчиков размером до тысячи человек. Примеры таких команд — Сбертех и Альфалаб, которые выросли из цифрового подразделения в отдельную компанию.
2. Купить готовый современный «коробочный» продукт
— Нужно дорабатывать функционал
Из плюсов — банк получает готовое решение. Из минусов — ни одно коробочное решение не может полностью удовлетворить задачи конкретного банка. Всегда нужны доработки. К тому же рынок очень быстро развивается и продукт должен уметь трансформироваться вместе с ним. Не все вендоры, особенно «бронзовые», могут обеспечить высокую скорость и гибкость. Не имея возможности развивать решение самостоятельно, банк рискует стать «заложником» вендора.
3. Выкупить legacy-код у вендора с намерением доработать
— Устаревший код без преимуществ современных технологий; нет кадров для доработки
Проблема в том что ДБО, которое сейчас находится в эксплуатации, чаще всего написано 10-15 лет назад. Помимо устаревшего кода банк получает проблемы с наймом специалистов. Мало кто на рынке хочет разбираться в непопулярном стеке технологий и монолитной архитектуре. Поэтому банки с legacy-решениями редко создают инхаус-команду для развития исключительно на этой архитектуре и либо развивают ПО только силами вендора, либо, если все таки выкупили код, меняют его кусками очень медленно и дорого, заменяя куски легаси-системы на более современные реализации, если это возможно.
4. Выкупить современное решение и с помощью вендора научиться дорабатывать его самостоятельно
✓ Легко создать инхаус-компетенцию
Это оптимальный вариант для инхаус-разработки, поскольку банк сразу получает готовый функциональную платформу и может быстро начать оптимизировать её: такую систему можно развивать кратно меньшим штатом, чем разработку с нуля. Но на рынке пока мало подходящих вендоров и решений.
— Долго, дорого, сложно
Этот вариант доступен в основном банкам из топ-10, у которых есть возможность собрать команду разработчиков размером до тысячи человек. Примеры таких команд — Сбертех и Альфалаб, которые выросли из цифрового подразделения в отдельную компанию.
2. Купить готовый современный «коробочный» продукт
— Нужно дорабатывать функционал
Из плюсов — банк получает готовое решение. Из минусов — ни одно коробочное решение не может полностью удовлетворить задачи конкретного банка. Всегда нужны доработки. К тому же рынок очень быстро развивается и продукт должен уметь трансформироваться вместе с ним. Не все вендоры, особенно «бронзовые», могут обеспечить высокую скорость и гибкость. Не имея возможности развивать решение самостоятельно, банк рискует стать «заложником» вендора.
3. Выкупить legacy-код у вендора с намерением доработать
— Устаревший код без преимуществ современных технологий; нет кадров для доработки
Проблема в том что ДБО, которое сейчас находится в эксплуатации, чаще всего написано 10-15 лет назад. Помимо устаревшего кода банк получает проблемы с наймом специалистов. Мало кто на рынке хочет разбираться в непопулярном стеке технологий и монолитной архитектуре. Поэтому банки с legacy-решениями редко создают инхаус-команду для развития исключительно на этой архитектуре и либо развивают ПО только силами вендора, либо, если все таки выкупили код, меняют его кусками очень медленно и дорого, заменяя куски легаси-системы на более современные реализации, если это возможно.
4. Выкупить современное решение и с помощью вендора научиться дорабатывать его самостоятельно
✓ Легко создать инхаус-компетенцию
Это оптимальный вариант для инхаус-разработки, поскольку банк сразу получает готовый функциональную платформу и может быстро начать оптимизировать её: такую систему можно развивать кратно меньшим штатом, чем разработку с нуля. Но на рынке пока мало подходящих вендоров и решений.
Что нужно для создания инхаус-компетенции?
— Бюджет
Сумма, которую банк готов вложить в покупку продуктовой платформы и её адаптацию для своих задач.
— Команда разработки
Это не только программисты, но и менеджеры, аналитики, тестировщики, DevOps.
— Инфраструктура для разработки
Система управления проектами и задачами, система контроля версий, ПО для документации и код-ревью и др.
Сумма, которую банк готов вложить в покупку продуктовой платформы и её адаптацию для своих задач.
— Команда разработки
Это не только программисты, но и менеджеры, аналитики, тестировщики, DevOps.
— Инфраструктура для разработки
Система управления проектами и задачами, система контроля версий, ПО для документации и код-ревью и др.
Открытый или частично открытый код: как не обречь себя на вечные расходы
Даже финтех-гиганты не создают свои продукты с нуля, а выкупают готовые решения у цифровых поставщиков, потому что это помогает существенно оптимизировать производство. В зависимости от возможности доработки, код ПО на банковском рынке делится на несколько типов:
- Закрытый исходный код
- Частично открытый исходный код
- Открытый исходный код
ПО с закрытым исходным кодом
Преимущества
Лицензия на такое ПО стоит дешевле, чем на решения, которые поставляются с открытым кодом.
Недостатки
Развивать продукт можно только через вендора.
- Стоимость.
Лицензия на такое ПО стоит дешевле, чем на решения, которые поставляются с открытым кодом.
Недостатки
- Нельзя дорабатывать самостоятельно.
Развивать продукт можно только через вендора.
ПО с открытым исходным кодом
Преимущества
- Неограниченные возможности для доработки и переработки кода.
Недостатки
- Стоимость.
Решения с открытыми исходниками, которые могут быть полностью переработаны, стоят в разы дороже, чем готовое «коробочное» ПО с закрытым ядром.
- Устаревший код.
Приложение приходится переписывать, чтобы оно было востребовано на рынке. В итоге возникает форк — ответвление от основного продукта, развиваемое и сопровождаемое исключительно в банке. Это приводит к потере совместимости с основной версией продукта от вендора и риску потери компетенции в банке.
- Кадры.
Сложно найти квалифицированных разработчиков, которые могут развивать решение, не ломая его.
- Дополнительные расходы.
Если банк не может развивать решение самостоятельно, ему приходится покупать другое или обращаться к вендору за доработками.
ПО с частично открытым исходным кодом
Преимущества
- Стоимость.
Решения с закрытым ядром стоят меньше, чем с полностью открытым кодом.
- Легко развивать.
Дорабатывать решение можно силами команды разработки из 2-10 человек.
Недостатки
- Не всё можно поменять.
Некоторые возможности для доработки кода ограничены лицензией.
Приложения с открытым и закрытым кодом дорого развивать по разным причинам. Решения, которые созданы с закрытым ядром и возможностью кастомизации, остаются самым гибким вариантом для доработок. Далее вы узнаете, как на скорость и стоимость разработки влияют архитектурные особенности ПО.
Выбираем архитектуру решения: разрабатывать быстро или основательно?
Архитектура банковских решений определяет, как разрабатываются и взаимодействуют между собой отдельные компоненты ПО. Прежде чем выбрать архитектуру, банк должен определиться, какую часть решения он хочет дорабатывать — клиентскую (фронтэнд) или серверную (бэкенд). Как правило, банк покупает бэкенд один раз и редко его меняет, поскольку программная часть устаревает в разы медленнее, чем интерфейс. Поэтому срок разработки новых продуктов зависит в основном от особенностей фронтенда.
Архитектура фронтенда в самом широком понимании делится на нативные и кроссплатформенные решения.
Архитектура фронтенда в самом широком понимании делится на нативные и кроссплатформенные решения.
Нативная разработка
Нативными называют программы, которые работают только на одной платформе: в вебе, на iOS или Android. Это самый распространённый вид разработки на рынке.
Преимущества
Нативные приложения имеют более низкое время отклика, низкую вероятность сбоев и зависаний.
Недостатки
На написание программного кода для двух платформ уходит в полтора-два раза больше времени, чем для одной платформы, поскольку инженерам нужно написать две базы кода.
Для каждой платформы нужна отдельная команда разработчиков.
Преимущества
- Высокая скорость и производительность.
Нативные приложения имеют более низкое время отклика, низкую вероятность сбоев и зависаний.
- Больше возможностей для интеграции с платформой, для которой они разработаны, по сравнению с кроссплатформенными решениями.
Недостатки
- Сроки создания приложения
На написание программного кода для двух платформ уходит в полтора-два раза больше времени, чем для одной платформы, поскольку инженерам нужно написать две базы кода.
- Стоимость разработки выше
Для каждой платформы нужна отдельная команда разработчиков.
- В случае попадания банка в SDN-лист все нативные iOS-разработчики и их разработки становятся невостребованными.
Single-core
Single-core архитектура позволяет разрабатывать функционал на единой кодовой базе и моментально переносить его на все платформы. Это даёт возможность дорабатывать ПО руками одной команды и сократить time-to-market до минимальных значений.
Преимущества
Благодаря этому команда разработчиков может использовать один технологический стек для всех платформ и максимально приближенные друг к другу мобильный адаптив (PWA) и мобильные приложения.
Single-core позволяет ускорить начальное развертывание приложения сразу на нескольких платформах, сократить время и сложность апдейтов.
Это позволяет реализовать «бесшовный» переход с одной платформы на другую, например, со смартфона на ноутбук.
Недостатки
Унифицированный стек технологий не позволяет подстраивать функционал приложения под особенности каждой платформы.
Это ограничение обычно не влияет на работу банковских сервисов.
Преимущества
- Единая база кода для всех платформ
Благодаря этому команда разработчиков может использовать один технологический стек для всех платформ и максимально приближенные друг к другу мобильный адаптив (PWA) и мобильные приложения.
- Сокращение времени и стоимости разработки
Single-core позволяет ускорить начальное развертывание приложения сразу на нескольких платформах, сократить время и сложность апдейтов.
- Одинаковый интерфейс приложений
Это позволяет реализовать «бесшовный» переход с одной платформы на другую, например, со смартфона на ноутбук.
Недостатки
- Меньшая гибкость.
Унифицированный стек технологий не позволяет подстраивать функционал приложения под особенности каждой платформы.
- Ниже отзывчивость приложения.
Это ограничение обычно не влияет на работу банковских сервисов.
Что выбрать для инхауса?
Поскольку скорость и бюджет разработки в приоритете, то банкам предпочтительнее выбирать решение, построенное на single-core архитектуре или хотя бы мобильной кроссплатформенности. Это позволит сократить стоимость разработки и time-to-market в 1,5-2 раза.
Нативная разработка vs Single-core: сравним трудозатраты
Мы первыми на рынке финансовых продуктов в РФ реализовали идею single-core архитектуры в готовом продукте в 2018 году.
Abanking разработал для одного из клиентов два мобильных приложения, веб-приложение и веб-адаптив. При нативной разработке потребовалось бы 4 команды — две для мобильных приложений и две — для интернет-банка, чтобы разработать фронтенд и бэкенд. У нас появилась гипотеза, что разработку можно вести кроссплатформенно силами одной команды. Благодаря этому снижается стоимость и растёт скорость разработки.
Эта архитектура получила название single-core. Она предполагает создание единой кодовой базы для всех платформ и единого функционала, который можно моментально масштабировать на все форматы приложений. Например, если банк делает доработку для мобильного приложения, она автоматически появляется в веб-версии.
Abanking разработал для одного из клиентов два мобильных приложения, веб-приложение и веб-адаптив. При нативной разработке потребовалось бы 4 команды — две для мобильных приложений и две — для интернет-банка, чтобы разработать фронтенд и бэкенд. У нас появилась гипотеза, что разработку можно вести кроссплатформенно силами одной команды. Благодаря этому снижается стоимость и растёт скорость разработки.
Эта архитектура получила название single-core. Она предполагает создание единой кодовой базы для всех платформ и единого функционала, который можно моментально масштабировать на все форматы приложений. Например, если банк делает доработку для мобильного приложения, она автоматически появляется в веб-версии.
На каком языке должно быть написано ПО, чтобы программисты не разбежались в ужасе
Чтобы банк мог быстро сформировать команду разработки, ему лучше выбирать ПО, которое написано на популярных, а не «хипстерских» языках программирования. Это облегчает поиск и найм специалистов, особенно в регионах.
Критерии выбора языка программирования
Мы выделили важные параметры для создания именно фронтенда:
Таким критериям соответствуют два языка — JavaScript и TypeScript. На основе этих языков созданы библиотеки готовых компонентов — React для JavaScript и Angular для TypeScript.
Особенности React и Angular:
- Можно разрабатывать приложения для веба и мобильных устройств.
- Большой размер комьюнити (git/stackoverflow)
- Легко найти специалиста на рынке труда.
- Высокое быстродействие / скорость рендера.
- Поддерживают компоненты, благодаря которым можно дробить проект на маленькие куски.
Таким критериям соответствуют два языка — JavaScript и TypeScript. На основе этих языков созданы библиотеки готовых компонентов — React для JavaScript и Angular для TypeScript.
Особенности React и Angular:
- Можно дробить проект на маленькие куски
- Единая кодовая база для мобильных устройств, десктопа и других платформ
- Богатый арсенал инструментов
Почему для инхауса не очень подходит Flutter
В 2017 году появился Flutter — современное и красивое решение, которое включает в себя фреймворк, написанный на языке Dart, и набор инструментов для кроссплатформенной разработки. Flutter отличается высокой скоростью программирования — он позволяет писать в несколько раз меньше кода, чем на JavaScript или TypeScript, и тем самым упрощает создание приложений.
На Flutter можно разрабатывать банковские приложения, однако его использование в проекте может сильно разочаровать банки, которые пытаются построить свою инхаус-лабораторию. На рынке до сих пор мало программистов, пишущих на Dart — он не входит в первую десятку наиболее востребованных языков, и найти разработчиков будет тяжело. Во-вторых, возможность разработки для веба на Flutter появилась только в марте 2021 года. Поэтому банки, готовые работать с этим инструментом, внутри своего рынка могут оказаться первопроходцами и решать проблемы, с которыми мало кто сталкивался.
На Flutter можно разрабатывать банковские приложения, однако его использование в проекте может сильно разочаровать банки, которые пытаются построить свою инхаус-лабораторию. На рынке до сих пор мало программистов, пишущих на Dart — он не входит в первую десятку наиболее востребованных языков, и найти разработчиков будет тяжело. Во-вторых, возможность разработки для веба на Flutter появилась только в марте 2021 года. Поэтому банки, готовые работать с этим инструментом, внутри своего рынка могут оказаться первопроходцами и решать проблемы, с которыми мало кто сталкивался.
Какие технологии использует Abanking
Решение Abanking написано на языке TypeScript и использует библиотеку Angular Framework — они имеют низкий порог вхождения и достаточно распространены, поэтому поиск разработчиков не занял много времени.
Фронтенд: Angular Framework, язык программирования TypeScript.
Бэкенд: платформа ASP.Net Core, язык программирования C#.
Моделирование БД: Dapper ORM.
Управление очередями запросов для выполнения задач в асинхронном режиме: RabbitMQ.
Поддерживаем СУБД: MS SQL, PostgreSQL, MySQL.
Решение Abanking написано на языке TypeScript и использует библиотеку Angular Framework — они имеют низкий порог вхождения и достаточно распространены, поэтому поиск разработчиков не занял много времени.
Фронтенд: Angular Framework, язык программирования TypeScript.
Бэкенд: платформа ASP.Net Core, язык программирования C#.
Моделирование БД: Dapper ORM.
Управление очередями запросов для выполнения задач в асинхронном режиме: RabbitMQ.
Поддерживаем СУБД: MS SQL, PostgreSQL, MySQL.
Как ещё вендор может помочь банку в создании инхаус-лаборатории
Если у банка нет опыта в построении цифровой лаборатории, вендор может помочь банку создать команду и обучить работе с решением. Для этого недостаточно передать документацию по проекту — скорее всего, банку будет сложно даже сформулировать набор нужных компетенций и провести отбор специалистов.
Что может предложить банку вендор:
Что может предложить банку вендор:
- Поиск специалистов. На этом этапе вендор может взять на себя поиск людей и собеседования для проверки их квалификации.
- Обучение разработчиков. Это поможет новой команде получить достаточно знаний и станет основой для развития в банке собственного центра компетенций. Правильно организованное обучение включает теорию и тестовые задачи с проверкой.
- Проведение код-ревью. Если вендор будет проверять код новых сотрудников, впоследствии это поможет банку избежать ошибок, уязвимостей и другие недочётов в приложении.
Чек-лист: выбираем решение, которое можно быстро дорабатывать внутри банка
Мы собрали небольшой список рекомендаций, как выбрать современное гибкое и красивое решение, которое не требует огромного штата разработчиков:
Банкам, которым нужно современное, красивое и гибкое решение, подойдет продукт Abanking — он позволяет создать интернет-банк на уровне цифровых лидеров финтеха и при покупке специализированной лицензии для инхаус-разработки сформировать внутренние IT-компетенции для его развития. А часть процессов вообще можно реализовывать без разработчиков за счёт nocode-технологий. Но это уже совсем другая история.
- Лицензия с частично открытым исходным кодом — позволит выкупить готовое современное решение и быстро включиться в процесс его доработки.
- Single-core архитектура — позволит масштабировать доработки на все платформы моментально.
- Современные языки программирования — позволяютпозволят быстро найти нужное количество разработчиков. Мы рекомендуем: TypeScript, Angular Framework — для фронтенда, C#, ASP.Net Core — для бэкенда.
- Решение упаковано как продукт для сторонней поддержки — это позволит передать банку набор шаблонов и библиотек для быстрого запуска доработок.
- Поддержка и обучение команды банка вендором — позволит банку сформировать собственную техническую компетенцию на начальном этапе.
- Есть кейсы развития продукта без участия вендора — позволит оценить опыт вендора по внедрению решений для инхауса
Банкам, которым нужно современное, красивое и гибкое решение, подойдет продукт Abanking — он позволяет создать интернет-банк на уровне цифровых лидеров финтеха и при покупке специализированной лицензии для инхаус-разработки сформировать внутренние IT-компетенции для его развития. А часть процессов вообще можно реализовывать без разработчиков за счёт nocode-технологий. Но это уже совсем другая история.
