Блог

Создаём инхаус-компетенцию: как банку выбрать ПО для развития собственной разработки

Нельзя один раз внедрить интернет-банк и на этом остановиться — банку обязательно нужны доработки: через полгода изменятся требования регулятора и понадобятся новые сервисы, а через пять лет критично устареет интерфейс.

У банков есть два варианта развития ПО: либо подсесть на контракт с вендором, который будет дорабатывать решение, либо улучшать интернет-банк самостоятельно. Иметь свою лабораторию удобно — это ускоряет процесс улучшений, банк перестаёт зависеть от вендора и ждать своей очереди доработок. Как подойти к формированию внутренней цифровой экспертизы, рассказываем в нашей статье.

Читайте в статье:

1. Зачем банку инхаус-компетенция?

2. Каким путём банки могут развивать свои цифровые каналы

3. Что нужно для создания инхаус-компетенции?

4. Открытый или частично открытый код

5. Выбираем архитектуру решения

6. На каком языке должно быть написано ПО

7. Дополнительные критерии выбора вендора

8. Чек-лист: выбираем оптимальное решение

Зачем банку инхаус-компетенция?

Внутренняя команда разработки, или инхаус-лаборатория, позволяет быстро развивать цифровые каналы — от готовности работать с клиентами онлайн зависит успешность банков на рынке.

По данным исследования консалтинговой компании Bain, которая проанализировала 50 ведущих европейских и ближневосточных банков, банки-цифровизаторы получают три преимущества перед традиционными.
Преимущества цифровых банков
  • Клиенты более лояльны к цифровым банкам. Цифровизация позволяет клиентам быстрее, дешевле и проще получать доступ к продуктам и услугам, и улучшает пользовательский опыт.
  • HR-рейтинг цифровых банков выше — их сотрудники видят карьерные перспективы, больше нацелены на лидерство и вовлечены в работу.
  • Акционеры технологичных банков зарабатывают больше.

Каким путём банки могут развивать свои цифровые каналы

1. Разработать новое решение с нуля

— Долго, дорого, сложно

Этот вариант доступен в основном банкам из топ-10, у которых есть возможность собрать команду разработчиков размером до тысячи человек. Примеры таких команд — Сбертех и Альфалаб, которые выросли из цифрового подразделения в отдельную компанию.

2. Купить готовый современный «коробочный» продукт

— Нужно дорабатывать функционал

Из плюсов — банк получает готовое решение. Из минусов — ни одно коробочное решение не может полностью удовлетворить задачи конкретного банка. Всегда нужны доработки. К тому же рынок очень быстро развивается и продукт должен уметь трансформироваться вместе с ним. Не все вендоры, особенно «бронзовые», могут обеспечить высокую скорость и гибкость. Не имея возможности развивать решение самостоятельно, банк рискует стать «заложником» вендора.

3. Выкупить legacy-код у вендора с намерением доработать

— Устаревший код без преимуществ современных технологий; нет кадров для доработки

Проблема в том что ДБО, которое сейчас находится в эксплуатации, чаще всего написано 10-15 лет назад. Помимо устаревшего кода банк получает проблемы с наймом специалистов. Мало кто на рынке хочет разбираться в непопулярном стеке технологий и монолитной архитектуре. Поэтому банки с legacy-решениями редко создают инхаус-команду для развития исключительно на этой архитектуре и либо развивают ПО только силами вендора, либо, если все таки выкупили код, меняют его кусками очень медленно и дорого, заменяя куски легаси-системы на более современные реализации, если это возможно.

4. Выкупить современное решение и с помощью вендора научиться дорабатывать его самостоятельно

✓ Легко создать инхаус-компетенцию

Это оптимальный вариант для инхаус-разработки, поскольку банк сразу получает готовый функциональную платформу и может быстро начать оптимизировать её: такую систему можно развивать кратно меньшим штатом, чем разработку с нуля. Но на рынке пока мало подходящих вендоров и решений.

Что нужно для создания инхаус-компетенции?

— Бюджет

Сумма, которую банк готов вложить в покупку продуктовой платформы и её адаптацию для своих задач.

— Команда разработки

Это не только программисты, но и менеджеры, аналитики, тестировщики, DevOps.

— Инфраструктура для разработки

Система управления проектами и задачами, система контроля версий, ПО для документации и код-ревью и др.

Открытый или частично открытый код: как не обречь себя на вечные расходы

Даже финтех-гиганты не создают свои продукты с нуля, а выкупают готовые решения у цифровых поставщиков, потому что это помогает существенно оптимизировать производство. В зависимости от возможности доработки, код ПО на банковском рынке делится на несколько типов:

  • Закрытый исходный код
  • Частично открытый исходный код
  • Открытый исходный код

ПО с закрытым исходным кодом

Преимущества

  • Стоимость.

Лицензия на такое ПО стоит дешевле, чем на решения, которые поставляются с открытым кодом.

Недостатки

  • Нельзя дорабатывать самостоятельно.

Развивать продукт можно только через вендора.

