Выступил сегодня на архитектурном митапе в ИТ-1.
Тема: методология принятия решения архитектором ПО

Представил своего Франкенштейна слепленного из разных методик

https://youtu.be/eBaPm4nPzkA?si=J0wgsgeubO1O_XEF

Запись с митапа

Контекст и метод

- Наблюдая эффективность чужой команды, многие пытаются перенять их МЕТОД
- Часто это заканчивается полной несуразицей (анти-паттерн карго культ)
- Забывается правило, что "Никакой метод работы не может быть перенесён из того конкретного проекта, в котором он был разработан, в другой проект" (см. situational method engineering)
- "Между ситуациями (контекстами) выживает не сам метод, как предзаданная последовательность операций, а только какие-то его части"
- В разных школах ситуационной инженерии методов эти части назывались компонентами/components, кусочками/chunks, ломтиками/slices
- То есть кроме описания метода должна быть предложена схема адаптации метода под ситуацию (контекст)
- Что опять таки требует наличия специалиста, погруженного в контекст - архитектора проекта.

Не знаю, есть ли методология адаптации чужих методов, но то что план адаптации не может быть универсальным - однозначно.

Отсюда еще одна ответственность архитектора - натягивать удачные процессы на известные предринятия. )

Определение архитектуры

Существует два популярных определения термина "архитектура":
1. "Архитектура — фундаментальная организация системы, состоящая из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы." (ISO 42010, TOGAF)
Или по простому ССС (Components + Connectors + Constraints)
2. Архитектура представляет значимые решения, где под словом «значимые» подразумевается то, что трудно изменить в дальнейшем. (Grady Booch и последователи Agile)

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

Во втором случае, утратив обоснования принятых решений - теряем архитектуру. Есть такое определение унаследованной системы:
"Унаследованная (legacy) система - это система архитектура которой утеряна".

А какое из определений ближе Вам ?

👇

Что такое архитектура (cont)

Выскажу свое мнение по вопросу☝.

Я согласен с большинством принявших участие в голосовании.
Считаю оба определения не полными.

1. По определению togaf мне не хватает измерений. Как архитектор я имею дело не просто со структурами компонент, а с четырех мерными (плюс время), или даже с "пяти-мерными" (плюс смысл) структурами.

2. В определении Буча появляется смысл и подспудно присутствует время. Но потерялось слово "система". Простая совокупность решений не дает эмерджентности.
Архитектура не просто набор, это система позволяющая находить оптимальные решения.

Исходя из своего понимания термина стараюсь при описании архитектуры совмещать оба подхода:
1. Давать описания архитектуры как системы (AD)
2. Давать описание архитектуры как набора осмысленных значимых решений (ADR)

Пока так

Архитектура как система

1. Многие рекомендуют при проектировании архитектуры использовать системный подход (см. А. Левенчук и др.)
2. Имеется в виду два момента:
- Мы проектируем систему (то есть не набор компонент, а нечто обладающее эмерджентностью)
- Мы проектируем системно (то есть рассматриваем различные аспекты системы)
3. Однако программная система это продукт всего процесса разработки. А продукт архитектора именно архитектура.
4. Если применять системный подход к работе архитектора, то следует признать, что архитектура тоже является системой со своей эмерджентностью и многоаспектностью.
5. Какое новое качество появляется при объединении всех архитектурных решений, моделек и принципов ?
ИМХО это возможность получить оптимальный и обоснованный ответ на вопрос стейкхолдеров, в частности разработчиков.

То есть, в моем понимании, архитектура это некоторая система знаний и решений позволяющая ответить на вопросы связанные с реализацией системы.

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

Вот такую работу раздают бесплатно

Modeling more software performance antipatterns in cyber-physical systems


Промоделированы многие известные анти-паттерны производительности

#Книга

Граф зависимостей по производительности

Готовлюсь к докладу по методологии принятия арх. решения.

Под это дело "причесал" граф зависимостей по производительности

Разные времена

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

Решение задач производительности

Если обобщить все тактики решения задач производительности то остается только два пути:
1. Залить железом (Manage Resources)
2. Повысить эффективность системы (Control Resource Demand)

Многие считают, что залить железом это оптимально. Так как железо зачастую стоит дешевле часов разработки.

Однако, стоимость не единственный критерий качества.

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

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

Кстати, те же рассуждения верны в плане повышения надежности.

Антипаттерн "Критическое мышление"

1. Критическое мышление по определению - способность анализировать информацию и делать выводы на основе умозаключений.
По факту критическое мышление пришло на смену логическому/научному мышлению.
2. Отличие критического мышления от научного в ареале применения. Логическое мышление Вы используете там, где чувствуете себя специалистом. Критическое мышление используется повсеместно.
3. Критическое мышление притягательно.
- Можно не зная о предмете высказывать свое суждение, облеченное в логические фигуры.
- Можно с легкостью отбивать атаки на свой информационный пузырь.
4. Критическое мышление опасно. Мнение специалиста уже не столь значимо. У каждого есть свое.
Заказчик заранее знает какое "техническое решение" правильно и сколько времени займет его реализация.
Джун легко назовет ошибки архитектора.
5. Стремясь противостоять критическому мышлению архитектор фиксирует не только свои выводы, но и их обоснования (ADR).

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

#Антипаттерны

