Как мы проектируем карту интеграций до первой строки кода

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

Поэтому в Korveniq Technologies каждый проект начинается с карты интеграций — документа, который описывает все системы, потоки данных и владельцев ещё до первой строки кода. Он превращает неизвестные зависимости в управляемый список рисков.

Обследование: какие системы участвуют

Сначала мы вместе с заказчиком перечисляем все системы, с которыми будет связан продукт: CRM, ERP, учётные базы, мессенджеры, платёжные и внутренние сервисы. Для каждой фиксируем способ доступа, ограничения по нагрузке и версию API.

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

Владельцы данных и источники правды

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

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

SLA, ошибки и сценарии отказа

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

Такие договорённости заранее переносятся в мониторинг и тесты, а не обнаруживаются в первую неделю эксплуатации.

Карта показывает системы, потоки данных и ответственных на одной схеме.

Что получает заказчик

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

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