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