Архитектура как система (contd)

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

Сегодня у Максима Смирнова нашел классификацию тех самых вопросов
https://news.1rj.ru/str/it_arch/1594

Похоже интересная работа. Добавляю в список для чтения.

Активный архитектор

Перечитал вышеизложенные типы запросов к архитектору и позволил себе некоторые возражения )

ИМХО архитектор в представлении автора череcчур пассивен.
Работает исключительно как служба.

А где вопросы от "самого важного" стейкхолдера - от самого себя.

Я убежден, что должен быть добавлен запрос на выявление рисков не реализовать ожидание заказчиков.

Этот запрос приведет нас к некоторому списку архитектурных задач (enablers), которые впоследствии придется драйвить.

Простая "архитектурная" задача и немного ТРИЗ на прошлом ArchDays
https://youtu.be/j5oiahWsyro?si=_fD7ncNmLbZXR-d4

На InfoQ вышел отчет по архитектурным трендам 2024 года.
Микросервисы продолжают закатываться )

https://www.infoq.com/articles/architecture-trends-2024/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

👆Увидел на восходящих Green software - какие-то недобрые предчувствия (

https://youtu.be/NZuy2QYHfCQ?si=dp5oHU1gSiFZ750l

Fast flow

Крис Ричардсон представил интересный взгляд на микросевисы: концепцию трех быстрых потоков (fast flow):
1. Поток организационный (топология команд)
2. Поток доставки ( DevOps)
3. Поток архитектурный - поддерживающий первые два.

Полностью здесь:
https://microservices.io//post/architecture/2024/04/10/success-triangle-is-about-fast-flow.html

Определение термина "архитектура"

На текущий момент мое понимание архитектуры ПО выглядит так:
система моделей программного обеспечения каждая из которых выражает значимые решения обоснованные интересами заинтересованных сторон.

Архитектура предлагает обоснованные ответы на вопросы связанные с развитием и поддержкой программного обеспечения.
Обоснование
- Архитектура не просто знания, а знания о рассматриваемой системе то есть модель.
- Но не одна модель, а множество моделей связанных с разными аспектами деятельности различных заинтересованных сторон.
- При этом не совокупность моделей а система, так как архитектура обладает эмерджентностью, связанной с целью ее формирования.
- Цель архитектуры – решение проблем заинтересованных лиц в процессе развития и поддержки системы.
- Модели фиксируют решения проблем заинтересованных лиц
- Решения связаны с конкретными заинтересованностями, и связь эту можно проследить (обоснованность)
- Представлены только значимые решения, то есть те которые в дальнейшем трудно переиграть (остальное - дизайн)

Смысл системы и цель архитектора.

Чтобы осознать свою цель на проекте, архитектор должен не только ясно понимать ситуацию, но и занять определенную позицию.

О понимании

Большая путаница возникает при смешении понятий цель и смысл.
Цель стейкхолдера это некоторое состояние, в достижении которого стейкхолдер заинтересован.

Смысл системы это индукция цели на систему. Сама система целью обладать не может, так как не может иметь заинтересованности. Система реализует цель и в этом ее смысл.

Цель индуцируется на других стейкхолдеров путем мотивации или манипуляции.
Можно обобщить понятие смысла на все индуцированные цели, но при этом возникнут некоторые дилеммы.

Например, писать код без багов смысл или цель программиста?
Смысл, так как этим самым программист удовлетворяет чужие цели. Но и цель, так как этим самым программист удовлетворяет своё чувство прекрасного и добывает себе некоторую порцию дофамина, серотонина а иногда и адреналина.

Откровенно говоря, все наши цели индуцированы в нас из вне.

Как же в этом случае определить основной смысл системы?
Чья цель главнее?

В замкнутой системе проекта вопрос решается просто.
Основной целью является бизнес цель – цель, ради которой заказчик инициализировал проект.

Обычно это прибыль/гешефт, в той или иной форме.

Бизнес цель обеспечивается через удовлетворение заинтересованностей пользователей системы. Заинтересованность пользователя обеспечивает прибыль заказчику.

О позиции

А каков смысл архитектора?

С точки зрения заказчика, архитектор обеспечивает реализацию бизнес цели. На то и нанят.
Об этом, кстати, говорит первая аксиома архитектуры от SEI.

Однако, то же самое чувство прекрасного и ответственность заставляет архитектора натягивать на себя еще и цели других стейкхолдеров.

Система должна быть не только прибыльной, но и красивой/
целостной/полезной.

Так что на этапе рекогносцировки архитектор должен выявить основные заинтересованности стейкхолдеров и определить свое отношение к ним.

Чему служим, господа.)

Основная цель архитектора.

Для пояснения вышесказанного, приведу небольшой кейс:

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

Какую цель Вы будете преследовать?

1. Я профессионал, то есть за деньги. Цель максимально эффективно извлечь прибыль, в том числе и накопленными знаниями.
2. Архитектора нанимают для реализации бизнес цели. Буду во всём способствовать этому.
3. Я должен построить качественную систему удовлетворяющую конечных пользователей. На благо людям. Менеджеры мне в этом помогут. Наши промежуточные цели совпадают.
4. Буду балансировать между различными интересами. Основная цель - все стейкхолдеры должны уйти удовлетворенными.
5. Я всё таки архитектор. Так что it depends )