На выходных поймал себя на довольно показательной мысли. Сначала был кейс про Kafka-команду, потом разговор про платформы и зоны ответственности, а уже после стало очевидно, что всё это упирается не в технологии, а в оптику, через которую мы на них смотрим.

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

В сервисной логике платформа существует для того, чтобы «ничего не упало». Команда отвечает за аптайм, патчи, алерты и регламенты. Всё, что выходит за рамки стабильности, перекладывается на потребителя: заявки, согласования, расчёты партиций, реплик и брокеров. Формально система работает, фактически — охраняется вход в кластер.

В продуктовой логике платформа существует для того, чтобы ею пользовались. Здесь фокус смещается с инфраструктуры на устранение трения: насколько быстро команда может начать интеграцию, сколько шагов нужно пройти до первого результата, сколько ручных решений переложено на автоматизацию, и какую бизнес-ценность платформа реально создаёт.

Разница между этими подходами хорошо видна в метриках.

Для сервисной модели ключевая метрика — стабильность.
Для продуктовой — скорость и простота использования.

Например, вместо абстрактного «Kafka работает» появляется вполне конкретная продуктовая метрика: Time to First Message — сколько времени проходит от запроса команды до первой записи в топик. Если это минуты — у вас продукт. Если дни или недели — у вас сервис с бюрократической обвязкой.

Если упростить, различие выглядит так:

Сервисная платформа
— метрика успеха: аптайм
— пользователь: источник риска
— главный артефакт: заявка

Продуктовая платформа
— метрика успеха: time-to-market
— пользователь: клиент
— главный артефакт: быстрый результат

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

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

Если хочется совсем приземлить эту мысль, вот простой вопрос для самопроверки, который можно задать платформенной команде уже завтра:

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

Ответ на этот вопрос очень быстро показывает, вы строите продукт или просто охраняете вход в кластер.