Как обеспечить совместимость разных отечественных ИТ-продуктов

Совместимость отечественных ИТ продуктов сегодня упирается не в трудность интеграции как таковую, а в отсутствие общих правил: единых стандартов данных и API, которые позволяли бы подключать системы без ручной настройки. Выйти из этого можно через экосистемный подход: открытые референс архитектуры, общие протоколы обмена и индустриальные консорциумы, где совместимость не декларируется, а проверяется и сертифицируется.

Почему «не стыкуется» даже отечественное с отечественным

На волне импортозамещения рынок быстро заполнился российскими решениями: ОС, СУБД, средства виртуализации, документооборот, ИБ, отраслевые платформы. Но во многих компаниях результат выходит неоднородным: набор продуктов работает, но между собой общается через разовые интеграции, скрипты, обмен файлами и индивидуальные коннекторы.

Причина чаще всего не в качестве конкретного вендора, а в системной проблеме: в разных сегментах нет обязательных отраслевых стандартов на интерфейсы и модели данных, а открытые API существуют не всегда или реализованы «каждый по своему» (разные форматы сущностей, версии, механизмы авторизации, подходы к ошибкам и журналированию). На практике это приводит к тому, что каждая новая интеграция превращается в отдельный проект со своим бюджетом, сроками и рисками.

Цена «лоскутной» архитектуры

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

• Долгий time-to-market: продукт или сервис готов, но «шина», обмен данными и учетные контуры не поспевают за ними.
• Рост операционных рисков: любое обновление одной системы может сломать цепочку интеграций, потому что контракт интерфейса нигде жестко не закреплен.
• Дублирование данных и «несогласованная правда»: разные системы хранят разные версии одной сущности (клиент, договор, объект, заявка).
• Дефицит компетенций: команда вынуждена держать специалистов по уникальным коннекторам и самописным обменам вместо развития архитектуры.

Именно поэтому в зрелых ИТ организациях совместимость рассматривают как стратегический актив, а не как задачу интегратора на проект.

Что можно сделать уже сейчас на уровне компании

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

• Ввести внутренний стандарт API: единый стиль (REST/gRPC), версионирование, формат ошибок, требования к идемпотентности, трассировке, логированию и обратной совместимости.
• Сделать условия обмена данными обязательным: справочники, мастер данные, словари полей, единые идентификаторы, правила качества и согласования изменений.
• Использовать промежуточный слой интеграции: ESB/iPaaS, event bus или брокер сообщений, чтобы уменьшать количество прямых «точка точка» связей.
• Принять принцип «API first»: сначала контракт, потом реализация — иначе интеграции всегда будут догонять разработку.

Но важно понимать ограничение: внутренние стандарты помогут навести порядок внутри компании, однако не решат проблему межвендорной совместимости, когда продукты надо соединять быстро и без доработок.

Референс архитектуры: общий язык для экосистемы

Дальше начинается уровень рынка: если каждый вендор строит «свой мир», клиент неизбежно получает лоскутную систему. Поэтому перспективный путь — развитие экосистемы на базе открытых референс архитектур: описаний типовых компонентов, слоев, интерфейсов и требований к нефункциональным характеристикам (надежность, безопасность, наблюдаемость, масштабирование).

Референс архитектура не равна монолитному единому стандарту на все. Это скорее каркас, который помогает:

• разделить ответственность между компонентами (где мастер данные, где процесс, где витрина);
• определить типовые интеграционные сценарии (события, запрос ответ, пакетный обмен);
• закрепить минимально необходимый набор интерфейсных требований, чтобы продукты «понимали» друг друга без кастомизации.

В финансовом секторе уже виден эффект от движения к единым правилам взаимодействия через Open API: «Ассоциация ФинТех» сообщает, что Банк России утвердил и опубликовал стандарты Открытых API, включая базовые основы взаимодействия и профили безопасности, а также спецификации API и правила взаимодействия; переход пилотных участников на утвержденные версии спецификаций запланирован на 1 октября 2026 года. Это пример того, как стандартизация интерфейсов снижает долю штучных интеграций и создает масштабируемую модель взаимодействия.

Общие протоколы и модели данных

Даже идеальный API не спасет, если стороны по разному понимают данные. Поэтому для совместимости нужны два слоя договоренностей:

1. Протоколы/транспорт и правила API (как стучимся, как авторизуемся, как версионируемся, как обрабатываем ошибки).
2. Семантика данных (что такое «контрагент», «договор», «лицевой счет», «единица оборудования»; какие обязательные поля; какие допустимые значения).

На первом уровне полезны отраслевые рамочные требования, аналогичные тем, что описаны в стандарте Банка России по открытым программным интерфейсам: там фиксируются, в частности, требования к кодировке (UTF 8), структуре URI, базовым HTTP заголовкам, кодам статусов, идемпотентности и другим параметрам взаимодействия. Такой подход важен тем, что он делает API предсказуемым по общему документу.

На втором уровне нужны отраслевые модели данных и справочники. Без них совместимость вырождается в конвертацию форматов, а не в согласованную цифровую цепочку.

Индустриальные консорциумы и совместная сертификация

Один из самых практичных механизмов — консорциумы, где вендоры договариваются о правилах совместимости и подтверждают ее тестами и сертификацией. Формат может быть разным:

• совместные тестовые стенды (interoperability lab);
• матрицы совместимости версий (что с чем работает);
• единый набор тест кейсов и требований к API/данным;
• программа «совместимо с…» с регулярной переаттестацией при обновлениях.

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

Как заказчику выбирать продукты с прицелом на совместимость

Если вы закупаете или внедряете отечественные решения, совместимость стоит проверять заранее — так же строго, как функциональность и безопасность.

Практичные вопросы на этапе RFP/пилота:

• Есть ли у продукта открытое API, документация и политика версионирования; поддерживается ли обратная совместимость?
• Есть ли готовые коннекторы к ключевым для вас системам (ERP/CRM/IDM/ESB/BI/СУБД) и кто отвечает за их поддержку?
• Как организованы наблюдаемость и диагностика интеграций (трассировка, метрики, корреляционные ID)?
• Есть ли участие в отраслевых инициативах/консорциумах и подтвержденная матрица совместимости?
• Какие обязательства по совместимости закреплены в договоре (SLA на интеграции, сроки исправления дефектов, регламент изменения API)?

Совместимость — это управляемый параметр, если требовать ее как продуктовую характеристику, а не «доделку интегратором».