С 1 октября 2011 года федеральные ведомства обязаны получать данные друг у друга через СМЭВ, а не требовать справки с заявителя. С июля 2012-го та же норма заработала на региональном уровне. На бумаге всё стройно: единая шина, электронные сервисы, реестр. На практике каждое ведомство подключалось по-своему, в своём темпе и со своим пониманием форматов. Результат предсказуем – сотни сервисов, которые работают по-разному, ломаются при обновлении смежника и не имеют единого владельца.

Корень проблемы не в технологии. Шина на базе СМЭВ и протоколы СЭД-СМЭВ описаны достаточно. Проблема организационная: интеграцией одновременно занимаются десятки подрядчиков, каждый трактует методические рекомендации по-своему, и никто не отвечает за систему целиком. Навести порядок поможет единый проектный офис.

Что делает проектный офис

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

Первая – реестр сервисов как единый источник правды. Не выгрузка из тестовой среды раз в квартал, а живой каталог: кто поставщик, кто потребители, какая версия WSDL в проде, когда последний раз менялся контракт, кто отвечает за инцидент. Без такого реестра любое изменение схемы у одного ведомства превращается в неделю расследований у пяти других.

Вторая – типовые адаптеры и шаблоны подключения. Когда каждый подрядчик пишет SOAP-клиент с нуля, вы получаете десять реализаций подписи по ГОСТ, восемь способов обработать тайм-аут и ноль переиспользования. Офис задаёт эталонный адаптер, библиотеку для работы с ЭП и чек-лист приёмки. Новое ведомство подключается за недели, а не за квартал.

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

Где обычно рвётся

Главная боль – данные. СМЭВ передаёт XML по жёстким схемам, но за каждым сервисом стоит ведомственная база с собственной моделью. Реестры населения, недвижимости, транспорта проектировались годами и десятилетиями, без оглядки друг на друга. Сопоставление сущностей, нормализация адресов, согласование справочников – здесь уходит больше времени, чем на сам обмен сообщениями.

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

Куда смотреть дальше

Жёсткие XML-схемы СМЭВ удобны для строгих контрактов, но плохо тянут эволюцию: добавить поле – значит выпустить новую версию сервиса и согласовать её со всеми потребителями. Поэтому внутри ведомственных контуров стоит присматриваться к более гибким моделям хранения – например, к поддержке JSON в PostgreSQL, которая позволяет хранить полуструктурированные данные без жёсткой схемы на каждом шаге.

Вывод

СМЭВ сегодня – это не дефицит технологий, а дефицит управления. Единый проектный офис с живым реестром сервисов, типовыми адаптерами и дисциплиной изменений превращает россыпь разрозненных подключений в управляемую систему. Сначала наведите порядок в процессе – техника подтянется.