Архитектурные Сложности
Зачастую, не так сложно найти красивое целевое решение как подложить это решение вместо "исторически сложившегося" дерьма

Признаки того, что конструктивный диалог превратился в спор:
1. Нет ответов на прямые вопросы;
2. Обсуждение "выходит из колеи" и убегает по ассоциативным цепочкам;
3. Одна из сторон ставится в позицию оправдывающегося.

Вопреки распространённому мнению, в споре ничего путного не рождается.

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

"Кто строит по решению архитектора, тот кладет кирпичи на голову архитектора.
А строящий без архитектора - на свою". (Св.Филарет Московский)

Добавил возможность комментировать и флудилку

Методы принятия архитектурного решения

1. Интуиция
Минус – непредсказуемое качество решения

2. Выбор из вариантов (метод перебора)
Минус – низкая эффективность (высокая стоимость)
a. Морфологический метод (рассматриваем все мыслимые варианты)
Очень дорого
b. Мозговой штурм (Алекс Осборн, XIX в)
Два этапа: генерация идей, оценка идей
Проблема – потеря верного решения на этапе генерации. Хорошие цепочки рассуждений прерываются новыми идеями
c. Синектика (Уильям Гордон)
Генерация идей с построением критических цепочек.
Лучший из методов перебора, но работает только для «притертых команд»

3. Решение по алгоритму (зачем перебирать, когда можно сразу дать правильный ответ)
a. Типовые задачи решаются по шаблону
Сложные типовые задачи зачастую приводят к перебору шаблонов
b. Преодоление противоречий (около ТРИЗ)

см. https://www.ozon.ru/product/nayti-ideyu-vvedenie-v-triz-teoriyu-resheniya-izobretatelskih-zadach-nayti-ideyu-vvedenie-v-triz-34584363/?sh=fWb2VAAAAA

Оценка работы архитектора

Здесь решаем две разных задачи:

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

Каждой задаче - свои методы решения

https://www.youtube.com/watch?v=JPu-60iQC7U&t=2307s&ab_channel=IT_OneInnovation%26Technologies
Круглый стол по "баночкам"

Классика (по SEI)

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