Open data и API: зачем компании думать как платформа уже сейчас
API - это не модный интерфейс и не способ выглядеть технологично. Это дисциплина интеграции, которая определяет, насколько легко ваши системы будут работать вместе через год.
Когда разговор заходит про API, руководители обычно слышат одно из двух. Либо это что-то для разработчиков - технический вопрос, который не стоит вникать. Либо это что-то модное - "надо открыть API, потому что Google и Amazon так делают".
Оба прочтения уводят от реального смысла. API - это прежде всего дисциплина того, как системы внутри компании и между компаниями обмениваются данными. И эта дисциплина имеет прямые деловые последствия.
Что такое API в практическом смысле
API - это контракт. Система А говорит системе Б: "вот каким образом ты можешь у меня что-то запросить, вот что я верну, вот что не изменится". Всё остальное - внутренняя кухня, которая может меняться.
Когда такого контракта нет, интеграции строятся иначе. Системы читают базы данных друг друга напрямую. Файлы передаются по расписанию через FTP. Один разработчик знает, "как оно сейчас работает", и держит это в голове. При увольнении этого разработчика интеграция превращается в загадку.
Я видел компании, где смена версии одной системы ломала пять других - именно потому, что никакого контракта не было. Была просто привязка к конкретной схеме базы данных.
Почему "сделаем потом" обходится дороже
Архитектурные решения, принятые на старте, живут долго. Компания, которая строила интеграции без API-контрактов три года, через три года обнаруживает, что у неё:
- несколько "источников правды" по одним и тем же данным;
- интеграции, которые никто не решается трогать;
- невозможность добавить нового партнёра или канал без отдельного большого проекта;
- зависимость от конкретных людей, которые "это понимают".
Переход от этого состояния к нормальному - дорогостоящий рефакторинг. Не технический подвиг, а длинная и скучная работа, которую приходится делать параллельно с текущими задачами.
Open data как частный случай
Движение за открытые данные, которое сейчас набирает силу в государственном секторе и технологических компаниях, построено на той же идее. Данные становятся доступны через стабильные, документированные интерфейсы. Другие могут строить поверх них продукты и сервисы - без согласования с каждым источником отдельно.
Для коммерческой компании это может означать следующее: если ваши данные о продуктах, заказах или партнёрах доступны через нормальный API, то интеграция с новым маркетплейсом, агрегатором или партнёром становится задачей на дни, а не на месяцы.
Это не "открытость ради открытости". Это снижение стоимости каждой следующей интеграции.
Где начинать, если API пока нет
Не нужно переписывать всё сразу. Разумный подход:
- выделить самые болезненные точки интеграции - где чаще всего что-то ломается или требует ручного вмешательства;
- зафиксировать контракт для этих точек - даже если реализация пока старая;
- при любом новом проекте ставить требование: никаких прямых соединений к базам данных, только через контракт.
Это не революция. Это постепенная замена неявных зависимостей явными.
Три вопроса для руководителя
Прежде чем следующий раз одобрять интеграционный проект, стоит задать команде:
- Какой контракт будет у этой интеграции и кто за него отвечает?
- Что произойдёт, если одна из сторон изменит свою внутреннюю схему?
- Можно ли добавить третью систему к этому обмену без переписывания?
Если на эти вопросы нет ответа - проект скорее всего создаёт новый жёсткий узел, который через год будет страшно трогать. Это и есть та цена, которую платят компании, думающие про API как про интерфейс, а не как про дисциплину.