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