Минская торговая компания, 60 человек. Учёт в 1С, продажи в Битрикс24, склад в отдельной программе, сайт на самописном движке. Каждое утро кладовщик выгружает остатки в CSV и отправляет их контент-менеджеру. Тот загружает файл на сайт. К обеду остатки снова не совпадают, потому что за три часа что-то продали.
Так работает половина среднего бизнеса. И именно на расшивке таких узлов держится целое направление в разработке, о котором на курсах говорят редко, хотя вакансий там стабильно больше, чем желающих.
Никто не планирует лоскутную автоматизацию. Она собирается сама.
Сначала бухгалтерии нужна 1С — её ставят. Потом отдел продаж просит CRM, и её берут облачную, потому что быстро. Склад живёт в своей системе с 2015 года, её никто не трогает, потому что кладовщики привыкли. Маркетинг подключает сервис рассылок. Появляется маркетплейс, к нему свой личный кабинет. Через пять лет в компании двенадцать программ, и ни одна не знает о существовании остальных.
Дальше начинается ручной труд: перенести, сверить, переспросить. По ощущениям сотрудников — «просто такая работа». По факту — несколько человеко-дней в неделю, которые никто не считает.
Первый и самый очевидный способ — связать программы напрямую. Написали обмен между 1С и CRM, потом между CRM и складом, потом между складом и сайтом.
Проблема в арифметике. Число возможных связей растёт не линейно, а как n(n−1)/2. Для пяти систем это десять обменов. Для десяти — сорок пять. Каждый обмен кто-то написал, кто-то тестировал, и кто-то теперь обязан его чинить, когда одна из сторон обновится.
На практике до сорока пяти дело не доходит: делают только критичные связи, штук восемь-двенадцать. Но и этого хватает, чтобы получить эффект «дёрнули за одну ниточку — распустилось в трёх местах». Обновили конфигурацию 1С — отвалился обмен с сайтом. Разработчик CRM выкатил новую версию API — перестали приходить оплаты.
Отдельная беда — люди. Обмены обычно писали разные подрядчики в разные годы. Документации нет. Логика зашита в код, который никто, кроме автора, не читал. Автор давно не работает.
Прежде чем говорить о платформах, стоит понимать базовые механики. Все интеграции в мире собираются из них.
Одна система кладёт файл, другая забирает. CSV, XML, Excel-выгрузка по расписанию на FTP. Технология тридцатилетней давности, и она до сих пор массово живёт в производстве и логистике.
Плюс: работает с чем угодно, даже с системой без API. Минус: данные всегда немного устаревшие, а ошибку вы заметите не сразу.
Две программы пишут в одну таблицу. Быстро, дёшево, и абсолютно неуправляемо при росте: любое изменение схемы ломает обе стороны сразу. Хороший вариант для двух систем, плохой — для пяти.
Программный интерфейс, через который одна система запрашивает данные у другой. Сегодня это стандарт: REST с JSON, реже SOAP с XML в старых корпоративных продуктах, gRPC там, где важна скорость.
API даёт актуальные данные в момент запроса. Но требует, чтобы обе стороны были доступны одновременно. Упал сервер CRM — заказ не ушёл, и вы об этом узнаете, если предусмотрели обработку ошибки.
Отправитель кладёт сообщение в очередь, получатель забирает его, когда сможет. RabbitMQ, Apache Kafka, встроенные брокеры платформ. Именно здесь появляются понятия, за которые на собеседованиях цепляются сильнее всего: гарантированная доставка, повторная попытка, идемпотентность.
Последнее объясню, потому что это ключ ко всему. Идемпотентность — свойство операции давать один и тот же результат, сколько бы раз её ни повторили. Сообщение об оплате ушло, ответ потерялся, отправитель повторил. Если система не умеет распознать дубль, клиенту начислят оплату дважды. Без идемпотентности любая асинхронная интеграция рано или поздно порождает призрачные заказы и задвоенные документы.
Логика перехода простая: вместо того чтобы соединять каждую систему с каждой, все подключаются к одному посреднику. Он принимает сообщение, приводит его к нужному формату и передаёт адресату. Десять систем — десять подключений вместо сорока пяти связей.
Такой посредник называется интеграционной шиной, ESB. Это класс промежуточного ПО, выросший из сервис-ориентированной архитектуры начала двухтысячных. Формально задачу решает более широкое понятие — Enterprise Application Integration, объединяющее все технологии обмена внутри одной организации.
Внутри шины три слоя. Коннекторы — готовые модули под конкретные системы, знающие их протоколы. Обработчики — преобразуют форматы и применяют правила, от простого перевода даты из одного вида в другой до логики «заказ дороже двухсот тысяч уходит на согласование». Маршрутизаторы — решают, кому отправить результат, и держат сообщение в очереди, если получатель недоступен.
Развёрнутый разбор архитектуры с таблицей сравнения подходов и отраслевыми кейсами есть в обзоре про интеграция приложений предприятия — там же показано, как считается экономика перехода от прямых обменов к централизованной платформе.
Второй класс решений — iPaaS, интеграционная платформа как облачный сервис. Отличий по существу три: iPaaS живёт в облаке провайдера, изначально заточен под SaaS и вебхуки, и настраивается визуально, без написания кода. ESB чаще ставят на своих серверах, она лучше дружит с legacy и даёт больше контроля.
| Критерий | ESB | iPaaS |
|---|---|---|
| Где работает | серверы компании | облако провайдера |
| Сильная сторона | старые и внутренние системы | облачные сервисы и API |
| Порог входа | нужен инженер интеграций | во многом low-code |
| Скорость запуска | недели | дни |
| Контроль над данными | полный | ограничен провайдером |
Выбирать между ними как между «или — или» на практике не приходится. Крупные компании обычно держат шину для внутреннего контура и облачную платформу для внешних сервисов. По оценкам обзора российских интеграционных платформ, гибридные схемы стали нормой, а сами платформы всё чаще совмещают несколько классов в одном продукте.
Отдельный фактор для рынка Беларуси и России — импортозамещение. Западные вендоры ушли, и требования к наличию продукта в реестре отечественного ПО стали для госсектора обязательными. Это подтолкнуло рост локальных платформ: объём рынка интеграционных решений последние годы измеряется миллиардами долларов и продолжает расти двузначными темпами.
Романтики здесь мало. Работа начинается не с кода.
Сначала инвентаризация: какие системы есть, каких версий, что у них с API, кто их поддерживает. На этом этапе всплывают неприятные новости вроде «а у нас 1С без опубликованных веб-сервисов» или «сайт писал студент в 2018-м, исходников нет».
Дальше картирование потоков. Какие данные, откуда, куда, с какой частотой. Что считать источником истины: если клиент заведён и в CRM, и в 1С, чья версия главная? Вопрос кажется формальным ровно до первого расхождения в реквизитах.
Потом фиксируют контракты обмена — структуру сообщений, обязательные поля, коды ошибок, лимиты. Затем маппинг: сопоставление полей между системами. Скучная, кропотливая часть, где закапывается большинство сроков.
И только потом разработка, пилот на ограниченном объёме, мониторинг. Последний пункт пропускают чаще всего, а зря: без панели, показывающей движение сообщений, поиск причины сбоя превращается в опрос трёх отделов.
Ориентиры по рынку, если считать в часах разработки.
Передача заявки с сайта в CRM — 16–28 часов. Двусторонний обмен CRM с 1С по зафиксированному ТЗ — 80–160 часов. Подключение внешнего сервиса по документированному API — около 30–55 часов. В деньгах типовая связка 1С и CRM у российских подрядчиков выходит в диапазоне от 30 до 150 тысяч рублей, у крупных интеграторов — от 120 тысяч и от двадцати рабочих дней.
Цифра, которую называют реже: поддержка обходится в 20–40 % стоимости внедрения ежегодно. Интеграция — не разовая покупка. Пока обе системы живут и обновляются, кто-то должен чинить обмен.
Здесь и лежит ответ на вопрос, зачем разбираться в теме, если вы учитесь на разработчика.
Интеграционный аналитик. Описывает потоки, собирает требования, ведёт маппинг, спорит с бизнесом о том, что считать источником истины. Нужны навыки бизнес-анализа, понимание нотаций процессов и умение читать документацию API. Кода почти не пишет.
Разработчик интеграций. Пишет коннекторы и обработчики, разбирается с форматами, ловит гонки и дубли. Базово нужен один серверный язык — Java, C#, Python или PHP, — уверенный SQL, понимание HTTP и умение работать с очередями. Плюс терпение: половина работы — чтение чужой документации разного качества.
1С-специалист со стороны обмена. Отдельная и очень востребованная роль. Знание 1С вместе с пониманием REST и очередей даёт заметное преимущество: людей, которые одинаково уверенно чувствуют себя и в конфигураторе, и в веб-сервисах, на рынке немного.
DevOps и поддержка. Разворачивают платформу, настраивают отказоустойчивость, следят за очередями и алертами.
Порог входа в направление ниже, чем кажется. Экзотических технологий здесь нет: HTTP, JSON, XML, SQL, брокер сообщений и аккуратность. Зато сильно ценится системное мышление — способность держать в голове, что произойдёт с данными, если третья система из пяти в этот момент недоступна.
Чем интеграция отличается от простого API? API — это одна деталь: интерфейс, который система предоставляет наружу. Интеграция — сборка целого механизма из таких деталей, где ещё есть преобразование форматов, маршрутизация, обработка ошибок и мониторинг. Наличие API у обеих систем не означает, что интеграция готова.
С какого момента платформа окупается? Практическая граница — четыре-пять систем, которые нужно связывать между собой, при условии что их состав меняется. Для трёх систем со стабильными процессами прямые обмены дешевле и понятнее.
Что делать, если у системы нет API? По убыванию предпочтительности: файловый обмен по расписанию, чтение реплики базы данных, обращение к внутренним таблицам через промежуточный слой. Крайний вариант — RPA, робот, который повторяет действия пользователя в интерфейсе. Работает, но ломается при любом изменении вёрстки.
Low-code означает, что программист не нужен? Нет. Визуальный конструктор снимает рутину написания коннекторов, но не отвечает за то, какие данные считать эталонными и что делать с дублями. Меняется профиль специалиста, а не потребность в нём.
Насколько это безопасно? Платформу можно поставить на собственные серверы, тогда данные не покидают контур компании. В облачном варианте вопрос решается шифрованием каналов, разграничением прав и журналом действий. Централизованный обмен обычно контролировать проще, чем десяток самописных скриптов с зашитыми в код паролями.
Как измерить результат? Три метрики, которые считаются без специальных инструментов: часы разработчика в месяц на поддержку обменов, среднее время поиска причины сбоя, доля операций с ручным переносом данных. Если после проекта они не изменились, проект не удался, какими бы красивыми ни были схемы.
Правило принятия решения простое. Две-три стабильные системы — делайте прямые обмены и не усложняйте. Пять и больше, с планами добавлять новые, — закладывайте платформу сразу, потому что переделывать сложившийся клубок связей дороже, чем построить архитектуру с самого начала.
Для того, кто выбирает специализацию, направление интересно тем, что не устаревает. Программы будут меняться, а задача заставить их разговаривать друг с другом останется. Освоить базу можно через программирование и работу с API — дальше всё зависит от того, насколько вам нравится наводить порядок в чужом хаосе.