Сложный ИТ-ландшафт: как описывать обмены, чтобы развитие не тормозилось
18 февраля 2026 года состоялась онлайн-встреча, посвященная теме описания обменов и данных в ИТ-ландшафте. Формат – открытый диалог представителей производства и интегратора. Эксперты разобрали практические кейсы и обсудили подходы к проектированию и документированию интеграций.
Фокус встречи – как выстроить работу с обменами между системами так, чтобы ИТ-ландшафт мог масштабироваться, снижались риски проектов и ускорялась разработка.
Эксперты встречи
- Дмитрий Шаров, модератор встречи, генеральный директор Data Tech Team
- Валерий Немцов, технический директор Data Tech Team
- Дмитрий Комаров, руководитель группы разработки интеграционных потоков агрохолдинга «Комос Групп»
О чем говорили
1. Почему без формализованных обменов развитие буксует
Валерий Немцов обозначил типовые сценарии, когда вопрос описания ИТ-ландшафта становится критичным:
- приход нового ИТ-директора и отсутствие прозрачной картины интеграций;
- запуск масштабной программы трансформации;
- необходимость заменить одну систему другой без потери функциональности.
Обсуждалось, что системы не существуют в вакууме: при внедрении новой системы или замене существующей необходимо:
- понять, какие данные система получает и откуда;
- определить, какие данные передаются вовне;
- проверить полноту и корректность потоков;
- учесть промежуточные состояния при переходе между решениями.
Отдельный акцент был сделан на различии между архитектурой «точка-точка» и использованием корпоративной шины данных (ESB), где критичным становится контроль связей и их формализация.
2. Документирование как часть процесса разработки
Обсуждался типовой разрыв: документация в виде Excel-файлов или бумажных описаний появляется после проекта и быстро теряет актуальность.
Была предложена логика встраивания документирования в полный цикл:
- проектирование;
- описание обменов;
- разработка;
- тестирование (автоматическое и ручное);
- вывод в промышленную эксплуатацию;
- поддержка.
Ключевая идея – документация должна быть не финальным артефактом, а активным элементом процесса.
3. А что в агрохолдинге «Комос Групп»: цифры и кейсы
В практической части Дмитрий Комаров показал, как это работает на масштабе: в холдинге с 450 информационными системами и 1300+ обменами через шину ежедневно проходит около 450 тыс. пакетов данных, и управляет этим команда из 8 человек.
Формализованное описание интеграций позволило заменить legacy-систему (Axapta → 1С УТ) без потери связей, внедрить систему прогнозирования с единым владельцем документации, провести инвентаризацию потоков с ПДн под ФЗ-152 и тиражировать 1С-решения так, что типовой запуск стал занимать 2 дня вместо месяцев за счет повторно используемых, задокументированных обменов.
Самое полезное со встречи
- При 3–10 обменах документирование кажется избыточным; после 100+ обменов без него развитие останавливается.
- При 300–400 обменах удельная стоимость разработки и сопровождения начинает снижаться за счет структурированности.
- Документация приравнивается к коду: есть разработка, ревью, ответственность двух специалистов.
- Централизованный владелец документации снижает риски рассинхронизации команд.
- Тиражирование возможно только при формализованных обменах иначе каждый запуск становится уникальным проектом.
Вывод
Встреча показала, что формализованное описание обменов – это не вспомогательная активность, а инфраструктурный элемент развития ИТ-ландшафта. Практика «Комос Групп» продемонстрировала, что интеграция документации в процесс разработки влияет на сроки, стоимость сопровождения и масштабируемость решений.
Особенно релевантной встреча была для ИТ-директоров, руководителей интеграционных команд и специалистов по цифровой трансформации в пищевой промышленности.
1. Для старта документирования достаточно зафиксировать:
- список систем‑участников обмена;
- форматы передаваемых данных;
- периодичность и объем обменов;
Этого набора достаточно для базового понимания процессов.
2. Документация как первый артефакт
В процессе роста компетенций мы эволюционно изменили подход к разработке: документация должна создаваться до написания кода, а не после. Это позволяет:
- выявить потенциальные проблемы на этапе проектирования;
- согласовать все детали с заинтересованными сторонами;
- сократить количество правок в процессе реализации.
Автоматизация минимизирует человеческий фактор и гарантирует актуальность данных.
3. «Правила входа» для новых интеграций
Мы установили обязательные требования для подключения новых систем:
- наличие полного описания обмена в системе документирования – требование для вывода обмена в продуктив;
- обязательно настроенные инструменты мониторинга
- обязательное сквозное тестирование обменов в тестовом контуре но на реальных данных до принятия решения о запуске обменов.
- Обязательный двухнедельный карантин «после последней ошибки», после которого обмены считаются стабилизированными и принятыми на поддержку
Без выполнения этих условий интеграция не должна запускаться в эксплуатацию.
4. Контроль качества
Регулярные проверки документации:
- назначаем ответственного за аудит актуальности описаний интеграций после любой корректировки кода;
- проводим кросс‑проверки – один аналитик проверяет документацию, написанную другим;
- Внедряем формализованные чек‑листы для оценки полноты и корректности данных (регламент документирования интеграций).
Качество документации напрямую влияет на скорость решения инцидентов и стоимость сопровождения.
5. Масштабирование
По мере роста числа интеграций:
- стандартизируем шаблоны документации для типовых сценариев;
- автоматизируем рутинные операции по созданию и обновлению описаний (формирование ТЗ, автоматическое создание документации при тиражировании обменов, и т.д.);
- выделили отдельных членов команды, выполняющих роли конечной экспертной точки для основных критических операций (управления документацией в крупных проектах, «нейминг» сущностей связанных с обменами, и т.д.).
Масштабирование без стандартизации ведет к хаосу – закладывайте основы для роста на ранних этапах.
_
Информационные партнеры встречи:
1. Будни Digital CTO — будничные вопросы ИТ в Еком и Маркетплейсах, клиентский путь и UX, digital tech, microservices от Digital CTO — Андреева Алексея.
2. Datareon — ведущий российский разработчик программного обеспечения, специализирующийся на решениях для автоматизации интеграции приложений и управления данными.
Продолжение следует
Наше сообщество продолжает серию онлайн- и офлайн-встреч по вопросам цифровизации пищевой отрасли. Анонсы новых мероприятий публикуются в телеграм-канале Digital4food, следите за обновлениями!