ПО с открытым исходным кодом

Преимущества
  • Неограниченные возможности для доработки и переработки кода.

Недостатки

  • Стоимость.

Решения с открытыми исходниками, которые могут быть полностью переработаны, стоят в разы дороже, чем готовое «коробочное» ПО с закрытым ядром.

  • Устаревший код.

Приложение приходится переписывать, чтобы оно было востребовано на рынке. В итоге возникает форк — ответвление от основного продукта, развиваемое и сопровождаемое исключительно в банке. Это приводит к потере совместимости с основной версией продукта от вендора и риску потери компетенции в банке.

  • Кадры.

Сложно найти квалифицированных разработчиков, которые могут развивать решение, не ломая его.

  • Дополнительные расходы.

Если банк не может развивать решение самостоятельно, ему приходится покупать другое или обращаться к вендору за доработками.

ПО с частично открытым исходным кодом

Преимущества
  • Стоимость.

Решения с закрытым ядром стоят меньше, чем с полностью открытым кодом.

  • Легко развивать.

Дорабатывать решение можно силами команды разработки из 2-10 человек.

Недостатки

  • Не всё можно поменять.

Некоторые возможности для доработки кода ограничены лицензией.
Приложения с открытым и закрытым кодом дорого развивать по разным причинам. Решения, которые созданы с закрытым ядром и возможностью кастомизации, остаются самым гибким вариантом для доработок. Далее вы узнаете, как на скорость и стоимость разработки влияют архитектурные особенности ПО.

Выбираем архитектуру решения: разрабатывать быстро или основательно?

Архитектура банковских решений определяет, как разрабатываются и взаимодействуют между собой отдельные компоненты ПО. Прежде чем выбрать архитектуру, банк должен определиться, какую часть решения он хочет дорабатывать — клиентскую (фронтэнд) или серверную (бэкенд). Как правило, банк покупает бэкенд один раз и редко его меняет, поскольку программная часть устаревает в разы медленнее, чем интерфейс. Поэтому срок разработки новых продуктов зависит в основном от особенностей фронтенда.

Архитектура фронтенда в самом широком понимании делится на нативные и кроссплатформенные решения.

Нативная разработка

Нативными называют программы, которые работают только на одной платформе: в вебе, на iOS или Android. Это самый распространённый вид разработки на рынке.

Преимущества

  • Высокая скорость и производительность.

Нативные приложения имеют более низкое время отклика, низкую вероятность сбоев и зависаний.

  • Больше возможностей для интеграции с платформой, для которой они разработаны, по сравнению с кроссплатформенными решениями.

Недостатки

  • Сроки создания приложения

На написание программного кода для двух платформ уходит в полтора-два раза больше времени, чем для одной платформы, поскольку инженерам нужно написать две базы кода.

  • Стоимость разработки выше

Для каждой платформы нужна отдельная команда разработчиков.

  • В случае попадания банка в SDN-лист все нативные iOS-разработчики и их разработки становятся невостребованными.

Single-core

Single-core архитектура позволяет разрабатывать функционал на единой кодовой базе и моментально переносить его на все платформы. Это даёт возможность дорабатывать ПО руками одной команды и сократить time-to-market до минимальных значений.

Преимущества

  • Единая база кода для всех платформ

Благодаря этому команда разработчиков может использовать один технологический стек для всех платформ и максимально приближенные друг к другу мобильный адаптив (PWA) и мобильные приложения.

  • Сокращение времени и стоимости разработки

Single-core позволяет ускорить начальное развертывание приложения сразу на нескольких платформах, сократить время и сложность апдейтов.

  • Одинаковый интерфейс приложений

Это позволяет реализовать «бесшовный» переход с одной платформы на другую, например, со смартфона на ноутбук.

Недостатки

  • Меньшая гибкость.

Унифицированный стек технологий не позволяет подстраивать функционал приложения под особенности каждой платформы.

  • Ниже отзывчивость приложения.

Это ограничение обычно не влияет на работу банковских сервисов.

Что выбрать для инхауса?

Поскольку скорость и бюджет разработки в приоритете, то банкам предпочтительнее выбирать решение, построенное на single-core архитектуре или хотя бы мобильной кроссплатформенности. Это позволит сократить стоимость разработки и time-to-market в 1,5-2 раза.

Нативная разработка vs Single-core: сравним трудозатраты

Мы первыми на рынке финансовых продуктов в РФ реализовали идею single-core архитектуры в готовом продукте в 2018 году.

Abanking разработал для одного из клиентов два мобильных приложения, веб-приложение и веб-адаптив. При нативной разработке потребовалось бы 4 команды — две для мобильных приложений и две — для интернет-банка, чтобы разработать фронтенд и бэкенд. У нас появилась гипотеза, что разработку можно вести кроссплатформенно силами одной команды. Благодаря этому снижается стоимость и растёт скорость разработки.

