Про велоинфраструктуру лучше молчать. Порежут существующий и без того не сказать чтобы широкий тротуар на вело и пешеходную часть, в итоге плохо будет всем.
Все приходят к этому примерно одним путём. Сотни функциональных модулей, десятки интеграций, многие десятки регуляторных требований в год, сотни мелких требований от бизнеса. Лет за 10 систему не узнать.
Так многих из этих оставшихся 300 банков таки да, окучивают в последний раз. Потом они сольются, сдадут лицензию или пойдут под внешнее управление. И прощайте доходы ИТ вендоров.
Цифровой рубль не имеет никакого отношения к АБС. Интеграции между ними - тонкая ниточка.
Учёт в АБС - не самая важная часть. А продуктовая логика на два десятичных порядка сложнее.
Интеграций даже для мелкого банка десятки, все с нюансами.
Деньги на сопровождение платятся за соответствие требованиям регуляторов в большей степени, и для мелкого молодого вендора это обычно неподъемный труд.
У log4j уязвимость с jndi была только у 2 версии. Слоупоки (очень, очень многие вендоры с тиражируемых софтом) на тот момент использовали 1 версию.
Кстати, один из выводов - нечего гнаться за обновлением зависимостей если это реально не требуется. Отдельный привет передаём ИБ с требованием регулярных и довольно частых обновлений.
Для финтеха написано весьма поверхностно, хотя большинство мыслей логичные.
Приведу несколько пришедших в голову комментариев.
Использование криптографии (особенно нормативной) существенно меняет эффективность обмена сообщениями. Высокие накладные расходы и вероятность ошибки заставляют переходить к асинхронным решениям и пакетному обмену.
Файловый обмен для пакетной обработки всё ещё остаётся весьма удобным транспортом. Механизм архивирования успешно и неуспешно обработанных файлов мало меняется десятилетия, под рукой архив для целей аудита или тестирования. Плюс на не очень хороших каналах сжатый файл – достаточно эффективный метод передачи пакетной информации.
Проблемы с семантикой полей одинаковы для любого протокола. Если не используется жесткое описание и контроль схемы сообщения и документация делается по остаточному принципу (обычное дело даже для финтеха) – проблемы гарантированы независимо от технологии.
Не упомянута одна из важнейших тем – адекватное журналирование. Как самих сообщений, так и сопутствующих состояний и ошибок. Для нагруженного интерфейса логи могут быть огромны, при плохо продуманных логах поиск чего либо затруднён. Часто надо использовать несколько параллельных журналов для различных целей плюс делать интерфейс администратора для поиска необходимой информации в журналах.
Существующие SOAP веб сервисы не поддерживают идемпотентность.
Дока по веб сервисам... эээ... ну она хотя бы есть.
Поддержка по интеграции отвечает очень, очень так себе.
Поддерживаются сервера приложений исторической древности 10-15 летней давности, более новые - на свой стах и риск.
Многих функционально естественных методов нет, но можно разработать за деньги (и не то, чтобы малые). Очевидно, что об удобстве и предсказуемости интеграции никто не думал.
Про велоинфраструктуру лучше молчать. Порежут существующий и без того не сказать чтобы широкий тротуар на вело и пешеходную часть, в итоге плохо будет всем.
Все приходят к этому примерно одним путём. Сотни функциональных модулей, десятки интеграций, многие десятки регуляторных требований в год, сотни мелких требований от бизнеса. Лет за 10 систему не узнать.
Так многих из этих оставшихся 300 банков таки да, окучивают в последний раз. Потом они сольются, сдадут лицензию или пойдут под внешнее управление. И прощайте доходы ИТ вендоров.
Цифровой рубль не имеет никакого отношения к АБС. Интеграции между ними - тонкая ниточка.
Учёт в АБС - не самая важная часть. А продуктовая логика на два десятичных порядка сложнее.
Интеграций даже для мелкого банка десятки, все с нюансами.
Деньги на сопровождение платятся за соответствие требованиям регуляторов в большей степени, и для мелкого молодого вендора это обычно неподъемный труд.
У log4j уязвимость с jndi была только у 2 версии. Слоупоки (очень, очень многие вендоры с тиражируемых софтом) на тот момент использовали 1 версию.
Кстати, один из выводов - нечего гнаться за обновлением зависимостей если это реально не требуется. Отдельный привет передаём ИБ с требованием регулярных и довольно частых обновлений.
Для финтеха написано весьма поверхностно, хотя большинство мыслей логичные.
Приведу несколько пришедших в голову комментариев.
Использование криптографии (особенно нормативной) существенно меняет эффективность обмена сообщениями. Высокие накладные расходы и вероятность ошибки заставляют переходить к асинхронным решениям и пакетному обмену.
Файловый обмен для пакетной обработки всё ещё остаётся весьма удобным транспортом. Механизм архивирования успешно и неуспешно обработанных файлов мало меняется десятилетия, под рукой архив для целей аудита или тестирования. Плюс на не очень хороших каналах сжатый файл – достаточно эффективный метод передачи пакетной информации.
Проблемы с семантикой полей одинаковы для любого протокола. Если не используется жесткое описание и контроль схемы сообщения и документация делается по остаточному принципу (обычное дело даже для финтеха) – проблемы гарантированы независимо от технологии.
Не упомянута одна из важнейших тем – адекватное журналирование. Как самих сообщений, так и сопутствующих состояний и ошибок. Для нагруженного интерфейса логи могут быть огромны, при плохо продуманных логах поиск чего либо затруднён. Часто надо использовать несколько параллельных журналов для различных целей плюс делать интерфейс администратора для поиска необходимой информации в журналах.
Пишите красиво. По факту же немного иное.
Существующие SOAP веб сервисы не поддерживают идемпотентность.
Дока по веб сервисам... эээ... ну она хотя бы есть.
Поддержка по интеграции отвечает очень, очень так себе.
Поддерживаются сервера приложений исторической древности 10-15 летней давности, более новые - на свой стах и риск.
Многих функционально естественных методов нет, но можно разработать за деньги (и не то, чтобы малые). Очевидно, что об удобстве и предсказуемости интеграции никто не думал.