👀Как стать гением архитектуры👀

Продолжаю делиться впечатлениями о клубе проектирования NextWay.

Поскольку школа NextWay ориентируется на аналитиков, большинство участников - аналитики. И мы оказались немного "подставлены" нашей проф. деформацией, в сравнении с тем как проходят такие секции архитекторы.

😱Выяснение требований: ФТ и НФТ

Первыми этапами стали сбор функциональных (ФТ) и нефункциональных требований (НФТ). Привычная задача для аналитиков. Мы с энтузиазмом бросились собирать информацию: задали кучу вопросов, узнали массу деталей. Но сколько из этого мы реально использовали? В лучшем случае, процентов 15.

🤔Провал с НФТ

Лично для меня этап с НФТ стал провалом. Я часто говорю своим менти, что одна из главных проблем аналитиков — это сбор НФТ "по-детски". То есть: спросили, записали и забыли, даже не пытаясь понять, зачем эти требования нужны.

В этот раз произошло то же самое. Все НФТ собрали, но использовала их только одна команда, да и то — минимально. Вспоминаю, как архитекторы на других мероприятиях, задавая меньше вопросов, использовали НФТ для расчетов, вплоть стоимости разработки и учёта в архитектуре. Это важный навык, которому аналитикам стоит учиться.

😁Проблемы внутри команд

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

Много времени в моей команде потратили на обсуждение сервисов аутентификации, BFF и API Gateway. Обсуждения почти дошли до конфликтов, пока на схеме не появился заветный прямоугольник. Иронично, что эти компоненты для решаемого кейса были вовсе не важны. В результате на обсуждение критически важных систем времени просто не оставалось.

🙈Моя грустная реальность

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

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

❔Как хакнуть архитектуру❔

1️⃣Не забывать, что это учебный кейс.

Не нужно выяснять все требования до мельчайших деталей. В подобных задачах почти всегда есть конечный набор вопросов по ФТ и НФТ, который стоит задавать. После 5–10 практик я, возможно, смогу поделиться этим списком.

2️⃣Избегать конфликтов в команде.

Если в вашей команде есть конфликтные люди, которые тянут обсуждение на себя, попроситесь в другую группу.

3️⃣ Не тратить время на второстепенные сервисы.

Компоненты вроде аутентификации и API Gateway часто вторичны. Чтобы избежать "стопора", можно сразу нарисовать эти блоки на схеме и больше к ним не возвращаться.

4️⃣ Провокационные ответы ради обратной связи.

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

5️⃣ Работай на знакомом уровне абстракции.

Если не знаете деталей многих решений, сосредоточьтесь на общем: интерфейс, бэкенд, кэш, БД. Главное — фокусироваться на системах, критичных для решения кейса.

6️⃣ Архитектура любит поцелуи
"KISS" (Keep It Simple, Stupid). Если систему можно не добавлять — не добавляйте. А если не понимаете, зачем она нужна, лучше не включайте её в архитектуру.

7️⃣ Освой базовые знания.
Минимальный набор: знание нотации C4 (до третьего уровня) и понимание технологий первого выбора.

8️⃣ Рефлексируй после практики.

Перерисуй эталонную архитектуру. Сформулируй вопросы к ней. Разбери неизвестные элементы. Подумайте, как можно улучшить решение.

⚡️Заключение⚡️

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

#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем