#оффтоп #литература

Читаю сейчас книгу Data Mesh in Action: https://www.amazon.com/Data-Mesh-Action-Jacek-Majchrzak/dp/1633439976/.

Ценная работа, в которой сформулированы многие идеи, которые давно хотел увидеть в литературе.

Особое внимание привлекла глава 4.2: «Applying ownership using domain decomposition.», особенно раздел 4.2.1 «Domain, subdomain, and business capability», где авторы проводят сравнение доменов из DDD с бизнес-возможностями. Не со всем согласен, но пост не об этом.

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

Приведу пару цитат:

"A business capability is what a business can do. It focuses on what, not how or who. It is defined by its outcome, which is usually expressed as a qualitative rather than quantitative measure."

"...Therefore, we should also focus on the outcome (qualitative), not the output (quantitative)."

For example, if we organize a birthday party for children, it doesn’t really matter how many cakes, toys, chairs, and tables we prepare (quantitative output). What matters is happy and smiling kids after the party (qualitative outcome); how we achieve that is of secondary concern."

И далее приводится пример "правильного" результата (outcome):

"Produce good-enough quality movies and series desired by the audience. This is a proper outcome. It is a qualitative measure and is focused on the impact that should be made (a series desired by the audience)."

#флешбэк

Если внимательно изучить примеры, можно заметить, что "правильный" outcome должен формировать позитивный опыт.

Это подтверждает наш вывод о том, что в успешных системах недостаточно просто удовлетворить потребности — важно создать позитивный опыт.

https://news.1rj.ru/str/IndustrialSoftwareArchitecture/70

А вот следующие рекомендации по неймингу напрямую связаны с темами предстоящих постов:

"Business capability should be phrased as a verb-noun combination, and this structure will help us focus on the activity and its outcome."
"...It is vital to define the name of a capability and its desired outcome (not output)."

Здесь авторы дают рекомендации по фреймингу. Как и обещал, далее мы обсудим, что такое фреймы и коснемся темы фрейминга.

#критика

Противопоставлять моделирование и diagramming нельзя в принципе, потому что:
1. Диаграммы порождаются в процессе моделирования, проектирования, документировании и тп.
2. Диаграммы всегда являются моделями, без исключений; почему именно — рассмотрим в деталях позже.

Когда человек утверждает, что выполняет диаграмминг (diagramming), он часто не до конца осознает, что делает на самом деле (см. п.1).

Создавая диаграммы, мы создаем модели. А в одном из значений, построение и изучение моделей реальных объектов и явлений — это и есть моделирование.

Противопоставлять создание моделей моделированию - пустое занятие.

Кстати, нашел только одно определение для diagramming:
«Diagramming - providing a chart or outline of a system
...
type of: representation»
https://www.vocabulary.com/dictionary/diagramming

При этом, chart (диаграмма) - это модель. И можно сказать, что модель это представление (representation) некоего объекта, предназначенное для рассмотрения определённых его аспектов (в разных целях).

Мы создаем модели в виде диаграмм в рамках таких процессов, как моделирование или проектирование. Даже скетчи (эскизы) мы рисуем не ради художественного самовыражения, а в более практичных целях (это тоже модели).

#миф
Ну а о блеске и нищете C4 Model мы поговорим отдельно и расскажем, как пытались разработать метамодель для моделей в C4 Model. Это далось непросто.

Кстати, авторы C4 Model благоразумно не называют её нотацией. Они говорят: "The C4 model is an "abstraction-first" approach to diagramming software architecture,...
The C4 model is notation independent, and doesn't prescribe any particular notation"
https://c4model.com/#Notation

И да, относить C4 Model к нотациям действительно неверно — это миф.

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

Иначе и быть не может, ведь развитие не происходит точно по плану.

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

Погружаясь в тему стратегий, у меня возникла идея сформулировать архитектурные максимы, по аналогии с максимами в управлении и стратегии.

Максима — это правило поведения, выраженное в краткой формуле.

#доклад
Впервые я сформулировал рекомендации, некоторые из которых вполне можно отнести к максимам, на ArchDays в 2019 году: https://www.youtube.com/watch?v=hGXkpzOw78I

