Архитектура для не-технарей: как говорить с бизнесом на одном языке

Техническое совершенство ≠ бизнес-понимание

На картинке выше вы видите типичную ситуацию: архитектор показывает финансовому директору и CEO диаграмму, усыпанную стрелками, взаимосвязями и умными словами вроде Kafka, SOA и ESB. Архитектура может быть на самом деле идеальной, масштабируемой и надежной. Но эта архитектура должна как-то помогать бизнесу в целом, поэтому со стороны бизнеса сразу возникают вопросы: и это дешевле? Сколько сэкономит в этом квартале?

Здесь мы сталкиваемся с фундаментальной проблемой, которую, например, пытается решить Domain Driven Design: техническое совершенство не равно бизнес-пониманию. Технически совершенная архитектура в примере выше существует в технических терминах, но не в терминах бизнес-контекста. Это как показывать карту метро тому, кто спрашивает, как дойти до булочной.

И это, кстати, еще один веский аргумент в пользу того, чтобы глубоко изучить Domain Driven Design (например, в рамках нашего интенсива Стратегические паттерны Domain Driven Design). Этот подход позволяет принципиально иначе взглянуть на архитектуру систем — вплоть до организации коммуникации между людьми. 

Искусство говорить на языке бизнеса

В любой книге архитектора вы найдете прекрасный инструмент — понятия point of view (точка зрения на проблему) и view (способ представления информации, чтобы ваша позиция была услышана и воспринята). Очевидно, что в контексте финансового директора определены не Kafka, SOA и ESB, а такие термины как стоимость, возврат на инвестиции, финансовые риски. Поэтому для того, чтобы обосновать свою точку зрения, нужно другое представление.

Почти все известные рекомендации, которые помогают усилить позицию, сводятся к одному: между контекстом архитектора и условного финансиста должен быть адаптер (Anti-Corruption Layer в терминах DDD) — переводчик, который переведет с языка технического совершенства на язык выгод. Дальше в статье мы разберем конкретные приемы, которые помогут превратить технические характеристики в понятные бизнесу ценности. 

Сила метафор: когда сложное становится простым

Один из самых мощных инструментов в арсенале архитектора — это метафоры.  Они хорошо работают, когда слушатели не знают ваш контекст, а вы не знаете контекст слушателей. На самом деле мы постоянно пользуемся метафорами, даже не замечая этого. Возьмем для примера сам термин «архитектура» — это ведь метафора, которую мы используем, чтобы описать нашу работу по проектированию систем (насколько точно, – это уже другой вопрос). То же самое с «облачными вычислениями» — это ведь тоже метафорическое выражение, как и «песочница», где мы тестируем и отрабатываем решения.

Вот еще несколько полезных примеров:

Метафора	Что объясняет	Как это звучит для бизнеса
Городская инфраструктура, где здания – аналог сервисов, а дороги – каналов коммуникации	Структуру и взаимодействие систем	«Мы строим квартал с четкой дорожной сетью, чтобы транспорт (данные) добирался без пробок»
Промышленный конвейер, где продукция – это аналог данных, а палеты – аналог очередей	Поток и узкие места	«Устраним бутылочное горлышко, как на производственной линии»
Электрическая сеть, где приборы – аналог микросервисов, а щиток – упрощенный аналог service mesh	Управляемость и отказоустойчивость	«Если прибор выйдет из строя, сеть мгновенно переключится на резерв»

 Но есть и вредные метафоры, которые не объясняют ничего.

• Швейцарский нож — такая метафора создает впечатление, что система способна на всё, но при этом не объясняет ее конкретные преимущества. 
• Сложные биологические аналогии (мозг, нервная система, иммунная система) — эти понятия сами требуют пояснений, а хорошая метафора должна опираться на простые и ясные образы. 
• Технические аналогии типа «это как DNS, но для сервисов» — бесполезны для тех, кто не знает, что такое DNS.

Визуализация, которая работает

Хорошим решением будет визуализация архитектуры на диаграмме. Однако и здесь нужно не забывать о ряде правил, чтобы диаграммы были понятными и полезными.

Контекстная диаграмма должна содержать:

• один центральный блок — это ваша система,
• внешние элементы — пользователи и другие системы, с которыми взаимодействует ваша система,
• стрелки с подписями — показывают бизнес-действия («покупает товар», «запрашивает отчет»).

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

Кроме того, отлично работают диаграммы «до» и «после». На «до» мы показываем проблемы (медленно, ненадежно, дорого), на «после» — порядок, отмечая зелеными галочками улучшения. Часто забывают показать «до», а сразу начинают с целевой архитектуры. Но защищать нужно именно изменения между текущим и целевым состоянием и визуализировать ценность изменений.

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

Основная цель такой диаграммы — не демонстрация технических деталей реализации, а визуализация бизнес-ценности и преимуществ.

 

Почему проваливаются презентации архитекторов

