Вероятно, те, кто делал платформы повторного использования знает, что часто бывает, когда встречаются потребители общих сервисов, их создатели и архитекторы. Одним нужно быстро, другим дешево, а третьим правильно. Традиционно выберите два из трех? Нет, в этом эпизоде мы узнаем весьма элегантный архитектурный элемент СУБО+. Как можно и быстро, и несложно, и красиво не проиграть в лотерею «2 из 3», а потом еще и переиграть если что-то поменялось.
Еще раз напомню принципы омниканальности: концентрация специфики в СУБО и унификация в ОПС/ОС. То есть, повторное использование в ОПС/ОС, продуктовая специфика в СУБО.
Кликните на картинку, чтобы увеличить изображение
Кажется, все нормально, но по мере развития продуктов у нас изменяется функционал повторного использования, причем как в сторону увеличения, так и в сторону сокращения. Скажем были СУБО, у них был свой функционал, потом этот функционал понадобился еще кому-то, значит выделяем ОПС. А дальше могут появиться еще потребители, а могут нет или сильно позже. Что мы имеем сейчас. Первоначальная архитектура имеет два состояния приведенной ситуации:
-
Нет функционала повторного использования — СУБО;
-
Есть функционал повторного использования — СУБО+ОПС.
В этом случае объем унификации (функционал ОПС) и ее перспективы (потребители) учитывались достаточно прямолинейно, выделением ИС типа ОПС. Со всеми дополнительными организационными, и не только, усилиями по вводу новой единицы управления, без приведенной выше серой зоны. Если переиспользуемый функционал сильно востребован и достаточно определен, это вполне оправдано. А если нет?
То есть, эффект от унификации и усилия на ее организацию могут быть несоизмеримы. Или в будущем один из потребителей отвалится и формально останется только один, что же переводит функционал обратно в СУБО?
Например,
-
Есть могучий «бесчеловечный» (без пользовательского интерфейса) процесс обработки клиентской заявки на продукт. Делаем ОПС и все нормально;
-
И вдруг нужно на каком-то шаге поднять одну формочку, и пользователь должен нажать на кнопку «Согласовано»;
-
И что создавать новый СУБО, новую систему или новую единицу управления, разрабатывать кучу документации, проходить целый жизненный цикл ради несколько десяткой строчек кода? Выглядит весьма сомнительно.
И наоборот,
-
Есть могучий «человечный» (с пользовательским интерфейсом) процесс;
-
И у него появляется пара общих шагов с другим «человечным» процессом. Выделять в ОПС тот же десяток строк? Также сомнительно.
Кликните на картинку, чтобы увеличить изображение
Мы поняли, что нам нужна более гибкая, бережливая, архитектура для учета таких пограничных ситуаций, или так называемых серых зон. Мы подумали и перешли от типов систем к типам программных интерфейсов: есть СУБО с их уникальным функционалом и программным интерфейсом (API), и есть ОПС с их функционалом повторного использования с собственным API. И у нас получился новый элемент платформы: объединение двух элементов СУБО и ОПС в одной системе СУБО+. В этой конструкции и СУБО, и ОПС остаются такими, как и были, но исходя из принципов бережливой унификации объединяются в одну систему или единицу управления СУБО+.
Для принятия решения о целесообразности мы разработали и утвердили методику. Получилась рабочая схема, но на ней сейчас останавливаться не будем. Если интересно, напишите в комментариях — покажем методику. Окончательное решение, с учетом проведенного по методике анализа, принимается на специальной архитектурной площадке по сервисам Платформы.
|
№ |
Критерии оценки целесообразности СУБО+ |
|
1 |
Количество потенциальных потребителей |
|
2 |
Объем функциональности |
|
3 |
Доля API для внутреннего и внешнего потребления |
|
4 |
Степень использования API внутренним и внешними потребителями |
|
5 |
Различные критичность и доступность |
|
6 |
Различные требования информационной безопасности |
|
7 |
Учет интересов внешних потребителей повторно используемой функциональности |
Теперь я расскажу о текущем шаге нашей трансформации, которая переводит нашу ИТ-архитектуру в пятое поколение. Напомню, что нам мешало в поколении 4++ — это сервис-провайдеры, то есть продуктовые системы типа автоматизированной банковской системы (АБС) Центра финансовых технологий (ЦФТ) и процессинга Way4. Они были построены при двух- и трехзвенной ИТ-архитектуре, со всеми связанными с этим проблемами с надежностью и производительностью этих систем. Замена таких «ядерных» систем в ИТ-ландшафте очень сложная и дорогостоящая задача, и мы ее откладывали, что называется до лучших времен, но в 2022 году ситуация резко поменялась и потребовалось импортозамещение этих систем. После тщательного анализа принято решение писать банковское ядро своими силами. Создается это ядро в той же омникальной архитектуре. То есть продуктовая логика обслуживания в СУБО, которые выводятся в канальные приложения, логика повторного использования — в ОПС.
Банковское ядро имеет слои:
-
Фронтальной логики обслуживания клиентов со своим набором СУБО;
-
Обеспечивающие сервисы, необходимые для поддержки этих процессов тоже со своим набором СУБО/ОПС;
-
Появился слой ОПС специального типа — продуктовый процессор, который обеспечивает продуктовый учет;
-
Бухгалтерский учет обеспечивается общими сервисами (ОС) платформы: «Генератор счетов» и «Генератор проводок», и СУБО+ «Главная книга»;
-
Расчеты в СУБО+ «Расчетные сервисы».
На сегодняшний день — это ключевая трансформация ИТ-архитектуры ВТБ. Надеюсь, я объяснил суть омниархитектуры:
-
В основе омниархитектуры лежит деятельность продуктовых или ценностных команд, которые создают уникальные и актуальные продукты на слое СУБО. А также выводят свои сервисы во все необходимые каналы;
-
А общие для всех элементы, функции и сервисы находятся на слоях общих, общих продуктовых и служебных сервисов.
Итак, возвращаясь к определению в начале, архитектура включает: структуру, связи и принципы, которые должны соблюдаться всеми участниками платформы. И омниканальная архитектура полностью соответствует этому определению. Далее вы в деталях узнаете, как выглядит на данный момент омниканальная архитектура ВТБ.
Автор: Vrunov
