Архитектор хренов

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

Что такое «архитектор хренов»: происхождение термина и суть феномена

Термин «архитектор хренов» возник в русскоязычной IT-среде как жёсткий, но меткий сленг. Он не имеет официального определения, но его смысл понятен каждому, кто работал в проектах с перегруженной, избыточной архитектурой. Это не человек, который плохо знает технологии — напротив, он часто отлично разбирается в них. Проблема в другом: он создаёт решения, которые не нужны, не понятны, не поддерживаются и не оправдывают затраты. Архитектор хренов — это тот, кто строит «дворец из картона»: с фасадом из микросервисов, кластеров Kubernetes, Kafka-топиков и GraphQL-схем, но внутри — пустота, дублирование, ненужная сложность и отсутствие связи с бизнес-целями.

Представьте: заказчик хочет простой API для получения данных о клиентах. Архитектор же предлагает 12 микросервисов, 3 брокера сообщений, 2 кэша, 4 уровня кеширования, собственную систему аутентификации на базе OAuth2 + JWT + OpenID Connect + SAML, и всё это — на Kubernetes с автоматическим масштабированием по 7 метрикам. Всё технически безупречно. Но зачем? Система обслуживается 5 разработчиками, её запуск занимает 15 минут, а обновление — 4 часа. Клиенты не чувствуют разницы. Бизнес теряет деньги. И всё потому, что архитектура стала символом «умности», а не инструментом эффективности.

Почему «архитекторы хренов» появляются: 5 основных причин

Причины возникновения такого типа архитектур — не в лени или глупости, а в системных сбоях в процессах принятия решений.

1. Давление со стороны заказчика или менеджмента

Заказчики часто хотят «современного» решения — «как у Google» или «на микросервисах». Архитектор, чтобы не выглядеть «устаревшим», соглашается, даже если система не требует такой сложности. Это особенно актуально в госзакупках и крупных корпорациях, где важна «демонстрация технологий», а не результат.

2. Недостаток бизнес-понимания

Архитектор, не понимающий целей бизнеса, не может оценить, какие функции действительно критичны. Он проектирует «на будущее» — но будущее, которого не будет. Система, рассчитанная на 10 млн пользователей, запускается с 500.

3. Эго и стремление к «технической красоте»

Некоторые архитекторы воспринимают архитектуру как произведение искусства. Они выбирают технологии не по эффективности, а по «интересности»: Rust вместо Java, GraphQL вместо REST, Event Sourcing вместо простого обновления таблиц. Это как строить дом из мрамора, когда нужен сарай.

4. Отсутствие обратной связи с пользователями

Если архитектор не общается с конечными пользователями, он не знает, что их реально беспокоит. Он проектирует «идеальную» систему, которая работает, но не решает их задачи.

5. Неправильная система KPI

Если архитектора оценивают по количеству использованных технологий, а не по времени простоя, скорости релизов или удовлетворённости команды — он будет создавать «хреновую» архитектуру. Это не его вина — это система.

Как распознать архитектуру «хренова»: 7 явных признаков

Не всегда легко понять, что перед вами «архитектура хренов». Вот ключевые сигналы, которые нельзя игнорировать:

• Слишком много уровней абстракции — каждый компонент имеет 3-4 слоя интерфейсов, а простая операция требует 7 вызовов между сервисами.
• Использование технологий, которые не нужны — Kafka для обмена сообщениями между двумя сервисами, которые работают в одном процессе.
• Отсутствие документации о бизнес-логике — есть схемы UML, но нет описания, зачем нужна эта система и как она влияет на доходы.
• Долгий цикл развертывания — релиз занимает 2 дня, потому что нужно перезапустить 15 сервисов и проверить 8 зависимостей.
• Высокая стоимость поддержки — на поддержку одного микросервиса тратят больше, чем на его разработку.
• Команда боится вносить изменения — «это работает, но если что-то тронешь — всё упадёт».
• Пользователи не замечают разницы — система работает, но никто не говорит: «О, теперь всё быстрее/удобнее!»

Реальные кейсы: когда архитектура убила продукт

В 2022 году одна из российских банковских IT-компаний разработала систему обработки заявок на кредиты. Архитектор решил использовать Event Sourcing, CQRS, Kafka, Redis, PostgreSQL, Elasticsearch и 7 микросервисов. Всё по «лучшим практикам». Результат: время обработки заявки — 8 минут. Конкуренты — 12 секунд. Клиенты уходили. Проект закрыли через 9 месяцев. Затраты — 12 млн рублей. Прибыль — ноль.

Другой случай: стартап, который хотел «взломать» рынок CRM. Архитектор выбрал GraphQL + WebSockets + serverless + DDD + полная изоляция по доменам. Через 6 месяцев команда из 8 человек не могла выпустить даже минимальный релиз. Все были заняты поддержкой архитектуры, а не продуктом. Компания обанкротилась.

Представьте: вы покупаете автомобиль, который ездит на 10 топливных систем, 5 бортовых компьютеров и 3 GPS-навигатора. Он красив, технологичен, но за рулём сидит водитель, который не знает, как включить свет. Это — архитектура хренов.

Как избежать стать «архитектором хренов»: практические шаги

Превратить себя из «архитектора хренов» в архитектора-решателя можно. Это не вопрос таланта — это вопрос дисциплины.

1. Начинайте с вопроса «Зачем?» — перед каждой технологией спрашивайте: «Какой бизнес-результат она даст?» Если ответ — «мы так делаем, потому что это модно» — откажитесь.
2. Используйте правило YAGNI (You Ain’t Gonna Need It) — не добавляйте функционал, который не нужен сегодня. Даже если «вдруг понадобится завтра».
3. Проводите архитектурные ревью с бизнесом — не только с разработчиками. Покажите диаграмму и спросите: «Как это помогает клиенту?»
4. Измеряйте не сложность, а результат — KPI: время выхода в продакшн, количество инцидентов, удовлетворённость команды, рост конверсии.
5. Упрощайте перед тем, как усложнять — попробуйте реализовать функцию на одном сервере, без микросервисов. Если работает — не усложняйте.
6. Слушайте команду — если разработчики говорят: «Это невозможно поддерживать» — они правы. Не игнорируйте их.
7. Пишите архитектурные решения как бизнес-документы — не как технические инструкции. Объясните, почему выбрано именно это, и как это влияет на доходы.

Экспертное мнение: как держать архитектуру на земле

Он добавляет: «Самая большая ошибка — думать, что сложность = надёжность. Нет. Надёжность — это простота, которая работает. А сложность — это риск. Каждый новый компонент — это новая точка отказа. Каждый новый фреймворк — это новый навык, который нужно учить. И всё это — деньги, время, стресс.»

Часто задаваемые вопросы

Заключение

Архитектура — это не про технологии. Это про ответственность. Ответственность перед пользователями, командой, бизнесом и будущим. «Архитектор хренов» — это не враг, а симптом. Симптом того, что в организации потеряна связь между техникой и целью. Он появляется там, где ценят «выглядит круто», а не «работает эффективно». Исправить это можно — но только если вы готовы задавать неудобные вопросы, отстаивать простоту и помнить: лучшая архитектура — та, которую никто не замечает, потому что она просто работает.

• Архитектура должна решать реальные проблемы, а не демонстрировать технологии.
• Самая опасная архитектура — та, что «работает», но не приносит ценности.
• Простота — не признак слабости, а признак зрелости и контроля.
• Всегда спрашивайте: «Зачем?» перед тем, как добавить новый компонент.
• Успех архитектора измеряется не по количеству сервисов, а по скорости, надёжности и удовлетворённости команды.