Анализируя неудачные презентации, можно выделить четыре основные причины провала.

Языковой барьер — это первая и главная проблема. Контексты разные, и архитектор зачастую должен выступать переводчиком между множеством различных контекстов. 

2. Перегрузка деталями — вторая распространенная ошибка. Часто это происходит из-за желания показать свой профессионализм: «Смотрите, как много умных слов я знаю и как много умею». Многие через это проходят, но со временем понимаешь, что профессионализм подтверждается реализацией сложных проектов, а не количеством сложных терминов на картинке.

3. Отсутствие понятной «истории ценности» — третья проблема. Когда есть просто архитектура ради архитектуры, на вопросах «сколько это будет стоить?» и «сколько еще людей нам надо нанять» можно посыпаться. Далее в статье расскажу, как с помощью концепции WIIFM донести ценность архитектуры на языке выгод, рисков и затрат.

4. Неподходящие визуализации. Лучше использовать простые картинки и что-то дополнить голосом, чем показывать перегруженные диаграммы, которые ни о чем не говорят бизнесу.

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

WIIFM: Что я с этого получу?

Архитекторы часто говорят о производительности, безопасности и масштабируемости. Но бизнес хочет слышать о выгодах, рисках, деньгах, времени и конкуренции. Именно здесь на помощь приходит концепция WIIFM (What’s In It For Me?) — она помогает сформулировать ценность предложения на языке бизнеса. 

Начинайте с вопроса «Почему?»: почему это важно для бизнеса прямо сейчас? Как решение закрывает конкретную боль или открывает новую возможность?

Сравните, как меняется восприятие при переводе на язык бизнеса:

• Вместо «масштабируемость» — «выдержим рост трафика в 10 раз без потерь продаж».
• Вместо «отказоустойчивость» — «не потеряем $X при сбое».
• Вместо «современный стек» — «привлечем топ-разработчиков, сократим сроки разработки на 30%».
• Вместо «безопасность» — «избежим штрафов $$$ и потери репутации из-за утечек».

Теперь вернемся к нашему примеру на картинке, где архитектор защищает проект перед финансовым директором и CEO, и поможем ему ответить на вопросы.

На вопрос «Сколько это стоит?»

❌ перечислить затраты на железо и лицензии («$500K за серверы и ПО»).

✅ сделать акцент на инвестициях, экономии и окупаемости.

Пример: «Общие инвестиции составят $X. Это позволит ежегодно экономить $Y на операционных расходах и генерировать дополнительный доход $Z за счет [конкретная причина]. Окупаемость — N месяцев/лет».

На вопрос «Почему не сделать дешевле?»

❌ использовать технические аргументы («ненадежно» или «не масштабируется»).

✅ объяснить через бизнес-риски и долгосрочные последствия.

Пример: «Упрощенное решение не решит проблему X, которую мы обсуждали, и может привести к рискам Y (например, простои) и дополнительным затратам Z в будущем. Наше предложение оптимально по балансу стоимости, рисков и долгосрочных эффектов».

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

• CEO интересует стратегия, деньги, конкуренты — минимум деталей, максимум выгод и рисков.
• Продажи и маркетинг хотят знать о влиянии на клиентов, скорости вывода фич и конкурентных преимуществах.
• Финансы думают категориями ROI, TCO, экономии и бюджета.

Структура успешной презентации

При планировании презентации архитектурного решения следуйте примерно такой структуре:

1. Почему это важно сейчас? — бизнес-боль или возможность
2. Как выглядит боль сегодня? — ситуация до решения проблемы
3. Что мы предлагаем? — одна ключевая идея архитектуры
4. Как это работает? — очень высокоуровнево, с метафорой и ключевым потоком событий
5. Преимущества на языке выгод — что это даст (деньги, время, риск)
6. Как выглядит победа? — что мы получим в результате
7. Что нужно от стейкхолдеров? — бюджет, ресурсы, решения
8. Дорожная карта — ключевые этапы и сроки (высокоуровнево)
9. Риски и как мы с ними справимся — честно, но с готовыми решениями
10. Резюме и дальнейшие шаги

В конечном итоге, ответственность за донесение смысла лежит на архитекторе. Вместо того чтобы считать слушателей недостаточно компетентными, сосредоточьтесь на том, как донести мысль яснее. 

Умение говорить на языке бизнеса, трансформировать технические детали в понятные выгоды — не дополнительный навык, а ключевая компетенция современного архитектора. Именно от этого зависит успех проектов, выделение бюджетов и карьерный рост.
 
Если вы хотите глубже разобраться в этих вопросах, приглашаю в школу Архитектора ПО. Это курс, где мы системно разбираем всю архитектурную деятельность: от анализа бизнес-контекста и проектирования до интеграции архитектуры в процессы разработки. Вы освоите как фундаментальные принципы, так и современные практики — от эволюционной архитектуры до работы с AI в проектировании.