Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт.

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

Сегодня разберу технику. Что именно сидит под капотом платформы, какие инструменты мы выбрали и почему, где это работает хорошо, а где ломается.

Почему не классический ESB

Коротко, потому что Дмитрий уже написал развёрнуто.

Классическая ESB — это монолитное ядро. Масштабирование только вертикальное. И при падении падает всё. Но самое болезненное для эксплуатации это то, что со временем шина становится местом, куда стекается вся прикладная логика. Через несколько лет она знает о бизнесе компании больше, чем любая из систем, которые к ней подключены. Разобраться в этом — отдельная задача. Это то нас и подтолкнуло к собственному подходу.

Мы сформулировали для себя так: возьмём лучшее из point-to-point и из ESB. Независимые сервисы — без централизованной бизнес-логики. Общий транспорт, общий мониторинг, общий инструментарий — как в ESB.

Концепция называется «умные сервисы и надёжные каналы».

Архитектура: каждая система — отдельный микросервис

Предлагаю посмотреть, как это работает. Для каждой интегрируемой системы создаётся независимый микросервис-коннектор. Он содержит ровно ту логику, которая нужна для взаимодействия с этой системой — и ничего лишнего. Адаптеры общаются через транспортный уровень, который отвечает за доставку и надежность.

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами, и про то, как именно этот слой убивает ИИ-проекты, я уже подробно разбирал в предыдущей статье на Хабре. 

Интеграция - это только одно из пяти узких мест, на которых ломается реальное ИИ-внедрение. Дальше идут атаки на агентов, регуляторика, разрыв стоимости разработки и сценарий, которого нет в голове у заказчика. Со мной в этом разборе еще трое: ИИ-архитектор Андрей Носов, Team Lead пентестер Сергей Зыбнев и директор по информационной безопасности компании Вебмониторэкс Лев Палей. 

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами. Все эти годы интеграция оставалась скучной технической прослойкой, которую в бюджетах по привычке записывали в строку «поддержка». В 2026 году ситуация изменилась, и не потому, что шины вдруг стали красивее или модными, а потому, что ИИ‑проекты начали массово застревать именно в интеграционном слое. В этой статье разберу, почему так происходит, какие архитектурные подходы ломаются первыми на ИИ‑нагрузке и что мы в Диасофт выбрали в качестве рабочего варианта. Будет кейс крупного банка, три грани, на которых интеграция включает или выключает всю ИИ‑стратегию, и честный ответ, когда интеграционная платформа вам не нужна.

Главный тормоз корпоративных ИИ‑проектов в 2026 году это не выбор модели, не мощности GPU и не цена за токены. Это банальный обмен данными между корпоративными системами. В апрельском исследовании Integrate.io 95% ИТ‑директоров назвали проблемы интеграции главным барьером внедрения ИИ. Отчет Anthropic State of AI Agents 2026 фиксирует ту же картину с другого угла: среди инженеров, которые уже строят агентные системы на продакшене, 46% называют интеграцию с существующими корпоративными системами главным техническим вызовом — она обошла и вопросы безопасности, и надежность самих моделей.

Вы когда-нибудь задумывались, почему в вашей любимой игре одни двери открываются, а другие - просто декорация? Почему за одной дверью - босс, а за другой - пустая комната? И я сейчас не про техническую реализацию, а про то, как дверь влияет на восприятие мира, на доверие игрока к системам игры и на саму логику игрового пространства. Это так называемая «Проблема дверей», и сегодня мы разберем, почему эта, казалось бы, простая вещь ломает мозг каждому геймдизайнеру.

Представьте: вы делаете свою первую игру. Вы добавляете дверь. Казалось бы, что может быть проще? Но тут же возникает куча вопросов.

Можно ли открыть эту дверь? Если да - как? Ключом, кнопкой, после выполнения квеста? А если нет - почему она вообще здесь? Является ли она просто частью декорации? Но тогда как игрок поймет, что одни двери - интерактивны, а другие - нет? Ведь если половина дверей в мире нерабочая, а другая - функциональная, но визуально они неотличимы, вы создаете фрустрацию, а не загадку.

А что, если дверь открывается только с одной стороны? Игрок проходит через неё, оборачивается - и видит, что обратно пройти нельзя. Это намеренное ограничение? Или баг? Как вы донесете до игрока, что это часть замысла, а не недоделка?

Или вот ещё: дверь закрывается за спиной. Это должно вызывать напряжение - как в Resident Evil. Но если игрок не был готов к этому, он может подумать, что застрял. Где тут грань между атмосферой и плохим UX?

Еще сложнее - когда дверь становится частью нарратива. Например, вы не можете открыть дверь в дом, потому что «герой ещё не готов эмоционально». Но механически это выглядит как обычная запертая дверь. Игрок не видит внутреннего конфликта персонажа - он видит стену. И начинает биться головой в попытках найти ключ, которого не существует. Так вы рискуете разрушить погружение, а не усилить его.

Сегодня поговорим не просто об инструменте, а о фундаменте, на котором строятся современные интеграционные платформы. Речь пойдет об Apache Camel – открытом интеграционном фреймворке, который лежит в основе таких решений, как Red Hat Fuse, Talend и нашей собственной платформы от «Диасофт» – Digital Q.Integration.

Важно подчеркнуть: мы не используем экспериментальные или нишевые стеки. Наша платформа построена на проверенной, зрелой и широко распространенной связке: Apache Camel и Spring Boot. Это дает стабильность, совместимость с корпоративной инфраструктурой и возможность глубоко интегрироваться с экосистемой Spring – от безопасности до мониторинга и распределенной трассировки.

Добрый день. Сегодня мы поговорим о двух мощных технологиях для асинхронного обмена данными — ActiveMQ Artemis и Apache Kafka. Мы разберемся, что они из себя представляют, как устроены под капотом, и главное — в каких ситуациях стоит выбрать одну, а в каких другую.

Наш план на сегодня довольно насыщенный. Мы начнем с того, почему вообще все пришли к асинхронному общению сервисов. Затем подробно разберем ActiveMQ Artemis — что это и какие задачи решает. Заглянем в его техническую архитектуру, чтобы понять источник его производительности. После этого мы кратко вспомним основы Apache Kafka, чтобы затем перейти к самому интересному — детальному сравнению. Мы составим четкие рекомендации, поговорим о нагрузочных характеристиках и подведем итоги.

Привет, хабр!

Это моя первая статья, поэтому для начала представлюсь. Меня зовут Виктор, мне 40 лет, из которых почти 20 я на разных ролях участвую в разработке различного программного обеспечения для крупных корпораций (в основном финтех). Путь был долгий и тернистый, но сейчас я занимаю роль Системного архитектора и по совместительству Руководителя направления интеграции.

Я всегда любил игры, у меня даже был собственный канал с летсплеями и обзорами разных игр, который, к сожалению, не сыскал успеха. Несмотря на это, около двух лет назад я решил с ноги ворваться в мир геймдева. Ничто не предвещало беды, просто одним февральским вечером будто щелкнуло что-то в мозгу - ХОЧУ… ДЕЛАТЬ… ИГРЫ…

Я человек самодостаточный, так что если хочу, значит, делаю. И на самом деле это очень интересное ощущение - в 40 лет почувствовать себя беспробудным джуном в той области, в которой совершенно ничего не понимаешь, но тебе так интересно.