На любом предприятии среднего размера работает не одна система, а с десяток: бухгалтерия в 1С, склад в собственной разработке, кадры в отдельном модуле, банк-клиент, а где-то ещё и SAP или «Парус» в головном офисе. Поодиночке каждая решает свою задачу. Проблема начинается там, где данные одной системы нужны другой. Бухгалтер сводит отчёт вручную, кладовщик переносит остатки по почте, а директор получает три разные цифры выручки за один и тот же месяц.

Почему «точка-точка» не масштабируется

Первый инстинкт – связать системы напрямую. Склад выгружает файл, бухгалтерия его читает. Банк-клиент шлёт выписку в 1С через свой импорт. Пока систем три-четыре, это работает. Но число связей растёт не линейно: десять систем дают до сорока пяти возможных каналов обмена. Каждый канал – это свой формат, своя кодировка, свой график выгрузки и свой человек, который один знает, как это починить.

Когда поставщик 1С выпускает новый релиз или банк меняет формат выписки, рушится не одна связь, а половина контура. Сопровождение такой паутины съедает бюджет ИТ-отдела целиком, а развитие останавливается. Это та же ловушка, в которую попадает компания, выбравшая случайный набор коробочных продуктов вместо продуманной архитектуры – мы разбирали это в материале о заказной и коробочной разработке.

ESB как единый контур обмена

Сервисная шина предприятия (Enterprise Service Bus, ESB) переворачивает схему. Вместо того чтобы соединять системы попарно, каждую из них подключают к одной общей шине. Система отдаёт данные в шину в своём формате – шина приводит их к общему виду, маршрутизирует и доставляет получателю в том формате, который понимает он. Десять систем теперь дают десять подключений вместо сорока пяти связей.

Шина берёт на себя то, что раньше делал человек и десяток самописных скриптов: преобразование форматов, гарантированную доставку сообщений, очереди при недоступности приёмника, протоколирование каждого обмена. Если склад на час ушёл в офлайн, сообщения копятся в очереди и доходят, как только он вернётся, – ничего не теряется.

Стандарт здесь – обмен через веб-сервисы и XML, поверх SOAP и JMS. Это не дань моде: единый протокол означает, что подключить новую систему – это написать один адаптер к шине, а не переписывать интеграцию со всеми остальными. Архитектура SOA, на которой строится ESB, перестала быть теорией из презентаций и превратилась в рабочий инструмент. Тот же подход через открытые сервисы сегодня позволяет довести корпоративные данные даже до мобильных устройств – мы писали об этом в связи с выходом iPhone 3G и App Store.

Что это даёт бизнесу и госсектору

Для коммерческой компании выигрыш прямой: отчётность собирается автоматически, остатки и проводки совпадают, закрытие месяца перестаёт быть авралом. Для госсектора ESB решает ещё и задачу межведомственного обмена – данные между учётными системами разных подразделений идут по регламенту, с фиксацией каждого шага, что важно при проверках.

Внедрение шины – не разовая покупка лицензии, а проект: нужно описать форматы, согласовать справочники, выстроить адаптеры под каждую систему. Окупается он за счёт того, что следующая интеграция стоит уже в разы дешевле первой. Старт здесь – аудит контура обмена и проектирование шины под конкретный ландшафт, а не закупка лицензии.

Вывод

ESB не заменяет ваши системы и не требует их выбрасывать. Она встраивается между ними как нервная система: каждый орган работает сам по себе, но сигналы идут через единый центр. Чем больше у предприятия учётных систем, тем раньше стоит перестать плодить связи «точка-точка» и заложить шину в архитектуру – пока паутина интеграций не стала дороже самих систем.