Целевое состояние, ожидаемый результат и ответственность MTB ESB Next Gen.

Цели и границы платформы

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

Цели

Единая точка входа. Публиковать и контролировать API через WSO2 API Manager.
Надёжная доставка. Использовать Kafka как транспортный backbone для событий и сообщений.
Изоляция систем. Подключать целевые системы через независимые адаптеры.
Управляемая сложность. Выносить многошаговые процессы в Kestra, не перегружая API Gateway бизнес-логикой.
Повторяемый onboarding. Стандартизировать подключение потребителей, API и новых адаптеров.
Эксплуатационная прозрачность. Обеспечить логи, метрики, трассировку, правила восстановления и понятное ownership.

Целевые показатели требуют подтверждения

В Project Charter приведены проектные показатели доступности, latency и охвата интеграций. До утверждения NFR и измеримого baseline их следует воспринимать как целевые ориентиры, а не как действующие SLA платформы.

Что входит в платформу

управление API, приложениями, подписками и политиками доступа;
публикация документации API в Developer Portal;
маршрутизация сообщений и ведение контрактного каталога Kafka topics;
прямые, асинхронные и оркестрируемые интеграционные потоки;
шаблоны и runtime для адаптеров целевых систем;
callback-механизм для асинхронных ответов;
общие правила идентификации, трассировки и идемпотентности;
развёртывание и продвижение артефактов по Dev, Stage и Prod;
базовые средства наблюдаемости и эксплуатационные процедуры.

Что находится за границами

Платформа не должна становиться:

системой хранения банковских бизнес-данных;
заменой core banking или другой целевой системы;
местом размещения доменной бизнес-логики внутри WSO2;
неуправляемым набором point-to-point интеграций;
архивом сообщений без ограниченного срока хранения;
способом обойти владельца API, security review или release gate.

Границы ответственности

Зона	Ответственность платформы	Ответственность подключаемой команды
API contract	Стандарты, проверка и публикация	Семантика операции и корректность модели данных
Доступ	Механизмы auth, scopes и policies	Обоснование доступа и актуальные владельцы
Доставка	Gateway, transport, routing и platform retry	Корректная обработка ответа и согласованная retry-модель
Целевая система	Адаптер и наблюдаемость интеграции	Доступность, ограничения и бизнес-поведение системы
Поддержка	Диагностика платформенного маршрута	Контекст операции и поддержка потребляющего приложения

Критерий успешной интеграции

Интеграция считается готовой не после создания API в Publisher, а когда:

контракт согласован и опубликован;
определён тип потока и маршрут;
настроены безопасность, scopes и ограничения;
запрос прослеживается end-to-end;
известны timeout, retry и error semantics;
пройдены проверки целевого окружения;
зафиксированы владельцы и путь эскалации.