Как снизить стоимость внедрения финансового хранилища данных
Построение в банке хранилища данных требует серьезных инвестиций. Как сэкономить бюджет без ущерба для результатов проекта, рассказала Юлия Амириди, заместитель генерального директора компании Интерсофт Лаб.
Финансовое хранилище данных (ХД) – абсолютный must have для управления современным банком на основе данных. Его главная задача – подготовка единой версии полных и достоверных данных для финансового планирования, прогнозирования, построения управленческой, регуляторной и риск-отчетности.
Драйверами ХД-инициатив сегодня выступают отложенный спрос 2022 года и оптимизация аналитической инфраструктуры в рамках импортозамещения. Банки отдают предпочтение готовым платформам для создания ХД и систем банковской отчетности из Реестра российского ПО.
Как показала практика, внедрение финансового хранилища на базе отечественных технологий – задача сложная, но выполнимая. Часто препятствием для реализации таких проектов становится высокая стоимость оборудования, лицензий и внедрения ПО. Предлагаем несколько проверенных подходов, чтобы сэкономить бюджет без ущерба для результатов проекта.
Прагматизм или амбиции: выбираем архитектуру
Уже целое десятилетие системные интеграторы напористо продвигают архитектуру Data Lake (озеро данных) для создания хранилищ данных в банках. Это все еще модно, масштабно, требует серьезных аппаратных мощностей и дорогостоящих специалистов.
При этом взаимосвязь решаемых прикладных задач и технологических подходов зачастую остается «за бортом» маркетинговой агитации. И это неправильно. Каждой задаче нужна своя технология.
Реализация типичных запросов бизнес-аналитики на базе финансового ХД требует структурированных данных. Поэтому предпочтительным выбором для финансового ХД является DataWarehose – централизованная архитектура для предметно-ориентированного хранения, обработки и анализа данных. Поставщиками данных для финансовых ХД выступают учетные системы банка. При загрузке в ХД первичные данные преобразовываются согласно требованиям банковской модели данных. Структурированные таким образом данные подходят для выпуска банковской отчетности и решения прикладных задач управления эффективностью.
Для антифрода, скоринга, прогнозирования и ряда других задач, наоборот, нужны большие данные из разных, в том числе внешних по отношению к банку, источников во всем их исходном многообразии: структурированные, полуструктурированные и неструктурированные. Для их хранения наиболее уместно использовать технологию Data Lake. А для обработки – методы искусственного интеллекта (Artificial Intelligence, AI), включая машинное обучение (Machine Learning, ML) и другие механизмы работы с большими данными.
Чтобы решать аналитические задачи на любых типах данных, в теории уже несколько лет существует гибридная архитектура LakeHouse. Она задумана, чтобы объединить сильные стороны классических ХД и озер данных. Однако практическая реализация этой концепции все еще упирается в низкую готовность соответствующего инструментария.
Таким образом, для решения разных прикладных задач банкам по-прежнему приходится разворачивать и финансовые ХД на СУБД, оптимизированных для обработки структурированных данных, и озера данных для работы с большими данными. Поручить какой-то одной технологии решать сразу все задачи, пока объективно не получается.
Так что не пытайтесь в угоду моде и амбициям приспособить Data Lake к управленческим задачам и подготовке структурированной отчетности. Потратитесь впустую. Действуйте прагматично: экономьте, выбирая для финансового ХД классическую архитектуру DataWarehose.
Экономия или санкционные риски: принимаем решение о свободном ПО
Последние пару лет мы регулярно слышим тезис о том, что свободное ПО теснит проприетарное. С одной стороны, банки выбирают софт с открытой лицензией. С другой - разработчики интегрируют в свои решения открытые компоненты.
При внедрении финансового ХД заказчик, как минимум, дважды выбирает между свободно-распространяемым ПО (СПО) и коммерческими компонентами решения – определяясь с СУБД и интеграционной платформой. Например, финансовое ХД «Контур» от компании Интерсофт Лаб функционирует на СПО СУБД PostgeSQL и на коммерческой версии Postgres Pro от компании Postgres Professional. Банк может выбрать любую. Традиционные клиентские аргументы в пользу СПО – независимость от вендоров и снижение затрат на лицензии.
Однако, технологии, распространяемые по свободной лицензии, не так уж независимы. Серьезное программное обеспечение невозможно создать на голом энтузиазме. За любым СПО скрыта ассоциация разработчиков, фонд или другая структура, которая управляет лицензией на нее. И это преимущественно заокеанские организации, которые способны «включить» экспортные ограничения не хуже частных правообладателей. Еще не стерся из памяти пример с массово-параллельной реляционной СУБД Greenplum, в один момент утратившей статус СПО с архивированием всех исходников на GitHub’е.
Конечно, назвать такой санкционный риск прямым сложно. Но косвенные санкционные риски использование СПО, безусловно, несет. С этой точки зрения альтернативный коммерческий софт, безусловно, предпочтителен, даже если он опирается на СПО. Потому что у добросовестных правообладателей имеется и исходный код проекта и, главное, экспертиза в работе с ним. Это гарантирует защиту инвестиций конечных пользователей в ХД, даже если реализуется самый негативный риск-сценарий.
Тезис с экономией на свободных лицензиях тоже не бесспорный. Попробуйте сравнить, например совокупную стоимость владения коммерческой редакцией СУБД Postgres Pro Standard и свободно-распространяемой PostgeSQL. Окажется, что разница в стоимости сертификатов технической поддержки уже через несколько лет не оставит следа от мнимого выигрыша в цене поставки СУБД.
Учитывайте это, оценивая выгоды от приобретения компонентов для финансового ХД. Моментальная экономия за счет СПО привлекает, но еще важнее перспектива. Ведь финансовое ХД создается не на один год.
Бессрочная или периодическая лицензия: считаем ТСО
Сегодня поставщики предлагают несколько моделей лицензирования ПО для создания ХД. Наиболее распространены две: традиционные бессрочные лицензии и лицензии по подписке (говоря иначе - периодические лицензии).
У каждой модели есть свои плюсы и минусы. В периодической модели привлекают низкие входные платежи, обновления в рамках подписки, возможность отказаться от оплаты, если банк прекращает использовать софт. Преимущества бессрочной лицензии – единовременная оплата, которой не грозят индексации, и возможность передать лицензию правоопреемнику. Обновления ПО в этом случае обычно предоставляются в рамках договора технической поддержки.
Нельзя сказать заранее, какой вариант окажется выгоднее для конкретного банка. Расчет стоимости лицензий для финансового ХД зависит от многих факторов, включая масштаб банка, состав решаемых на основе хранилищ прикладных задач, количество потенциальных пользователей и проч. Лицензионные метрики разных поставщиков тоже сильно отличаются. Кроме того, у многих есть пакетные предложения и прочие опции для снижения стартовой стоимости ПО.
Выбирая ХД-платформу, обязательно выясните все нюансы лицензирования, а также формирования стоимости технической поддержки, определите потенциальный горизонт использования финансового ХД и посчитайте совокупную стоимость владения (Total cost of ownership, ТСО) ПО. Получите интересные цифры для размышления и экономии.
Заказчик или соисполнитель: распределяем проектные работы
Самое дорогое «удовольствие» в проекте построения финансового ХД – интеграция с учетными системами банка. Основной способ снизить затраты на интеграцию – распределить работы между заказчиком и исполнителем. В зависимости от возможностей и желания заказчика можно выбрать разные варианты совместного участия в разработке интеграционного решения.
Наиболее затратный вариант, когда разработка технологии выгрузки данных из источников банка и их загрузки в ХД полностью делегирована исполнителю проекта. Его главное преимущество в том, исполнитель полностью несет ответственность за результат и сроки выполнения работ.
Определенной экономии можно добиться, передав заказчику подготовку промежуточных представлений (view) из систем-источников. Атрибутный состав витрин должен соответствовать требованиям финансовой модели данных ХД. В зоне ответственности исполнителя останется трансформация и загрузка данных в ХД, а также контроль их качества. Такое распределение задач при хорошем знании заказчиком собственных источников данных может сократить сроки проекта. Минусы этого варианта - размывание ответственности за результат и скрытые расходы банка на подготовку view и их последующее сопровождение.
Если заказчик возьмет на себя полную разработку ETL-процесса и размещение данных в заданных форматах в STG-области ХД, стоимость интеграции существенно снизится. Исполнителю останется загрузить подготовленные данные в ХД, выполнить их проверку и вернуть информацию о выявленных ошибках для их исправления. Чтобы добиться качества данных, потребуется несколько итераций устранения ошибок и перезагрузки. Недостаток такого подхода – существенное увеличение сроков на интеграцию. Кроме того, банк должен располагать квалифицированными ресурсами и в дальнейшем сопровождать разработанные маппинги.
Таким образом, противовесом экономии бюджета на интеграцию выступают косвенные расходы, сроки проекта и ответственность за его результаты. Определяясь с распределением работ между заказчиком и банком, помните, что сэкономить на загрузке данных можно, но получится это не у всех.
Эффективный способ подобрать оптимальный вариант совместного выполнения работ – оценить готовность заказчика участвовать в разработке интеграционного решения в рамках пилотной стадии проекта. Обязательно воспользуйтесь этой возможностью, чтобы протестировать все составляющие своего выбора и своевременно скорректировать границы, сроки и экономику проекта.
