API-first внутри компании: почему интеграции не должны рождаться по знакомству
Как договориться об интерфейсах между системами до того, как хаос интеграций стал нормой, и зачем это важно для роста компании.
В большинстве компаний интеграции между системами появляются по одному принципу: кто-то кому-то позвонил, договорились, сделали. Разработчик из одного отдела попросил коллегу из другого "дать доступ к данным" - и тот дал, как удобно. Через прямую выгрузку в таблицу, через скрипт, через общий пароль к базе.
Это работает, пока компания маленькая. Потом это начинает медленно ломать всё вокруг.
Что происходит, когда интеграции не спроектированы
Через два-три года при таком подходе компания обнаруживает знакомую картину:
- никто не знает, какие системы с чем связаны;
- любое изменение в одной системе непредсказуемо ломает что-то в другой;
- данные одного отдела попадают к другому через промежуточные выгрузки, у которых нет владельца;
- при смене подрядчика или разработчика половина интеграций становится необъяснимой.
Это не проблема конкретных людей, которые делали плохую работу. Это отсутствие договора.
Что означает подход API-first
API-first - это не про технологию. Это про дисциплину: прежде чем две системы начнут обмениваться данными, нужно явно описать этот обмен. Об этой дисциплине в её внешнем измерении речь шла раньше, но та же логика не менее актуальна для внутренних систем. Что передаётся, в каком формате, в каком направлении, кто за это отвечает, как обрабатываются ошибки.
Такое описание - это контракт. Он может быть реализован по-разному технически, но его суть одна: интеграция существует как явный, задокументированный интерфейс, а не как неформальная договорённость между людьми.
Когда контракт есть, можно менять реализацию с обеих сторон независимо. Когда контракта нет - каждое изменение требует согласования между командами, а каждая ошибка превращается в расследование.
Почему это важно для бизнеса, а не только для разработчиков
Директора иногда воспринимают разговор об API как технический разговор, который им не обязателен. Это ошибка.
Интеграция без контракта - это скрытая зависимость. Когда компания меняет CRM, оказывается, что к ней подключено ещё восемь систем, о которых никто не думал. Когда подрядчик уходит, оказывается, что только он знал, как работает связка между складом и бухгалтерией. Когда данные расходятся в отчётах - расследование занимает недели, потому что никто не знает, где и как происходит трансформация.
Это не техническая проблема. Это проблема управляемости.
С чего начинается порядок
Хорошая новость в том, что не нужно переписывать всё с нуля. Порядок в интеграциях вводится постепенно.
Первый шаг - инвентаризация: составить список того, что с чем связано прямо сейчас. Часто оказывается, что даже этого никто не делал.
Второй шаг - для каждой новой интеграции ввести правило: прежде чем начинать, описать интерфейс. Что система A ожидает от системы B и наоборот. Это занимает несколько часов, но экономит недели при будущих изменениях.
Третий шаг - для критичных интеграций сделать то же ретроспективно: описать, как они работают сейчас, и зафиксировать это.
Простой вопрос для проверки
Если в вашей компании завтра уволится человек, который настраивал интеграцию между двумя ключевыми системами - сколько времени займёт у другого разработчика понять, как она устроена?
Если ответ "несколько дней" или "не знаем" - интеграции живут в головах, а не в договорах. Это нормально для стартапа на ранней стадии. Но для компании, которая рассчитывает работать ещё пять лет, - это накопленный риск, который рано или поздно предъявят счёт.