Срочно! Ищем ИТ-руководителей и архитекторов для дискуссии о интеграции. Публикация на хабре!

Готовим экспертную онлайн-дискуссию о том, почему интеграция корпоративных систем регулярно оказывается сложнее и дороже, чем предполагалось в начале проекта.

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

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

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

Дата и формат

6 августа 2026 года, 15:00–16:00 МСК.

Дискуссия пройдет удалённо, продолжительность — один час. Потребуются стабильное интернет-соединение, камера и микрофон.

Запись разговора и основные тезисы участников будут использованы при подготовке публикации на Хабре.

Приглашаем:

— CIO, CTO, CDO и руководителей цифровой трансформации;

— руководителей направлений интеграции, разработки и корпоративной архитектуры;

— enterprise- и solution-архитекторов;

— руководителей внутренних платформенных и инфраструктурных команд;

— технических специалистов банков, ритейла, промышленности, телекома, логистики, электронной коммерции и других компаний со сложным ИТ-ландшафтом.

Что планируем обсудить

1. Почему интеграцию почти всегда недооценивают при расчёте сроков и стоимости проекта?

2. В каких случаях обычного брокера сообщений действительно достаточно, а когда вокруг него приходится строить дополнительную платформу?

3. Где проходит граница между удобным самописным адаптером и неуправляемым «зоопарком» интеграций?

4. Нужно ли разрешать прикладным системам напрямую работать с Kafka или RabbitMQ либо доступ должен проходить через отдельный сервисный слой?

5. Насколько дорого обходится эксплуатация брокера с учётом мониторинга, consumer lag, повторной доставки, повреждённых оффсетов, изменения схем и поиска потерянных сообщений?

6. Кто в компании должен отвечать за контракты сообщений, совместимость форматов и изменение интеграционных интерфейсов?

7. Где low-code и визуальная настройка интеграций действительно ускоряют работу, а где всё равно требуется программирование?

8. Какие архитектурные решения хорошо выглядели на старте, но создали проблемы после роста количества систем и сообщений?

9. Какой реальный интеграционный сбой оказался для вашей команды самым показательным и какие выводы вы из него сделали?

В ответе укажите:

— имя, должность и компанию;

— вашу роль в интеграционных или платформенных проектах;

— готовы ли вы участвовать 6 августа с 15:00 до 16:00 МСК с включённой камерой.

Количество участников ограничено!