2021-05-20 10:00:43
Вчера зацепили в Scrum сообществе один из популярных мифов о бесполезности роли Solution Architect и коллективной архитектуре. Он заключается в том, что Solution Architect чисто надуманная роль и архитектура должна рождаться командой при правильных вводных и должной фасилитации. В качестве довода приводится известный пример архитектора, который только рисует диаграммы и отдаёт команде.
Я постараюсь объяснить почему это миф и почему роль Solution Architect жизненно необходима большинству продуктов. Исключение составляют очень простые продукты, стартапы на начальной фазе (далеко не все) и продукты с типовой архитектурой целого семейства решений. Ключом к пониманию проблематики является отличие архитектуры от дизайна. Под работой над архитектурой подразумеваются следующие активности:
- определить ключевые архитектурные характеристики;
- выбрать и детально описать архитектурные стили;
- описать первичную структура системы;
- принять и аргументировать важные архитектурные решения;
- написать руководства по дизайну системы (правила и принципы).
Если все это сделано, то остаются только дизайн решения в рамках реализации конкретной бизнес функциональности. Например, решить какие микросервисы будут затронуты, выбрать синхронный или асинхронный канал коммуникации, обеспечить масштабирование и отказоустойчивость нового сервиса. С такими задачами должна успешно справляться команда и задача Solution Architect сводится к менторству и коучингу.
Какие навыки нужны, чтобы успешно разрабатывать архитектуру системы:
- глубокое понимание домена и его особенностей;
- умение вытаскивать из представителей бизнеса не только требования, но и архитектурные характеристики;
- чувство баланса, так как не бывает идеальных решений;
- владение множеством архитектурных стилей и паттернов;
- умение структурировать и доносить свои идеи до представителей бизнеса и команд;
- широкий технологический кругозор...
Последний пункт один из ключевых, который отличает концептуально архитектора от разработчика. Ведь в жизни действует закон малинового варенья - чем шире размазываешь, тем тоньше получается слой. У разработчика цель уметь круто работать по специализации в своём стеке и смежных, у архитектора же цель - иметь технологический кругозор как можно шире (и чуть глубже в некоторых местах) для выбора наиболее подходящих решений. Невозможно одновременно развиваться и в ширину и в глубину. Остальные навыки нарабатываются со временем и опытом.
Какие проявления отсутствия адекватного Solution Architect обычно можно встретить на практике:
- архитектурные характеристики (aka quality attributes) не определены и не влияют на реализацию фичей;
- система не масштабируется под рост нагрузки и не обеспечивает нужной доступности;
- систему тяжело дорабатывать, постоянно тратится много времени и вылазят проблемы;
- все дизайн решения принимаются точечно на усмотрение исполнителя;
- структура системы не соответствует потребностям бизнеса, приходится постоянно вставлять костыли;
- никто не может объяснить почему было сделано так как сделано...
Чаще всего, следующей ступенькой роста разработчика является роль Technical Lead. В этой роли он начинает развивать широту знаний и терять часть hands-on навыков. Нужно много чего изучать, читать, пробовать, экспериментировать... Это промежуточный этап развития в направлении Solution Architect.
Надеюсь, мне удалось вас убедить и кого-то даже заинтересовать новым направлением развития.
#архитектура
1.9K views07:00
X
