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

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

Конструктивный диалог требует трех условий
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

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

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

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

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

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

MindMap по методам принятия арх. решений

(Планировалось обсуждение в сообществе архитекторов IT_One)

ТРАЗ: Решение нетиповых задач

Нетиповые задачи - задачи по которым отсутствуют/неизвестны готовые рабочие концепты (стили, эталоны, паттерны, тактики и т.п.)

Решение этих задач требуется изобрести.

Изобретение это не обязательно интуиция, оно может быть проведено по алгоритму (см ТРИЗ)

Этапы работы
1. Определение противоречия
2. Разрешение противоречия
Варианты (в последовательности):
1. Снятие противоречия
2. Разрешение во времени
3. Разрешение в пространстве
4. Разрешение в структуре
5. Разрешение по взаимодействиям
6. Разрешение в отношении

#Software_Architecture
#TRIZ
#ТРАЗ

ТРАЗ: Определение противоречия

Противоречие возникает когда к одному объекту предъявляются несовместимые требования.

Для фиксации противоречия надо определить его как два утверждения одно из которых противоположно другому

Формат
Предмет должен A для a1 и должен не A для a2
где А это некоторое утверждение, a1 и a2 - некоторые цели

Пример

Проблема:
Требуется периодическое архивирование данных при этом система в процессе архивирования не справляется с нагрузкой, и время отклика становится неприемлемым.

Неправильно формулируемое противоречие:
Система должна выдавать ответ не дольше чем за 1 сек и должна производится архивация данных

Правильная форма:
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.

#ТРАЗ

ТРАЗ: Снятие противоречия

Снятие противоречия возможно при сопоставлении утверждения и его цели.
Возможны варианты:
1. утверждение не связано с целью
1. возможно что озвученная цель скрывает реальную (корысть)
2. возможно заблуждение (например - используем микросервисы для упрощения процесса разработки)
2. утверждение не единственный способ реализации озвученной цели
необходимо рассмотрение и сравнение всех вариантов

Пример
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.

Обеспечить надежность (по метрике RPO) можно не только архивированием.
Переход на Event Source позволяет произвести откат на любое состояние.
При этом архитектура Event Source более производительна при записи.

#ТРАЗ