Компонуемая бизнес-архитектура (англ. composable business architecture) — наиболее гибкий путь к расширению функциональных возможностей приложения с помощью рекомбинации отдельных блоков. Самой доступной аналогией может служить детский конструктор: соединяя отдельные детали различными способами, получаем фигуры для многих вариантов использования.
Иными словами, созданное по принципу «компонуемой бизнес-архитектуры» приложение должно состоять из отдельных блоков, которые можно реиспользовать для создания нового приложения без программирования.
Ключевые характеристики компонуемой бизнес-архитектуры:
- модульность— оптимальный размер решения, лёгкое сопровождение, компоненты предназначены для первичной и повторной сборки решения в разных контекстах, чтобы обеспечить соответствие меняющимся бизнес-потребностям;
- автономность— отдельные компоненты, минимум взаимозависимостей между ними;
- оркеструемость — компоненты легко включаются в новые бизнес-процессы;
- обнаруживаемость— компоненты сами включаются в каталог маркетплейса, легко выявляются и дают полную информацию о себе.
Приложение, состоящее из микросервисов, лишь частично соответствует принципу компонуемой архитектуры. Микросервисы можно использовать для создания нового приложения, но сделать это с небольшим объёмом кода (англ. low-code) и уж тем более совсем без программирования — не получится. Кода будет чересчур много.
Поэтому для реализации этого принципа нужны более крупные строительные блоки — Packaged Business Capabilities (PBC).
Проще говоря, большие решения для бизнеса состоят из набора PBC, а они в свою очередь — из набора микросервисов. Из этих строительных блоков бизнес и может строить большие решения.
Пример реализации компонуемой архитектуры — решения компании «Диасофт». Они называются платформами развития, состоят из наборов PBC и закрывают различные потребности бизнеса, например, работу на финансовых рынках, обслуживание корпоративных и розничных клиентов. Примеры таких платформ рассмотрим в конце курса.
PBC — это готовая, автономная бизнес-возможность, упакованная как сервис.
Бизнес — это возможности. PBC — программный компонент (мини-приложение), содержащий в себе реализацию набора этих возможностей. То есть строительный блок для создания цифрового двойника бизнеса.
PBC — это набор микросервисов, данных, методов программного интерфейса (API) и пользовательских диалогов, адаптивных или специфичных для каждого из каналов, где его планируется публиковать.
Это не просто набор, микросервисов, а бизнес-ориентированные компоненты, которые:
- имеют чёткий бизнес-контракт
- обеспечивают законченную функцию
- могут использоваться в разных приложениях
- управляются одной командой-владельцем
Как избежать дублирования?
- Единый реестр компонентов — каталог всех доступных PBC.
- Правила именования и версионирования — единые стандарты.
- Ownership — каждая PBC имеет команду-владельца.
- Архитектурный надзор — архитектурный совет утверждает новые компоненты.
- Единые архитектурные принципы.
Архитектурные принципы — это фундаментальные правила, которые используются для принятия архитектурных решений и раскрывают способ их реализации на практике. На их основе разрабатывается структура типового приложения или, выражаясь образно, скелет приложения. Для каждого элемента структуры стандартизируется технологический стек.
Как определить правильный размер РВС?
- PBC слишком мал, если для любого бизнес-пользователя нужны дополнительные PBC.
- PBC слишком велик, если бизнес-пользователь использует (через API) лишь его отдельные части (микросервисы), никогда не обращаясь ко всему PBC напрямую.
- PBC правильного размера, когда бизнес-заказчик может сразу же чётко связать его со своим бизнес-доменом на предприятии и быстро описать, чего от него ожидает.
Чем PBC отличается от классического микросервиса?
| Критерий | Микросервис | PBC |
| Ориентация | Техническая (например, «UserService) | Бизнес-функция (например, «ManageCustomer) |
| Интерфейс | Технический | Бизнес-читаемый |
| Граница | Техническая (например, «БД клиентов») | Бизнес-домен (например, «Жизненный цикл клиента») |
| Ответственность | За техническую функцию | За бизнес-результат |
| Имя | CustomerDataService | CustomerManagement |
| Понятен | Разработчику | Бизнес-аналитику, продукт-менеджеру |
Почему недостаточно одних лишь микросервисов?
Почему «low-code платформы» не решают проблему для бизнес-пользователей?
Почему среды вроде Mendix, OutSystems, Microsoft Power Apps, где можно создавать приложения через визуальные конструкторы, без глубокого программирования, не работают в условиях хаотичной микросервисной архитектуры?
Ответ: Low-code платформы зависят от качества и понятности API.
Т.к. микросервисы имеют технические имена (UserManagementService_v2, AuthProxy), возвращают нестандартизированные данные и требуют сложной аутентификации, бизнес-пользователь не сможет их использовать.
Low-code работает только если сервисы — бизнес-читаемые, стандартизированные, документированные.
Решение — использовать комбинации таких «мини-приложений» (PBC), тогда каждое бизнес-подразделение, команда или отдельный бизнес-пользователь в рамках организации вполне сможет создавать собственные функциональные приложения с помощью композиционной платформы.