Многие путают проектирование (дизайн) с архитектурой

Если у вас четко определены требования и поставлена задача - вы проектируете решение
Если же вы оценив риски самостоятельно ставите задачи исходя из контекста - вы занимаетесь архитектурой

В общем накидав API микросервису ты еще не стал архитектором

Когда-то программисты делились на инженеров и техников.
Инженер знает как поведет себя система до написания кода.
Техник узнает об этом от тестировщиков.

И да. Сейчас не делятся

Котлин конечно хорош. Очень хорош.
Но статические анализаторы кода (по той же безопасности) прощают ему многое.

Выбирай, но осторожно

Теорема Томаса гласит: «Если люди определяют ситуации как реальные, они реальны по своим последствиям».
Архитектор формирует новую реальность

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

Признаки того, что конструктивный диалог превратился в спор:
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 при уходе от печатных форм документации сводить все в один документ - не имеет смысла

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

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

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

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

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