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

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

Так наведем линзу нашего пронзающего взгляда на загадочные «башенки» омниканальности.

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

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

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

Что если СУБО «Клиентские данные» понадобился для другого банка или страховой компании? Адаптируем пользовательский интерфейс под корпоративный бренд страховой компании, выводим его в канальные приложения резидента платформы — и готово. Что будем делать, если к платформе подключается банк-партнер, но его не устраивает логика СУБО «Платежи и переводы»? Если хотите продукт с перламутровыми пуговицами, пожалуйста, переписывайте логику процесса «под себя», а общий продуктовый сервис (ОПС) «Продуктовый профиль клиента» используйте через программный интерфейс или API (application program interface).

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

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

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

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

Если логика нужна для нескольких СУБО и ОПС, но не содержит продуктовой специфики, ее можно использовать не только в банковской сфере, но и в других отраслях — для другого банка, в лизинге, факторинге или на нефтегазовом производстве. К примеру, к таким функциям относятся: работа с клиентскими данными, проверки по черным спискам, уведомления по SMS, PUSH или электронной почте. Имеет смысл архитектурно оформить ее как переиспользуемый элемент, но без банковской специфики. То есть, общий сервис или ОС.

А для разработчиков предусмотрены служебные сервисы, которые поддерживают гибкость и функциональность системы. Как вы уже знаете, для гибкости использования такой ИТ-архитектуры слои не перемешиваются, они должны оставаться независимыми. Нижний слой не знает, кто его использует, главное — соблюдение четкого API. Линия разреза строго по слоям. Иначе говоря: смешать, но не взбалтывать.

Вот почему возможны разные описанные выше сценарии: можно заменить пользовательский интерфейс в СУБО, можно переписать СУБО, сохранив при этом логику ОПС/ОС. Если бы ОПС знали про СУБО, невозможно было бы разрезать архитектуру на уровне ОПС, пришлось бы вносить изменения в СУБО, что нарушило бы гибкость системы. Это привело бы к архитектурному хаосу, где сервисы потеряли свою автономность и слились в монолитную систему, как в старых архитектурах. Мы бы вернулись к проблемам предыдущих поколений, которые пытались решить с помощью новой архитектуры. Те, кто попытается нарушить эту структуру, будут вынуждены решать гораздо более сложные проблемы в ближайшее время.