(кейс из менторской практики)
История от менти. Крупный Enterprise. Нужно подключить сервис к Kafka.
На входе — нормальная бизнес-задача. На выходе — аналитик, который внезапно должен:
- посчитать объёмы сообщений,
- определить количество топиков,
- выбрать число партиций,
- решить, сколько реплик и на каких брокерах,
- и аккуратно раскрасить заявку по цветам в Excel-шаблоне.
Да, буквально. Не метафора.
И вот здесь возникает простой вопрос: а чем тогда занимается Kafka-команда?
Платформа сбрасывает ответственность — аналитик её ловит
Формально всё выглядит прилично. Платформенная команда говорит: «Мы не можем просто так дать доступ. Вы же можете положить кластер».
И дальше происходит ключевой трюк.
Все архитектурные решения аккуратно перекладываются на потребителя:
- ты сам выбираешь партиции,
- сам определяешь репликацию,
- сам подписываешься под нагрузкой.
Если что-то пойдёт не так — виноват ты. Не платформа. Не кластер. Не архитектурный гайд. Аналитик, который “так указал в заявке”.
Это не про Kafka. Это про страх ответственности, замаскированный под процесс.
Аналитик как высокооплачиваемая секретарша с навыками Excel-дизайнера
В этой модели аналитик перестаёт быть аналитиком.
Он становится:
- переводчиком между командами,
- компенсатором организационных дыр,
- человеком, который берёт на себя решения без мандата и без рычагов влияния.
А теперь ключевая метафора.
Аналитик подписывается под количеством партиций, хотя его экспертиза заканчивается на логике домена и бизнес-процесса.
Это как если бы официант решал, при какой температуре повару жарить стейк, чтобы ресторан не сгорел.
Не потому что он эксперт. А потому что иначе заказ не примут.
Архитектура на костылях из аналитиков
Почему эта модель токсична:
- решения принимают те, кто за них не отвечает,
- ответственность размазана,
- платформа превращается в охранника входа,
- аналитик — в универсальную прокладку между процессами.
И внезапно в компании начинают считать, что знание параметров Kafka важнее понимания бизнес-процесса.
Хотя должно быть ровно наоборот.
И, кстати, именно здесь становится понятно, почему в Enterprise так много системных аналитиков.
Не из-за сложности систем. А из-за размытого ownership.
Финальный вопрос (не академический)
А вы кто в своей компании? • архитектор смыслов, • человек, который понимает бизнес-потоки, • и проектирует решения
или
бесплатное приложение к Jira-шаблону платформенной команды, которое ещё и аккуратно раскрашивает ячейки, чтобы заявка прошла дальше?
Вот здесь, кажется, и проходит настоящая граница роли аналитика.
Дискуссия