Простая "архитектурная" задача и немного ТРИЗ на прошлом 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 )

Коллеги, спасибо всем тем, кто поделился своим пониманием цели формирования архитектуры!

Много лет я преподавал практики SA, повторяя вслед за методологами аксиому о высшей значимости бизнес цели.

Сейчас я убежден, что архитектор вправе сам определять свою цель на проекте. И вы подкрепили мою уверенность. )

Смысл выключателя

1. У любой системы есть смысл – цель ее существования с т. з. заинтересованного субъекта (стейкхолдера)
- Смысл делает систему системой. Т. е. не просто совокупностью элементов, а целостностью, обладающую некоторым ценным эмерджентным свойством.
2. Одна из задач архитектора – определить смысл проектируемой системы.
3. Одна из практик выявления смысла сводится к постановке "правильных" вопросов.
4. С моей т. з. самым быстрым путём к смыслу будет вопрос: "А что было бы, если бы системы не было бы?".
- Вы не задавали себе вопрос, почему выключатель называется выключателем, а например, не включателем? Ответ прост. Если бы выключателя не было бы, свет горел бы всегда. Смысл выключателя в добавлении основной функции "выключения" и вспомогательной "включения".
5. При этом ответ на этот вопрос различен с т. з. разных стейкхолдеров.
6. Основным стейкхолдером системы является пользователь , он и определяет основной её смысл.
- При этом пользователь микроскопа может определить его как инструмент для заколачивания гвоздей.
7. Как бы не были значимы интересы бизнеса, бизнес-цель это дополнительный смысл системы.
- Например, система должна приносить прибыль (нет системы - нет прибыли).
8. Интересы команд поддержки и сопровождения сводятся к возможности работать с системой.
- При этом полностью законченная и абсолютно надежная система становится неинтересной.
Забавный факт:
Многие признают, что основной смысл системы идет от пользователя, но при этом утверждают, что основная цель проекта - удовлетворение бизнес-целей. Нет ли здесь когнитивного диссонанса?

Интересная статья по моделированию производительности https://dzone.com/articles/queuing-theory-for-software-engineers

Обещанная презентация с TeachLead Conf.

Тема для доклада слишком объемная.
Но дробить на несколько докладов не стал.
Буду в канале разбирать по частям.

Базовая методология по программной архитектуре

На прошедшей конференции меня часто спрашивали:
какую методологию я порекомендую архитектору ПО.

Опубликую свой ответ здесь.

Я считаю базовыми знаниями - знания практик от института SEI.

Многие методологи ссылаются на методы SEI.
ATAM, ADD и др. упоминаются во многих работах, в том числе TOGAF.

Многие курсы по архитектуре базируются на курсах Рика Казмана из SEI.
Сам преподавал по Kazman Workshop в Люксофт )

Большое количество материала здесь - https://www.sei.cmu.edu/publications/index.cfm

Базовая методология

Возвращаясь к предыдущему посту хотелось бы объяснить, что я имею ввиду под термином "базовая методология".

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

Примерно так же это сделал небезызвестный Eoin Woods:
Взял от SEI метод ATAM и настроил его под себя назвав TARA.

2. Почему за базу беру практики SEI?
a. Они достаточно популярны и много где упоминаются.
b. Эти практики имеют хорошее покрытие по активностям программного архитектора.
c. Эти практики хорошо документированы.

3. Использую ли я методологию SEI в ее "классическом" виде?
Нет.
Слишком тяжела для большинства кейсов.

Так что: "после сборки обработать напильником" )

Обучение архитектуре

По последнему докладу получил следующий комментарий:

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

Так как не могу ответить лично, отвечу здесь.

Для принятия архитектурного решения года изучения теории явно недостаточно.

Я бы сказал от пяти лет. При этом активно сочетая с практикой.

Я не буду толерантно называть это "моим мнением".

Зафиксирую это как факт.

Инженерная школа
(Ворчалка)

1. Не прекращаются споры о том, чем должен заниматься в проекте архитектор/аналитик/программист etc.
2. Вопрос легко решается в рамках одного проекта. Но на общих площадках согласия нет. Идут баталии.
3. Я вижу причину в том, что традиции русской школы программной инженерии во многом утрачены.
4. Где под школой я имею ввиду не только совокупность методов, но и традиции, культуру, организованную преемственность.
5. Старые инженера-программисты, носители культуры остались в почтовых ящиках и большей частью не пошли в бизнес проекты.
6. На смену пришли молодые. Всё с нуля. Источник знаний - инет. Методология эклектична. Культура? А зачем она вообще!
7. Возможно все утрясётся и устаканится. Под термином "программный арх." везде будут понимать одно и тоже. ГОСТ по архитектуре будет не слабым переводом ИСО, а собственным выстраданным, творением. Возможно, но не факт.

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

Architecture Through Different Lenses

InfoQ опубликовал книжку (mini-book) Architecture Through Different Lenses.

К сожалению, не доступна для скачивания из нашей локации.

Выложу здесь)