Меня зовут Максим Седов, я корпоративный архитектор. Хочу рассказать о проблемах, с которыми мы (а может быть и вы) сталкиваемся в архитектуре, и подумать, как их можно побороть. Для этого я затрону проблемы, с которыми столкнулась архитектура до 2023 года.

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

Поделюсь практическим применением архитектурных паттернов. И, конечно, не могу обойти стороной тренды — искусственный интеллект и LLM.

Итак, о чём пойдёт речь. 

• Какой была архитектура до 2020 года. 

• Накопленные за годы проблемы.

• Куда бы хотели прийти.

Сначала надо начать с определения. И, помучив DeepSeek, было получено следующее:

Информационная архитектура предприятия — это комплексная структура, которая описывает организацию, взаимосвязи и взаимодействие всех информационных систем, процессов и ресурсов предприятия. 

Архитектура до 2020 года

Какая была и отчасти остается архитектура в Банке:

• Сервис-ориентированной.

• АБС-ориентированной.

• Организационно-ориентированной.

Почему сразу три направления? Архитектура Банка представляет из себя взаимодействие большого количества систем и подходов. При этом изменения очень сильно растянуты во времени. Невозможно перейти на какой-то подход одномоментно, всегда будут оставаться «куски» ландшафта, реализованные на старых технологиях и принципах.

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

Когда клиентов и операций было мало — всё работает прекрасно. Помимо этого, скорость внедрения изменений тогда позволяла нам использовать классическую каскадную модель процесса разработки. Кроме того, конечно, АБС справлялась: она была близка к тем данным, которые требовались процессам. Она быстро их доставляла, обрабатывала, и таким образом появлялись достаточно крупные блоки бизнес-логики.

Организационно-ориентированную архитектуру тоже я не могу обойти. Все мы знаем закон Конвея: 

«Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации».

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

Отсюда вытекают ряд проблем, с которыми мы до сих пор боремся. 

Следствия архитектурных подходов

№1 Неустойчивость фронт-систем при падениях бэка. 

АБС-ориентированная архитектура, доставка данных из бэка приводит и сейчас, и ранее к тому, что её недоступность приводит к недоступности фронт-систем.

№2 Бизнес-логика на стороне ядра системы, где у нас должна быть главная книга, должны быть проводки, но не бизнес-операция.

№3 Дублирование бизнес-логики на стороне фронтов. 

Тоже интересная история, потому что она возникает из-за того, что мы делим технологии по языкам программирования. У нас для этого есть соответствующие команды и они определяют те подходы, по которым они формируют бизнес-логику на своей стороне. Иногда есть противоречия, которые приводят к появлению дублей только из-за того что нет возможности разобраться в коде, написанном на другом языке разработки.

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

Дальше попробую описать наши способы борьбы со сложившимися проблемами.

Что делать?

№1 Переход на микросервисы. Понятно, это было в тренде и остаётся в тренде. Хотя должен сказать, что если взглянуть на наш АБС, то это классная история по построению микросервисов. Если разобрать её до винтиков, это микросервисная архитектура в чистом виде. 

№2 Дальше мы стали перестраивать оркестраторы, добавлять хореографию. Сейчас мы не говорим о том, что лучше, что хуже. За счёт этого началось переиспользование логики, а не дублирование.

№3 Мы начали заливать данные во фронты. Когда в АБС и логика, и данные — это удобно для расчётов, но как только начали выносить бизнес-процессы на слои выше, данные потянулись за ними. Такой подход привёл к появлению дублей данных, а также необходимости контроля их качества. 

№4 Мы начали формировать платформы. Платформы как раз возникают из-за необходимости построить слой с мидл-логикой, который уже будет выполнять бизнес-функции.

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

Если смотреть на предыдущие подходы, то они хорошие. Мы действительно имели возможность очень быстро реализовывать новые процессы, использовать качественные данные, лежащие близко к сервисам. Но и тут от проектного треугольника никуда не деться, и, к сожалению, со временем баланс начал разрушаться, а показатели цены и сроков расти.

То, что у нас сейчас вырисовывается («Стало») вызывает некоторые вопросы и порождает в том числе новые проблемы. 

Новые проблемы

№1 В первую очередь у нас появился «прыгающий мидл». Неожиданно возникла идея такого определения. Что я имею в виду? 

Ситуация, когда у нас бизнес-логика лежала на АБС, позволяет однозначно ответить на вопросы где она и за что отвечает, при этом исключено дублирование. Также не было проблем с тем, где разместить эту логику и выбрать за неё ответственного кто за неё отвечает условно. 

Как только появилась необходимость ее вынести, сразу стали возникать вопросы, а куда ее поселить. Практика показала, что у нас возникает middle-слой на разных уровнях: он может появиться и в канале, появиться непосредственно где-то на middle уровне, а может появиться ещё где-то. 

