ТРИЗ в архитектуре
ТРИЗ - теория интересная, но к решению архитектурных задач приспособлена слабо. Можно надергать полезные элементы, но в целом система не работает.
Прежде всего потому, что архитектурные системы живут в динамике, постоянно достраиваются, развиваются.
Представьте себе инженера, который на ходу пристегивает к паровозу пару дополнительных колес и крылья.
В общем нужна ТРАЗ
#ТРАЗ
#TRIZ
#Software_Architecture
ТРИЗ - теория интересная, но к решению архитектурных задач приспособлена слабо. Можно надергать полезные элементы, но в целом система не работает.
Прежде всего потому, что архитектурные системы живут в динамике, постоянно достраиваются, развиваются.
Представьте себе инженера, который на ходу пристегивает к паровозу пару дополнительных колес и крылья.
В общем нужна ТРАЗ
#ТРАЗ
#TRIZ
#Software_Architecture
Чья-то правильная мысль
"компромисс всегда обходится дороже, чем любая из альтернатив"
"компромисс всегда обходится дороже, чем любая из альтернатив"
😁1
Активности архитектора.pdf
345.8 KB
Активности разных типов архитекторов и в зависимости от процесса
Успешный стартапер
имеет привычку покидать проект перед выходом в прод.
Основной девиз "При мне все было хорошо и вовремя. После меня все сломали"
имеет привычку покидать проект перед выходом в прод.
Основной девиз "При мне все было хорошо и вовремя. После меня все сломали"
😁1
Время принятия архитектурного решения
У Форда в эволюционной архитектуре:
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: 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 "Навязывание" новой реальности начинается с языка.
Как архитектор формирует реальность
Архитектор формирует "ментальное поле" проекта.
Для этого прежде всего выбирается язык на котором будут говорить стейкхолдеры.
Это может быть язык поддерживаемый комьюнити (стиль) или собственный уникальный общеупотребительный язык (UL в DDD).
IMHO "Навязывание" новой реальности начинается с языка.
Прямоугольники и стрелочки
Классификация архитекторов #softwarearchitect #antipattern
The well-rounded architect Presentation 1.pdf
9.2 MB
В ту же тему с конференции NYC O’Reilly Software Architecture Conf (Feb 2019)
Понятие Well-rounded architect
Понятие Well-rounded architect
Что делает архитектор если заказчик орет ?
Включаем режим "внимательно слушаю".
Если дошло до эмоций то скорее всего где-то здесь прячется бизнес цель / корысть. Важно зафиксировать.
Исключение - заказчик орет постоянно.
Чаще всего это способ манипуляции (через стыд / испуг).
В этом раскладе архитектор как взрослый и психологически устойчивый индивид работает в обычном режиме.
Включаем режим "внимательно слушаю".
Если дошло до эмоций то скорее всего где-то здесь прячется бизнес цель / корысть. Важно зафиксировать.
Исключение - заказчик орет постоянно.
Чаще всего это способ манипуляции (через стыд / испуг).
В этом раскладе архитектор как взрослый и психологически устойчивый индивид работает в обычном режиме.
Бизнес цель
- термин который мне никогда не нравился. Все время приходится его объяснять.
Из за недопонимания рождаются перлы вроде "Моя бизнес цель - убрать кэш адресов".
Насколько понятнее было если бы по-русски бизнес цель называлась корысть, или, например, гешефт (не по-русски)
- термин который мне никогда не нравился. Все время приходится его объяснять.
Из за недопонимания рождаются перлы вроде "Моя бизнес цель - убрать кэш адресов".
Насколько понятнее было если бы по-русски бизнес цель называлась корысть, или, например, гешефт (не по-русски)
😁1
image_2022-03-09_11-56-51.png
114.1 KB
MindMap по методам принятия арх. решений
(Планировалось обсуждение в сообществе архитекторов IT_One)
(Планировалось обсуждение в сообществе архитекторов IT_One)
ТРАЗ: Решение нетиповых задач
Нетиповые задачи - задачи по которым отсутствуют/неизвестны готовые рабочие концепты (стили, эталоны, паттерны, тактики и т.п.)
Решение этих задач требуется изобрести.
Изобретение это не обязательно интуиция, оно может быть проведено по алгоритму (см ТРИЗ)
Этапы работы
1. Определение противоречия
2. Разрешение противоречия
Варианты (в последовательности):
1. Снятие противоречия
2. Разрешение во времени
3. Разрешение в пространстве
4. Разрешение в структуре
5. Разрешение по взаимодействиям
6. Разрешение в отношении
#Software_Architecture
#TRIZ
#ТРАЗ
Нетиповые задачи - задачи по которым отсутствуют/неизвестны готовые рабочие концепты (стили, эталоны, паттерны, тактики и т.п.)
Решение этих задач требуется изобрести.
Изобретение это не обязательно интуиция, оно может быть проведено по алгоритму (см ТРИЗ)
Этапы работы
1. Определение противоречия
2. Разрешение противоречия
Варианты (в последовательности):
1. Снятие противоречия
2. Разрешение во времени
3. Разрешение в пространстве
4. Разрешение в структуре
5. Разрешение по взаимодействиям
6. Разрешение в отношении
#Software_Architecture
#TRIZ
#ТРАЗ
ТРАЗ: Определение противоречия
Противоречие возникает когда к одному объекту предъявляются несовместимые требования.
Для фиксации противоречия надо определить его как два утверждения одно из которых противоположно другому
Формат
Предмет должен A для a1 и должен не A для a2
где А это некоторое утверждение, a1 и a2 - некоторые цели
Пример
Проблема:
Требуется периодическое архивирование данных при этом система в процессе архивирования не справляется с нагрузкой, и время отклика становится неприемлемым.
Неправильно формулируемое противоречие:
Система должна выдавать ответ не дольше чем за 1 сек и должна производится архивация данных
Правильная форма:
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
#ТРАЗ
Противоречие возникает когда к одному объекту предъявляются несовместимые требования.
Для фиксации противоречия надо определить его как два утверждения одно из которых противоположно другому
Формат
Предмет должен A для a1 и должен не A для a2
где А это некоторое утверждение, a1 и a2 - некоторые цели
Пример
Проблема:
Требуется периодическое архивирование данных при этом система в процессе архивирования не справляется с нагрузкой, и время отклика становится неприемлемым.
Неправильно формулируемое противоречие:
Система должна выдавать ответ не дольше чем за 1 сек и должна производится архивация данных
Правильная форма:
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
#ТРАЗ
ТРАЗ: Снятие противоречия
Снятие противоречия возможно при сопоставлении утверждения и его цели.
Возможны варианты:
1. утверждение не связано с целью
1. возможно что озвученная цель скрывает реальную (корысть)
2. возможно заблуждение (например - используем микросервисы для упрощения процесса разработки)
2. утверждение не единственный способ реализации озвученной цели
необходимо рассмотрение и сравнение всех вариантов
Пример
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Обеспечить надежность (по метрике RPO) можно не только архивированием.
Переход на Event Source позволяет произвести откат на любое состояние.
При этом архитектура Event Source более производительна при записи.
#ТРАЗ
Снятие противоречия возможно при сопоставлении утверждения и его цели.
Возможны варианты:
1. утверждение не связано с целью
1. возможно что озвученная цель скрывает реальную (корысть)
2. возможно заблуждение (например - используем микросервисы для упрощения процесса разработки)
2. утверждение не единственный способ реализации озвученной цели
необходимо рассмотрение и сравнение всех вариантов
Пример
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Обеспечить надежность (по метрике RPO) можно не только архивированием.
Переход на Event Source позволяет произвести откат на любое состояние.
При этом архитектура Event Source более производительна при записи.
#ТРАЗ
🔥1
ТРАЗ: Идеальный объект
Объект идеален, если его нет, а функция выполняется.
Пример 1
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Переход на Event Source позволяет произвести откат на любое состояние. Архив - идеальный объект. Его больше нет, но его функции выполняются.
Пример 2
Некоторый шлюз перенаправляет запросы и возвращает ответы.
Обслуживается множество клиентов.
Шлюз держит таблицу маршрутизации ID запроса - ID клиента
Необходимо масштабировать шлюз.
Противоречие:
Шлюз должен иметь состояние чтобы маршрутизировать ответы.
Шлюз не должен иметь состояния для масштабирования.
Решение: пусть запрос и ответ содержат ID клиента.
Таблица маршрутизации - идеальный объект.
Общий подход перехода к идеальным объектам
Если при разборе противоречия определяем объект, который должен быть и не быть одновременно - пытаемся избавится от него, переносим его функции на уже имеющиеся объекты.
#ТРАЗ
#TRIZ
#идеальный_объект
Объект идеален, если его нет, а функция выполняется.
Пример 1
Данные должны архивироваться для обеспечения надежности и не должны архивироваться для обеспечения производительности.
Переход на Event Source позволяет произвести откат на любое состояние. Архив - идеальный объект. Его больше нет, но его функции выполняются.
Пример 2
Некоторый шлюз перенаправляет запросы и возвращает ответы.
Обслуживается множество клиентов.
Шлюз держит таблицу маршрутизации ID запроса - ID клиента
Необходимо масштабировать шлюз.
Противоречие:
Шлюз должен иметь состояние чтобы маршрутизировать ответы.
Шлюз не должен иметь состояния для масштабирования.
Решение: пусть запрос и ответ содержат ID клиента.
Таблица маршрутизации - идеальный объект.
Общий подход перехода к идеальным объектам
Если при разборе противоречия определяем объект, который должен быть и не быть одновременно - пытаемся избавится от него, переносим его функции на уже имеющиеся объекты.
#ТРАЗ
#TRIZ
#идеальный_объект
#ТРАЗ: Правильно сформулированная задача
При решении архитектурных задач часто используют понятие компромисс.
Безопасность или надежность противопоставляется производительности и предлагается найти решение используя более сложные паттерны.
В случае изобретения решения подобные противопоставления не эффективны.
Я не могу решить проблему "надежность против производительности".
Проблема должна быть сформулирована как противоречие.
Например:
Архив должен создаваться для обеспечения приемлемого RTO
Архив не должен создаваться для поддержания приемлемого времени отклика при записи.
Напрашивается решение рассматривать архив как #идеальный_объект, с выносом его функций на уже существующие объекты системы.
Адепты #ТРИЗ говорят, что не существует правильно сформулированных задач.
Правильно сформулированная задача - это уже решение.
При решении архитектурных задач часто используют понятие компромисс.
Безопасность или надежность противопоставляется производительности и предлагается найти решение используя более сложные паттерны.
В случае изобретения решения подобные противопоставления не эффективны.
Я не могу решить проблему "надежность против производительности".
Проблема должна быть сформулирована как противоречие.
Например:
Архив должен создаваться для обеспечения приемлемого RTO
Архив не должен создаваться для поддержания приемлемого времени отклика при записи.
Напрашивается решение рассматривать архив как #идеальный_объект, с выносом его функций на уже существующие объекты системы.
Адепты #ТРИЗ говорят, что не существует правильно сформулированных задач.
Правильно сформулированная задача - это уже решение.
#ТРАЗ: Решение задачи переходом на другие уровни
Идеальный объект - не единственный способ снятия противоречия.
Можно решать задачу выводя ее на другие уровни. Для архитектуры ПО это будут уровни инфраструктуры, системы, аппаратного обеспечения и т. п.
Например:
Мы должны передавать данные пакетами (batch) для обеспечения приемлемой пропускной способности.
Мы не должны передавать данные пакетами для обеспечения приемлемой задержки (latency)
Задаем вопрос, почему пропускная способность снижается при передаче одиночных сообщений.
Ответ - накладные расходы. При передаче сообщения дополнительно передаются метаданные в заголовках сообщений. И их процент в общем потоке тем выше чем меньше объем передаваемых данных.
Переформулируем противоречие на другом уровне.
Мы должны передавать метаданные с каждым сообщением для решения транспортных задач.
Мы не должны передавать метаданные с каждым сообщением для обеспечения приемлемых пропускной способности и задержки.
Можем ли мы отказаться от заголовков сообщений ?
Вопрос может решаться на системном и даже на аппаратном уровне.
Идеальный объект - не единственный способ снятия противоречия.
Можно решать задачу выводя ее на другие уровни. Для архитектуры ПО это будут уровни инфраструктуры, системы, аппаратного обеспечения и т. п.
Например:
Мы должны передавать данные пакетами (batch) для обеспечения приемлемой пропускной способности.
Мы не должны передавать данные пакетами для обеспечения приемлемой задержки (latency)
Задаем вопрос, почему пропускная способность снижается при передаче одиночных сообщений.
Ответ - накладные расходы. При передаче сообщения дополнительно передаются метаданные в заголовках сообщений. И их процент в общем потоке тем выше чем меньше объем передаваемых данных.
Переформулируем противоречие на другом уровне.
Мы должны передавать метаданные с каждым сообщением для решения транспортных задач.
Мы не должны передавать метаданные с каждым сообщением для обеспечения приемлемых пропускной способности и задержки.
Можем ли мы отказаться от заголовков сообщений ?
Вопрос может решаться на системном и даже на аппаратном уровне.