На тот момент эти рекомендации не воспринимались мной как максимы.

#максима

Не приступайте к разработке нового функционала без стабилизации текущего.

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

https://news.1rj.ru/str/IndustrialSoftwareArchitecture/90

Строители не начинают возводить стены, пока не застынет фундамент. Мы же почему-то считаем, что законы в «софте» не работают и долги отдавать не нужно.

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

#FYI
Легаси (от англ. legacy — наследие) — в одном из значений это решение, в котором разобраться чрезвычайно трудно или вовсе невозможно. Такое решение практически не поддаётся развитию и зачастую рациональнее его «переписать», чем пытаться развивать.

Решение может стать легаси по разным причинам, не только из-за непомерного технического долга. Например, команда может уйти, не оставив документации, или используемые технологии могут устареть.

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

В широком смысле легаси — это решение, которое невозможно или нецелесообразно развивать.

Там, где начинается легаси, заканчивается инженерия.

Напомню, инженерия это: «Творческое применение научных принципов для проектирования или конструирования машин, аппаратов или производственных процессов или эксплуатации их с полным пониманием их устройства; или прогнозирования их поведение…»

https://news.1rj.ru/str/IndustrialSoftwareArchitecture/45

#максима

Сначала создайте коммерческий продукт, и только потом мигрируйте на него.

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

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

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

Важные условия: решение должно быть модульным; коммерциализация всего функционала без исключения не обязательна; действовать стоит итеративно.

Эта формула (максима) применима, однако, только если есть ресурсы — время и деньги.

Коммерческий продукт, лишённый лицензий, обновлений и поддержки, — это легаси. Такой продукт развивать невозможно.

Хочу поделиться видео Жени Лукьянова про микросервисы.

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

Я же считаю, что с точки зрения инженерии микросервисы – это автономные модули. Эту точку зрения я подробно объясню в разделе, посвящённом конструированию, после обсуждения тем моделирования и проектирования.

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

https://youtu.be/ZwkoGV-4rSw?si=VvuC8hscN9yMhGak

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

#итоги

Промышленная архитектура программных систем: Параллели со строительством и ключевые черты

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

Основные моменты:

- В программной инженерии, как и в строительстве, существуют архитектурные стили, которые отражают исторический контекст и требования своего времени, и способствуют распространению и применению лучших практик для их реализации.
- Промышленная архитектура в строительстве ориентирована на проектирование зданий для производственных нужд, с акцентом на функциональность, экономическую эффективность, инновационность, надёжность, безопасность, модульность и автономность.
- Промышленная архитектура программных систем так же направлена на создание промышленных решений и сохраняет те же акценты.
- Общим трендом для промышленной архитектуры как в строительстве, так и в разработке программных систем является проектирование с учётом будущих изменений и обеспечение эволюционности

Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/15

#итоги

Системы и инженерия: Промышленная архитектура как элемент возрождения инженерных подходов в разработке программных систем

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

Основные моменты:

- Системы порождают эмерджентность — системный эффект, при котором возникают свойства, не характерные для её отдельных элементов.
- Понимание системного эффекта и применение инженерных подходов являются ключевыми факторами для успешного проектирования сложных программных решений.
- Ключевые свойства программных систем, как технических систем, выполненных в стиле Промышленной архитектуры: наличие потребительских качеств и выполнение полезных функций, способность к многократным изменениям состояния, многоэлементность и наличие множества связей между элементами, иерархичность.
- Применение Эджайл-методов и микросервисной архитектуры часто приводит к хаосу и непредсказуемости в эксплуатации и развитии систем.
- В настоящее время появилась необходимость в систематизации инженерных практик в архитектуре программных систем для создания предсказуемых, экономически эффективных и безопасных решений. В связи с этим предлагается новый стиль — «Промышленная архитектура программных систем».

Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/26

#оффтоп #холизм

Счёл важным привести пример системного подхода в одном из величайших трудов по стратегии «О войне», Клаузевица:

«В нашем предмете, более чем в каком-либо другом, вместе с частью должно мыслиться целое»

Что важно, автор задаёт эту установку (холизм) с самого начала, во вступительной части.