Спасибо за интересную дискуссию.
OGG — это Oracle Golden Gate? Довольно дорогая штука, надо признаться. И он тоже может по какой-то причине сломаться и не обновлять данные в кеше, при этом на системе-источнике данные вполне успешно будут писаться. Да и задержка в 3-4 секунды, на мой взгляд — недопустима, мошенники не дремлют.
in memory data grid с заполнением данных на основе CDC (Change Data Capture, к которым в том числе относится и Golden Gate) — отличная штука для кеша в каналах интернет-банка (отображение балансов). Это решение не нагружает системы авторизационного контура, задержка даже в 20 секунд с обновлением там ОК, а в редких случаях падения CDC финансовых последствий не будет. Это был наш планБ на случай, если NI не потянет запрос баланса для интернет-банков в реальном времени. Но нагрузочные тесты и плавный запуск в промышленной среде показали, что с производительностью и нагрузкой проблем нет, так что этот план не понадобился.
Описанное решение работает в промышленной среде на всех клиентов уже несколько лет, и проблем не доставляет. Благодаря простой и надежной архитектуре в нем крайне мало сбоев, и случаев ошибок с расчетом балансов я не припоминаю. Повторюсь, тонкое место в этом решении — производительность, но с ней пока все очень хорошо. Количество вызовов NI API постоянно растет (новые продукты, рост числа транзакций), деградации производительности не наблюдаем.
Зачем делать новый бэк в данном случае? Почему все таки не процессинг будет мастером по остатку?
Бывают счета без карт. И таких счетов достаточно много. Если остатки хранить в процессинге, то придется либо во всех системах делать две логики и выбор между ними (есть карты/нет карт), либо сгружать в процессинг данные даже по тем счетам, где карт нет. Первый вариант плох тем, что придется переделывать все системы банка, работающие со счетами. И этот вариант не понятно как будет работать, когда к счету карты долгое время не было, и тут ее открыли. Второй вариант плох тем, что на процессинг вырастет нагрузка, а также плата за лицензии (они зависят от числа карт, счетов и т.д. в системе). Также не понятно, как быть с процессинговыми лимитами. Например, у нас есть лимит на сумму одной операции, это глобальное ограничение по рискам. Этот лимит достаточно велик для карточных операций, но для счетовых он слишком мал, ведь клиенты могут переводить десятки/сотни миллионов рублей.
Почему не поднимать данные из других бэков через какой нибудь кэшовый слой?
Потому что любой кеш — это задержки. И даже если задержки сделать минимальными, этот подход имеет риск в случае сбоя системы, наполняющей кеш. Допустим, деньги из кассы выданы, но по какой-то причине кассовая система не выложила эту информацию в кеш. В итоге имеем неверный баланс счета.
Зачем в этот же новый бэк запихивать комиссии? Логичней имхо или в единый каталог продуктовый их запихивать, или вести в ИС, которая мастер по договору клиента (если тарифы предполагают индивидуальность).
Согласен, логично все комиссии собирать в единое место, там же вести тарифные планы и исключения из них. И у нас такая система есть. Вся сложность в Online 24x7. Довольно небольшой перечень систем по-настоящему могут работать в таком режиме и имеют адекватную поддержку. Наша комиссионная система так не умеет, и затраты на ее доработку в тот момент казались нерациональными. Возможно, в будущем мы это реализуем.
Обычно в банке бизнес-продукт реализуется в нескольких приложениях. Те же депозиты — это фронт, интернет-банк, бек офис. Разработчики и аналитики продуктовой команды способны одинаково эффективно делать доработки во всех системах, реализующих продукт? Специализация по приложениям/технологиями не мешает этому?
Составы команд варьируются в зависимости от потребностей создаваемого продукта, но практически всегда это “полный стек”, необходимый для доработки или разработки продукта.
Уточните, пожалуйста, что понимается под понятием «продукт» — это ИТ-приложение (система) или бизнес-продукт (депозит, карта и т.д.)?
Совершенно верно, это время выбрано из-за продолжительности закрытия дня в АБС. Только оно у нас, к сожалению, занимает более двух часов. Время выбрано с таким расчетом, чтобы АБС успела открыться к началу рабочего дня наших восточных филиалов.
Хороший пример. Взносы всегда выжны для клиентов, так как часто они делаются под платеж по кредиту. Поэтому мы делаем проводки по счетам по взносам (либо Cash-In в наш банкомат, либо входящий перевод с чужих карт) в момент авторизации.
Но в любом случае приходится подводить черту между «сегодня» и «завтра». Допустим, у вас сегодня дата планового платежа по потребительскому кредиту в нашем банке. А Вы находитесь в США, и в 19 часов вечера местного времени отправили перевод с американской карты на карту в нашем банке. У вас «сегодня», а у нас «завтра», поэтому мы засчитаем просрочку по платежу в 1 день.
В нашем банке по дебетовым картам черта между «сегодня» и «завтра» проходит в районе 22 часов вечера по Москве.
Вопрос в том, что Вы понимаете под термином «учетные движения». Если это бухгалтерсике проводки, то мы не делаем все проводки при авторизации. Покупки в торговых точках мы холдим на счетах клиента при авторизации, проводки формируем при клиринге. Это связано с тем, что суммы при авторизации и клиринге по таким операциям могут расходиться очень сильно. По переводам с карты на карту дисциплина крайне высокая, там можно полностью доверять сумме при авторизации, а значит можно делать проводку.
Зависит от того, что будет уметь новая АБС. Если в ней будут возможности работы Online 24x7, удобный API по балансам/проводкам/холдам, рассылка событий о движениях по счетам, штатный и гибкий модуль для интеграции с процессингом, то NI отправится на свалку истории.
Гипотетическая миграция на новую АБС будет постепенной, некоторый счета из старой будут мигрированы в новую. На этапе параллельной эксплуатации обеих АБС NI сослужит добрую службу, обеспечив для всех внешних систем прозрачность расчета баланса и создания проводок.
В нашем случае АБС, к сожалению, довольно инертая система в плане развития. Эта интертность вытекает из нескольких источников: устаревшая архитектура самой АБС, достаточно высокий ценник на доработки, сильная связанность с АБС других систем банка. Последний момент означает, что любые изменения в АБС зачастую требуют доработок во многих системах из окружения, как транзакционных, так и отчетных. Этот пункт нас весьма раздражает и в данный момент обсуждаются идеи, как уйти от этой сильной зависимости.
АБС развивается, в первую очередь по тем продуктам, которые «живут» внутри АСБ, то есть по которым проводки формирует сама АБС, а не внешние системы.
Спасибо за Вашу внимательность! Клиенту при авторизации дали на 10,15 рублей РФ больше, чем дали бы при клиринге. Значит, банк потерял, а клиент в выигрыше. В этом участке статьи есть еще одна неточность — банк Евро не продал клиенту, а купил у него. Будем инвертировать логику в статье.
Прошу прощения, банковская профдеформация. АБС — это автоматизированная банковская система, ядро банка, центральная система, где живут остатки, проводки, считаются проценты, предоставляются данные для отчетности и делается много другой работы.
Мы как раз использовали реализацию от Импэксбанка на стороне процессинга, и это нам сэкономило довольно много времени. Коллеги, которые в прошлом делали интеграцию процессинга и АБС Импэкса, серьезно помогли нам с подготовкой ТЗ для модуля NI по работе с ISO-8583 сообщениями. Если говорить про саму АБС, то решение Импекса не подходило по целому ряду критичных показателей, в серьез не рассматривали замену АБС.
Отвечая на Ваш вопрос буквально — никакие. В данном проекте не требовалось объяснять бизнесу выбор того или иного варианта технической реализации проекта. Инициатива исходила от ИТ и операционных подразделений, а бизнес на первых порах не проявлял вовлечения в проекте.
В сущности, при реализации любой задачи в ИТ встает вопрос делать VS покупать. Мы всегда прорабатываем возможные варианты с различных аспектов — наличие готовых решений на рынке, стоимость внедрения и владения, гибкость и возможность дальнейшего развития… Перечень достаточно большой и часто формируется под конкретную задачу. А когда все оценено и сведено в таблицу, обычно решение о выборе варианта становится очевидным, даже для бизнеса.
В данном проекте, если рассматривать вариант интеграции существующего процессинга и АБС с помощью сторонней «коробки», предложения на рынке нет. Мы первые и, насколько мне известно — единственные, кто в принципе к данной линейке АБС в режиме Online 24x7 подключил хоть что-нибудь. Поставщик АБС был очень удивлен, узнав что у нас это получилось.
OGG — это Oracle Golden Gate? Довольно дорогая штука, надо признаться. И он тоже может по какой-то причине сломаться и не обновлять данные в кеше, при этом на системе-источнике данные вполне успешно будут писаться. Да и задержка в 3-4 секунды, на мой взгляд — недопустима, мошенники не дремлют.
in memory data grid с заполнением данных на основе CDC (Change Data Capture, к которым в том числе относится и Golden Gate) — отличная штука для кеша в каналах интернет-банка (отображение балансов). Это решение не нагружает системы авторизационного контура, задержка даже в 20 секунд с обновлением там ОК, а в редких случаях падения CDC финансовых последствий не будет. Это был наш планБ на случай, если NI не потянет запрос баланса для интернет-банков в реальном времени. Но нагрузочные тесты и плавный запуск в промышленной среде показали, что с производительностью и нагрузкой проблем нет, так что этот план не понадобился.
Описанное решение работает в промышленной среде на всех клиентов уже несколько лет, и проблем не доставляет. Благодаря простой и надежной архитектуре в нем крайне мало сбоев, и случаев ошибок с расчетом балансов я не припоминаю. Повторюсь, тонкое место в этом решении — производительность, но с ней пока все очень хорошо. Количество вызовов NI API постоянно растет (новые продукты, рост числа транзакций), деградации производительности не наблюдаем.
Бывают счета без карт. И таких счетов достаточно много. Если остатки хранить в процессинге, то придется либо во всех системах делать две логики и выбор между ними (есть карты/нет карт), либо сгружать в процессинг данные даже по тем счетам, где карт нет. Первый вариант плох тем, что придется переделывать все системы банка, работающие со счетами. И этот вариант не понятно как будет работать, когда к счету карты долгое время не было, и тут ее открыли. Второй вариант плох тем, что на процессинг вырастет нагрузка, а также плата за лицензии (они зависят от числа карт, счетов и т.д. в системе). Также не понятно, как быть с процессинговыми лимитами. Например, у нас есть лимит на сумму одной операции, это глобальное ограничение по рискам. Этот лимит достаточно велик для карточных операций, но для счетовых он слишком мал, ведь клиенты могут переводить десятки/сотни миллионов рублей.
Потому что любой кеш — это задержки. И даже если задержки сделать минимальными, этот подход имеет риск в случае сбоя системы, наполняющей кеш. Допустим, деньги из кассы выданы, но по какой-то причине кассовая система не выложила эту информацию в кеш. В итоге имеем неверный баланс счета.
Согласен, логично все комиссии собирать в единое место, там же вести тарифные планы и исключения из них. И у нас такая система есть. Вся сложность в Online 24x7. Довольно небольшой перечень систем по-настоящему могут работать в таком режиме и имеют адекватную поддержку. Наша комиссионная система так не умеет, и затраты на ее доработку в тот момент казались нерациональными. Возможно, в будущем мы это реализуем.
Ну и интернет-банк и бек-офис — неужели это и правда одно приложение?
Уточните, пожалуйста, что понимается под понятием «продукт» — это ИТ-приложение (система) или бизнес-продукт (депозит, карта и т.д.)?
Но в любом случае приходится подводить черту между «сегодня» и «завтра». Допустим, у вас сегодня дата планового платежа по потребительскому кредиту в нашем банке. А Вы находитесь в США, и в 19 часов вечера местного времени отправили перевод с американской карты на карту в нашем банке. У вас «сегодня», а у нас «завтра», поэтому мы засчитаем просрочку по платежу в 1 день.
В нашем банке по дебетовым картам черта между «сегодня» и «завтра» проходит в районе 22 часов вечера по Москве.
Гипотетическая миграция на новую АБС будет постепенной, некоторый счета из старой будут мигрированы в новую. На этапе параллельной эксплуатации обеих АБС NI сослужит добрую службу, обеспечив для всех внешних систем прозрачность расчета баланса и создания проводок.
АБС развивается, в первую очередь по тем продуктам, которые «живут» внутри АСБ, то есть по которым проводки формирует сама АБС, а не внешние системы.
Мы как раз использовали реализацию от Импэксбанка на стороне процессинга, и это нам сэкономило довольно много времени. Коллеги, которые в прошлом делали интеграцию процессинга и АБС Импэкса, серьезно помогли нам с подготовкой ТЗ для модуля NI по работе с ISO-8583 сообщениями. Если говорить про саму АБС, то решение Импекса не подходило по целому ряду критичных показателей, в серьез не рассматривали замену АБС.
В сущности, при реализации любой задачи в ИТ встает вопрос делать VS покупать. Мы всегда прорабатываем возможные варианты с различных аспектов — наличие готовых решений на рынке, стоимость внедрения и владения, гибкость и возможность дальнейшего развития… Перечень достаточно большой и часто формируется под конкретную задачу. А когда все оценено и сведено в таблицу, обычно решение о выборе варианта становится очевидным, даже для бизнеса.
В данном проекте, если рассматривать вариант интеграции существующего процессинга и АБС с помощью сторонней «коробки», предложения на рынке нет. Мы первые и, насколько мне известно — единственные, кто в принципе к данной линейке АБС в режиме Online 24x7 подключил хоть что-нибудь. Поставщик АБС был очень удивлен, узнав что у нас это получилось.