На выходных поймал себя на довольно показательной мысли. Сначала был кейс про Kafka-команду, потом разговор про платформы и зоны ответственности, а уже после стало очевидно, что всё это упирается не в технологию, а в оптику, через которую мы на них смотрим.
Платформа может быть либо техническим сервисом, либо продуктом. И это принципиально разные модели.
В сервисной логике платформа существует для того, чтобы «ничего не упало». Команда отвечает за аптайм, патчи, алерты и регламенты. Всё, что выходит за рамки стабильности, перекладывается на потребителя: заявки, согласования, расчёты партиций, реплик и брокеров. Формально система работает, фактически — охраняется вход в кластер.
В продуктовой логике платформа существует для того, чтобы ею пользовались. Здесь фокус смещается с инфраструктуры на устранение трения: насколько быстро команда может начать интеграцию, сколько шагов нужно пройти до первого результата, сколько ручных решений переложено на автоматизацию, и какую бизнес-ценность платформа реально создаёт.
Разница между этими подходами хорошо видна в метриках.
Для сервисной модели ключевая метрика — стабильность.
Для продуктовой — скорость и простота использования.
Например, вместо абстрактного «Kafka работает» появляется вполне конкретная продуктовая метрика: Time to First Message — сколько времени проходит от запроса команды до первой записи в топик. Если это минуты — у вас продукт. Если дни или недели — у вас сервис с бюрократической обвязкой.
Если упростить, различие выглядит так:
Сервисная платформа
- — метрика успеха: аптайм
- — пользователь: источник риска
- — главный артефакт: заявка
Продуктовая платформа
- — метрика успеха: time-to-market
- — пользователь: клиент
- — главный артефакт: быстрый результат
И вот здесь появляется неудобная, но важная мысль. Продуктовый подход логически ведёт к конкуренции. Не обязательно в формате «два одинаковых отдела», а хотя бы как выбор между внутренним решением и внешним облачным сервисом. В этот момент платформа перестаёт быть обязательной и начинает доказывать свою ценность качеством сервиса.
Да, для Enterprise это звучит почти крамольно. Но именно так появляются удобство, скорость и инновации — не из регламентов, а из необходимости быть выбранным.
Если хочется совсем приземлить эту мысль, вот простой вопрос для самопроверки, который можно задать платформенной команде уже завтра:
Какой процент запросов на использование платформы проходит автоматически, без ручного согласования и архитектурных решений со стороны потребителя?
Ответ на этот вопрос очень быстро показывает, вы строите продукт или просто охраняете вход в кластер.
Дискуссия