Эта архитектура получила название single-core. Она предполагает создание единой кодовой базы для всех платформ и единого функционала, который можно моментально масштабировать на все форматы приложений. Например, если банк делает доработку для мобильного приложения, она автоматически появляется в веб-версии.

На каком языке должно быть написано ПО, чтобы программисты не разбежались в ужасе

Чтобы банк мог быстро сформировать команду разработки, ему лучше выбирать ПО, которое написано на популярных, а не «хипстерских» языках программирования. Это облегчает поиск и найм специалистов, особенно в регионах.

Критерии выбора языка программирования

Мы выделили важные параметры для создания именно фронтенда:

  1. Можно разрабатывать приложения для веба и мобильных устройств.
  2. Большой размер комьюнити (git/stackoverflow)
  3. Легко найти специалиста на рынке труда.
  4. Высокое быстродействие / скорость рендера.
  5. Поддерживают компоненты, благодаря которым можно дробить проект на маленькие куски.

Таким критериям соответствуют два языка — JavaScript и TypeScript. На основе этих языков созданы библиотеки готовых компонентов — React для JavaScript и Angular для TypeScript.

Особенности React и Angular:

  1. Можно дробить проект на маленькие куски
  2. Единая кодовая база для мобильных устройств, десктопа и других платформ
  3. Богатый арсенал инструментов

Почему для инхауса не очень подходит Flutter

В 2017 году появился Flutter — современное и красивое решение, которое включает в себя фреймворк, написанный на языке Dart, и набор инструментов для кроссплатформенной разработки. Flutter отличается высокой скоростью программирования — он позволяет писать в несколько раз меньше кода, чем на JavaScript или TypeScript, и тем самым упрощает создание приложений.

На Flutter можно разрабатывать банковские приложения, однако его использование в проекте может сильно разочаровать банки, которые пытаются построить свою инхаус-лабораторию. На рынке до сих пор мало программистов, пишущих на Dart — он не входит в первую десятку наиболее востребованных языков, и найти разработчиков будет тяжело. Во-вторых, возможность разработки для веба на Flutter появилась только в марте 2021 года. Поэтому банки, готовые работать с этим инструментом, внутри своего рынка могут оказаться первопроходцами и решать проблемы, с которыми мало кто сталкивался.
Какие технологии использует Abanking

Решение Abanking написано на языке TypeScript и использует библиотеку Angular Framework — они имеют низкий порог вхождения и достаточно распространены, поэтому поиск разработчиков не занял много времени.

Фронтенд: Angular Framework, язык программирования TypeScript.

Бэкенд: платформа ASP.Net Core, язык программирования C#.

Моделирование БД: Dapper ORM.

Управление очередями запросов для выполнения задач в асинхронном режиме: RabbitMQ.

Поддерживаем СУБД: MS SQL, PostgreSQL, MySQL.

Как ещё вендор может помочь банку в создании инхаус-лаборатории

Если у банка нет опыта в построении цифровой лаборатории, вендор может помочь банку создать команду и обучить работе с решением. Для этого недостаточно передать документацию по проекту — скорее всего, банку будет сложно даже сформулировать набор нужных компетенций и провести отбор специалистов.

Что может предложить банку вендор:

  • Поиск специалистов. На этом этапе вендор может взять на себя поиск людей и собеседования для проверки их квалификации.
  • Обучение разработчиков. Это поможет новой команде получить достаточно знаний и станет основой для развития в банке собственного центра компетенций. Правильно организованное обучение включает теорию и тестовые задачи с проверкой.
  • Проведение код-ревью. Если вендор будет проверять код новых сотрудников, впоследствии это поможет банку избежать ошибок, уязвимостей и другие недочётов в приложении.

Чек-лист: выбираем решение, которое можно быстро дорабатывать внутри банка

Мы собрали небольшой список рекомендаций, как выбрать современное гибкое и красивое решение, которое не требует огромного штата разработчиков:

  1. Лицензия с частично открытым исходным кодом — позволит выкупить готовое современное решение и быстро включиться в процесс его доработки.
  2. Single-core архитектура — позволит масштабировать доработки на все платформы моментально.
  3. Современные языки программирования — позволяютпозволят быстро найти нужное количество разработчиков. Мы рекомендуем: TypeScript, Angular Framework — для фронтенда, C#, ASP.Net Core — для бэкенда.
  4. Решение упаковано как продукт для сторонней поддержки — это позволит передать банку набор шаблонов и библиотек для быстрого запуска доработок.
  5. Поддержка и обучение команды банка вендором — позволит банку сформировать собственную техническую компетенцию на начальном этапе.
  6. Есть кейсы развития продукта без участия вендора — позволит оценить опыт вендора по внедрению решений для инхауса

Банкам, которым нужно современное, красивое и гибкое решение, подойдет продукт Abanking — он позволяет создать интернет-банк на уровне цифровых лидеров финтеха и при покупке специализированной лицензии для инхаус-разработки сформировать внутренние IT-компетенции для его развития. А часть процессов вообще можно реализовывать без разработчиков за счёт nocode-технологий. Но это уже совсем другая история.
Блог