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