Он не не закреплён. И кажется, что определение «прыгающий» вполне сюда подходит. 

Да, это перекликается с подходами, которые тоже лет пять назад, наверное, чуть меньше продвигали консалтинговые группы, когда должны возникать так называемые PBC-шки, Package Business Capability, которые формируют и управляют конкретной бизнес-сущностью, и призваны решать одну конкретную задачу.

№2 Усложнение архитектуры. Всё понятно, у нас появляется больше сервисов, больше слоёв, усложняется передача данных между ними. Появляются слои реконсиляции, возникает необходимость в построении Data Governance и т.д. 

№3 Увеличение количества зависимостей, и мы получаем каналы как бэк-системы. Сильно сказывается организационная структура, но факт есть факт: что некоторые функциональности и некоторые продукты начинают жить прямо в канале, и канал по сути становится бэк-системой.

Куда хотим прийти?

Что мы хотим сделать с этим, куда мы хотим прийти? Ключевое — хотим достигнуть надёжности с точки зрения архитектуры. 

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

Прозрачность. У нас должна появиться прозрачность того, как реально построена архитектура организации. Сейчас у нас присутствуют разрывы в процессах. 

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

Автономность. Решение, которое мы должны получить, должно показывать в автономном режиме происходящее в архитектуре. Мы должны иметь триггеры, которые сигнализируют, что возникает что-то противоречащее нашим подходам и утверждённым стандартам.

Таким образом, какие подходы мы хотим сейчас использовать?

Реализация паттернов

Мы должны использовать паттерны для того, чтобы достигать прозрачности архитектуры за счёт использования утверждённых, согласованных, принятых и апробированных шаблонов для её проектирования. Кроме того более жесткое регулирование проектирование архитектуры за счёт стандартов. 

Дальше. Второй важный пункт — это платформизация.

Платформизация

Выше я упомянул что у нас АБС-ориентированная архитектура и логика находится в Core системе. Со стороны это выглядит это как монолит. И сейчас мы всё равно приходим к тому, что у нас должны появляться платформы, которые будут содержать совокупность логики. Может показаться, что это тоже возникновение монолитов. Наверное, это так и есть. 

Но мы должны видеть слои и понимать, какие конкретно системы и направления отвечают за функционал, чтобы не дать ему расползтись по всему банку и дублировать себя.

Архитектурный репозиторий

Отдельная история — архитектурный репозиторий.

В больших организациях всю архитектуру на страницу не уложишь.

В связи с этим появляются разнообразные вариации архитектурных репозиториев. Также произошло и у нас. Мы реализовали свой архитектурный репозиторий. Он несколько лет в продакшене, и в его рамках наш контроль, прозрачность, наша автоматизация, ненавязчивость должны появиться. Мы уже сейчас через него заводим все системы, модули и контролируем их появление. Уже тысячи систем заведены, а если спускаться до сервисов, то объектов более 10 тысяч. 

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

Цель на самом деле простая и очевидная, она на поверхности: хочется, чтобы мы проследили путь появления системы от идеи в голове бизнеса до фактической реализации установки её на сервера. 

Для этого должна быть проделана достаточно большая работа, и мы её делаем. Сейчас этап, который должен появиться и который мучает всех — это автоматизация сетевых схем. Когда уже доступы будут появляться, выдаваться именно по той документации, которая сделана. И развитие — это выход на возможность увидеть фактически установленный сервис на условно-конкретном железе. 

Конечно, хочется добавить туда и новые технологии, которые я упомянул в начале статьи. Это инструменты искусственного интеллекта, но это в перспективе. При этом наша рабочая группа тоже над этим трудится.

Есть положительные результаты, но пока это всё в тестовом режиме. 

В идеале наш архитектурный репозиторий должен иметь возможность показать в более читаемом виде граф архитектуры всего Банка. 

Часто возникают случаи, когда ребята приходят в банки из сфер, не связанных с финтехом и возникает вопрос: «Что мы делаем, как мы выглядим, какие системы есть и что они делают». На этот вопрос сложно ответить, это требует нескольких этапов встреч, рассказов. 

Но мы надеемся, что наш инструмент в конечном итоге позволит оперативно отвечать на такой вопрос, видеть картинку в целом, а для нас и для других подразделений, в том числе безопасности и инфраструктуры, видеть те точки, в которых у нас могут возникать проблемы, противоречащие либо стратегиям, либо подходам, и тогда наше управление архитектурой будет достаточно на высоком уровне

Также подписывайтесь на Телеграм-канал Alfa Digital, где рассказывают о работе в IT и Digital: новости, события, вакансии, полезные советы и мемы.

Читайте другие наши статьи: