IMHO (v2)

Иллюстрация вышесказанного

Документирование процесса

1. На этапе оценки рисков - Architectural Decision Records (ADR)
Здесь варианты (возможно) и обоснования решения
2. На этапе согласования - Request for Comments (RFC)
Здесь согласуемая версия и комментарии стейкхолдеров

Мы у себя разводим эти документы - что бы
1. не загружать стейкхолдеров избыточной информацией по процессу принятия решения
2. не потерять обоснования принятия решения

Документирование результата

Кроме документов сопровождающих процесс нужны документы фиксирующие результат -
так называемое "описание архитектуры" (Architectural Denoscription, AD)
Это по стандарту большая портянка содержащая информацию для различных стейкхолдеров по всем аспектам. (см. диаграмму)

В нашем проекте описание архитектуры фрагментировано. Состоит из следующих частей:
1. Актуальная архитектура
a. Набор согласованных RFC дополненная списком архитектурных gap
б. Представления сформированные по прямому запросу стейкхолдеров (компонентная модель, диаграмма развертывания, DFD и т.п.), под задачу.
2. Целевая архитектура. Вольное описание того как мы хотели бы видеть нашу систему. Незаменимый артефакт при работе с блокировками (locks) и формировании архитектурного беклога.

IMHO при уходе от печатных форм документации сводить все в один документ - не имеет смысла

Идеальная архитектура

Идеальная архитектура - артефакт близкий по смыслу целевой архитектуре.

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

Представление идеальной архитектуры позволяет определить проблемы в контексте (ограничения мешающие системе) и сформировать план давления на контекст.

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

Конструктивный диалог

Конструктивный диалог требует трех условий
1. Наличие самой проблемы (противоречие)
2. Возможность выйти на мета-уровень на котором противоречие устраняется
3. Отсутствие заинтересованности в одном из вариантов (корысти)

Конструктивно не решаются игры с нулевой суммой,
к которым относятся споры за власть (кто здесь главный) или за деньги (за чей счет банкет)

Менеджмент заточен на участие в спорах.
На это их затачивают обстоятельства и различные тьюторы.
Близко не подпускайте менеджера к решению технических задач.

Архитектор (хороший) ищет решение в мета-уровнях.
Плохой архитектор стучит кулаком по столу или устаивает налеты (чайка-менеджмент).
И здесь чаще всего вопрос власти или бизнеса (перехват чужих денег).
Если технический диалог переходит в спор ищем причину в корысти и работаем на другом уровне.
А еще лучше уступаем поле боя менеджерам. Они заточены на споры.

Microservice API Patterns
https://www.microservice-api-patterns.org/

ТРИЗ в архитектуре
ТРИЗ - теория интересная, но к решению архитектурных задач приспособлена слабо. Можно надергать полезные элементы, но в целом система не работает.
Прежде всего потому, что архитектурные системы живут в динамике, постоянно достраиваются, развиваются.
Представьте себе инженера, который на ходу пристегивает к паровозу пару дополнительных колес и крылья.
В общем нужна ТРАЗ

#ТРАЗ
#TRIZ
#Software_Architecture

Чья-то правильная мысль

"компромисс всегда обходится дороже, чем любая из альтернатив"

IMHO v.3
С изрядной долей педантизма

Активности разных типов архитекторов и в зависимости от процесса

Классификация архитекторов
#softwarearchitect #antipattern

Успешный стартапер
имеет привычку покидать проект перед выходом в прод.
Основной девиз "При мне все было хорошо и вовремя. После меня все сломали"

Время принятия архитектурного решения
У Форда в эволюционной архитектуре:
Last Responsible Moment: The time when decisions occur is a major differentiator between traditional and evolutionary architecture. In a traditional architecture, decisions about e.g. structure, technology stack and communication patterns are taken early, before writing code. In an evolutionary architecture, we wait for the last responsible moment before making decisions. Deciding when that moment occurs can be hard but this is where fitness functions can provide guidance. Decisions with a significant influence on the architecture or with an impact a critical success factor for the project should be made earlier.

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

Так может быть сразу разделить решения на проектные и архитектурные ?

Переформулирую Last Responsible Moment:

Значительное влияние на систему имеют архитектурные решения их нужно принимать ранее прочих.
Остальные (проектные) решения принимаются как можно более поздно.

В продолжении темы.
Как архитектор формирует реальность

Архитектор формирует "ментальное поле" проекта.
Для этого прежде всего выбирается язык на котором будут говорить стейкхолдеры.

Это может быть язык поддерживаемый комьюнити (стиль) или собственный уникальный общеупотребительный язык (UL в DDD).

IMHO "Навязывание" новой реальности начинается с языка.

В ту же тему с конференции NYC O’Reilly Software Architecture Conf (Feb 2019)

Понятие Well-rounded architect

Что делает архитектор если заказчик орет ?

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

Исключение - заказчик орет постоянно.
Чаще всего это способ манипуляции (через стыд / испуг).
В этом раскладе архитектор как взрослый и психологически устойчивый индивид работает в обычном режиме.

Бизнес цель
- термин который мне никогда не нравился. Все время приходится его объяснять.
Из за недопонимания рождаются перлы вроде "Моя бизнес цель - убрать кэш адресов".
Насколько понятнее было если бы по-русски бизнес цель называлась корысть, или, например, гешефт (не по-русски)

Сцилла и харибда - синдромы вахтера и самозванца