Вероятно, те, кто делал платформы повторного использования знает, что часто бывает, когда встречаются потребители общих сервисов, их создатели и архитекторы. Одним нужно быстро, другим дешево, а третьим правильно. Традиционно выберите два из трех? Нет, в этом эпизоде мы узнаем весьма элегантный архитектурный элемент СУБО+. Как можно и быстро, и несложно, и красиво не проиграть в лотерею «2 из 3», а потом еще и переиграть если что-то поменялось.

Еще раз напомню принципы омниканальности: концентрация специфики в СУБО и унификация в ОПС/ОС. То есть, повторное использование в ОПС/ОС, продуктовая специфика в СУБО.

Рис 1. Башенки Омниканального королевстваКликните на картинку, чтобы увеличить изображение — Рис 1. Башенки Омниканального королевства
*Кликните на картинку, чтобы увеличить изображение*

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

Нет функционала повторного использования — СУБО;
Есть функционал повторного использования — СУБО+ОПС.

В этом случае объем унификации (функционал ОПС) и ее перспективы (потребители) учитывались достаточно прямолинейно, выделением ИС типа ОПС. Со всеми дополнительными организационными, и не только, усилиями по вводу новой единицы управления, без приведенной выше серой зоны. Если переиспользуемый функционал сильно востребован и достаточно определен, это вполне оправдано. А если нет?

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

Например,

Есть могучий «бесчеловечный» (без пользовательского интерфейса) процесс обработки клиентской заявки на продукт. Делаем ОПС и все нормально;
И вдруг нужно на каком-то шаге поднять одну формочку, и пользователь должен нажать на кнопку «Согласовано»;
И что создавать новый СУБО, новую систему или новую единицу управления, разрабатывать кучу документации, проходить целый жизненный цикл ради несколько десяткой строчек кода? Выглядит весьма сомнительно.

И наоборот,

Есть могучий «человечный» (с пользовательским интерфейсом) процесс;
И у него появляется пара общих шагов с другим «человечным» процессом. Выделять в ОПС тот же десяток строк? Также сомнительно.

Рис 2. СУБО+ дитя бережливой унификацииКликните на картинку, чтобы увеличить изображение — Рис 2. СУБО+ дитя бережливой унификации
*Кликните на картинку, чтобы увеличить изображение*

Мы поняли, что нам нужна более гибкая, бережливая, архитектура для учета таких пограничных ситуаций, или так называемых серых зон. Мы подумали и перешли от типов систем к типам программных интерфейсов: есть СУБО с их уникальным функционалом и программным интерфейсом (API), и есть ОПС с их функционалом повторного использования с собственным API. И у нас получился новый элемент платформы: объединение двух элементов СУБО и ОПС в одной системе СУБО+. В этой конструкции и СУБО, и ОПС остаются такими, как и были, но исходя из принципов бережливой унификации объединяются в одну систему или единицу управления СУБО+.

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

№	Критерии оценки целесообразности СУБО+
1	Количество потенциальных потребителей
2	Объем функциональности
3	Доля API для внутреннего и внешнего потребления
4	Степень использования API внутренним и внешними потребителями
5	Различные критичность и доступность
6	Различные требования информационной безопасности
7	Учет интересов внешних потребителей повторно используемой функциональности

Теперь я расскажу о текущем шаге нашей трансформации, которая переводит нашу ИТ-архитектуру в пятое поколение. Напомню, что нам мешало в поколении 4++ — это сервис-провайдеры, то есть продуктовые системы типа автоматизированной банковской системы (АБС) Центра финансовых технологий (ЦФТ) и процессинга Way4. Они были построены при двух- и трехзвенной ИТ-архитектуре, со всеми связанными с этим проблемами с надежностью и производительностью этих систем. Замена таких «ядерных» систем в ИТ-ландшафте очень сложная и дорогостоящая задача, и мы ее откладывали, что называется до лучших времен, но в 2022 году ситуация резко поменялась и потребовалось импортозамещение этих систем. После тщательного анализа принято решение писать банковское ядро своими силами. Создается это ядро в той же омникальной архитектуре. То есть продуктовая логика обслуживания в СУБО, которые выводятся в канальные приложения, логика повторного использования — в ОПС.

Банковское ядро имеет слои:

Фронтальной логики обслуживания клиентов со своим набором СУБО;
Обеспечивающие сервисы, необходимые для поддержки этих процессов тоже со своим набором СУБО/ОПС;
Появился слой ОПС специального типа — продуктовый процессор, который обеспечивает продуктовый учет;
Бухгалтерский учет обеспечивается общими сервисами (ОС) платформы: «Генератор счетов» и «Генератор проводок», и СУБО+ «Главная книга»;
Расчеты в СУБО+ «Расчетные сервисы».

На сегодняшний день — это ключевая трансформация ИТ-архитектуры ВТБ. Надеюсь, я объяснил суть омниархитектуры:

В основе омниархитектуры лежит деятельность продуктовых или ценностных команд, которые создают уникальные и актуальные продукты на слое СУБО. А также выводят свои сервисы во все необходимые каналы;
А общие для всех элементы, функции и сервисы находятся на слоях общих, общих продуктовых и служебных сервисов.

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

Через тернии к Омни. Эпизод 7. Бережливая унификация