— Михаил, какие преимущества были получены при переходе клиентов на AXIOM JDK? Удалось ли достичь полной совместимости с отечественными ОС?

— Наша компания в новой версии своей АБС для клиентской части использует продукт AXIOM JDK, который входит в единый реестр российского ПО и поддерживает различные системные конфигурации. Взаимодействие АБС с операционными системами производится именно через данное решение. Напрямую код АБС не взаимодействует с ОС. AXIOM JDK самостоятельно сертифицируется на операционных средах, а ЦАБС «БАНК 21 ВЕК» полностью наследует его характеристики.

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

Михаил Песин, руководитель управления новых технологий компании «Инверсия»

— Можно ли утверждать, что СУБД Postgres PRO стала идеальной отечественной базой данных? Не приходится ли что-то в ней дописывать?

— В качестве примера можно рассмотреть нашу АБС, которая реализуется в датацентричном архитектурном подходе, и база данных является ее ключевым элементом. В задачи СУБД входят не только хранение данных и доступ к ним, но и обеспечение среды выполнения алгоритмов обработки данных в рамках задач бизнес-логики. Зарубежные промышленные базы данных соответствуют такому подходу и отлично справляются с высоконагруженными задачами.

Когда пришло время выбора отечественной СУБД, ключевым фактором принятия решения были сроки переноса функционала. Они же не позволяли изменять архитектуру АБС. Надо понимать, что наша АБС является результатом работ, которые длятся более двадцати лет с привлечением свыше ста программистов: совокупно — это сотни тысяч дней работ. Поэтому только процесс миграции функционала «как есть» — это уже отдельная колоссальная задача.

Таким образом, выбора у нас особо не было: пожалуй, единственной отечественной СУБД, которая позволяет осуществлять перенос функционала без изменения архитектуры, в нашем случае является Postgres PRO Enterprise.

Однако не будем утверждать, что все происходит гладко. «Под капотом» СУБД устроены по-разному. Например, есть различия в организации механизма мультиверсионности (MVCC), что в конечном счете требует изменения кода бизнес-логики. Тот код, который хорошо работает с СУБД Oracle, с Postgres PRO Enterprise может обернуться проблемами производительности всей системы. Но это не означает, что мы не сможем получить нужную функциональность: просто код приложений надо адаптировать под другую СУБД и под ее особенности.

Хочу отметить, что часть привычного функционала, предоставляемого Oracle, в PG PRO отсутствует или работает иначе. Но надо отдать должное разработчикам отечественной СУБД: постоянно выходят новые версии и патчи к ним, где добавляются те или иные недостающие функциональные возможности. Также имеется возможность самостоятельно реализовывать библиотечные функции и операторы. В ряде случаев мы пользуемся такими возможностями и решаем часть проблем, в том числе и данным способом.

— Какие новые тренды учитываются при разработке АБС? Становится ли она платформой или core-less решением? Каково ваше отношение к композитной архитектуре?

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

АБС в первую очередь — это система автоматизации, которая служит бизнесу, его требованиям и ограничениям. Кроме того, вендорская АБС — это тиражируемое решение, хотя не всем заказчикам подходит один конкретный вид архитектуры и реализации функционала. Изначально в нашей АБС были заложены возможности обеспечения высокой гибкости, и до сих пор эта особенность позволяет иметь единую тиражируемую систему, способную адаптироваться под каждого клиента со своими особенностями. Однако с ростом объемов и нагрузки, а также с обострением необходимости в быстрой реализации доработок начинают проявляться недостатки монолитной архитектуры. Крупные банки видят АБС в качестве микросервисного core-less решения: необходимо «переваривать» огромные объемы данных, иметь возможность горизонтально масштабировать нагрузку и встраиваться в собственную инфраструктуру банка с множеством других микросервисов.

Для малых и средних банков монолитная АБС является великолепным выбором. Она дешевле при внедрении, дешевле в сопровождении, проще в обслуживании и прекрасно справляется со своими задачами.

Сама АБС как тиражируемое решение не становится платформой — у крупных банков настолько специфичные и исторически сложившиеся наборы систем и продуктов, что АБС становится лишь частью этой огромной системы: большой частью, но не всеобъемлющей.

Компания «Инверсия» понимает эти тренды и параллельно с монолитной ЦАБС «БАНК 21 ВЕК» ведет разработку микросервисной АБС для крупных банков.

— Параллельная разработка одного и того же функционала на разных стеках сейчас не редкость. Для чего это делается и каковы основные сложности?

— Микросервисные АБС в разных банках могут различаться. Например, у некоторых банков есть готовые компетенции по работе и обслуживанию одних NoSQL СУБД и отсутствуют компетенции по другим. Даже для кеширования, например, в одном банке используется Redis, а в другом — Apache Ignite. Также для разных задач у банков могут быть существенно различные требования по быстродействию. Как следствие приходится рассматривать разнообразные инструменты для решения тех или иных задач. То есть стек технологий даже для тиражируемой микросервисной АБС может меняться вследствие кастомизации.

Но не всем нужны микросервисы. В первую очередь микросервисная архитектура — дорога, порой избыточна и весьма сложна в обслуживании и сопровождении. Тут можно провести аналогию с большим карьерным самосвалом — отличная машина для своих задач, но на дорогах общего пользования неразумно использовать его в качестве обычного грузовика. Для малых и средних банков монолитная АБС является великолепным выбором. Она дешевле при внедрении, дешевле в сопровождении, проще в обслуживании и прекрасно справляется со своими задачами.

Конечно, параллельная разработка несет издержки для компании-разработчика: нужно больше аналитиков, больше программистов, больше тестировщиков и консультантов сопровождения. И кадры далеко не всегда могут быть взаимозаменяемыми для разных систем на одних и тех же позициях. Также сложность вызывает выстраивание процессов разбора инцидентов, происходящих на системах с кастомизированными программными средствами: чем разнообразнее выбор программных средств, тем больше количество возможных точек отказа.

— Прижился ли в «Инверсии» подход улучшения качества решений по результатам обратной связи? Как это происходит? Как решается, что хорошо или плохо?

— Разработчики банковских систем напрямую заинтересованы в качестве своего продукта — это снижает многие негативные риски: как свои, так и клиентские. Компания «Инверсия» постоянно совершенствует процессы обеспечения качества своих решений. Сбор обратной связи — один из используемых подходов. Более того, он положительно влияет даже на решение более глобальных вопросов.

Имеется несколько вариантов реализации подхода. Самый частый — это общение с пользователями, сотрудниками поддержки и руководителями заказчиков. В первую очередь внимание уделяется различным инцидентам и выявленным дефектам. К разбору подключаются сотрудники всех причастных отделов. Устранением дефекта дело не ограничивается. Ведется ретроспективный анализ причин его возникновения и по результатам вносятся изменения в процессы, охватывающие всю цепочку жизненного цикла разработки: от аналитики и первичной постановки задачи до сопровождения с учетом вариантов адаптации и кастомизации типового решения у клиентов. Во вторую очередь внимание уделяется вопросам, в которых результат автоматизации влияет на доходы клиентов: это, например, вопросы общего быстродействия, вопросы изменений бизнес-логики, позволяющих оптимизировать рабочий процесс или добавить новую функциональность, опросы допустимого времени простоя системы при обновлении. В третью очередь уделяется внимание удобству работы пользователей системы: начиная со всевозможных защит от заведомо ошибочных действий и заканчивая оптимизацией UX. Хотя последняя нередко бывает субъективной и зависит от особенностей конкретного банка.

К другим вариантам реализации подхода относится сбор статистики. Здесь важно уточнить, что он обязательно тщательно согласуется с заказчиками. К собираемой статистике относятся всплески и отклонения операционного быстродействия, скорость взаимодействия пользователей с графическим интерфейсом системы, частота использования тех или иных компонентов системы. На основании этих данных мы можем оценивать частотные проблемы быстродействия, оптимизировать пользовательский путь в интерфейсах системы, а также формировать ранжированные списки используемых компонентов. А далее — выявлять неявные для нас, но критичные для заказчиков участки системы и принимать решение о последовательности переписывания функциональных блоков системы внутри модулей, как это, например, было при переходе на другие фреймворки пользовательского интерфейса или при работах по переходу с СУБД Oracle на Postgres PRO.

Улучшение качества системы позволяет повышать доходы и сокращать издержки заказчиков, что является одним из важнейших приоритетов деятельности нашей компании.