В 2008 году я защитил диссертацию по приложению методов искусственного интеллекта в технической диагностике.

Тема моей работы начиналась со слов: "Триадная фреймовая модель представления знаний в технической диагностике..."

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

В начале 2000-х было принято начинать изучение ИИ с основ, включая когнитивную психологию. Тогда считалось нормальным — читать книги.

Кстати, в 2002 году мы обучили нашу первую нейронную сеть. Но оказалось, что для наших задач "нейронки" не подходят. В итоге я переключился на семантические модели и, если говорить современным языком, на графы знаний.

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

На мой взгляд, "экран" — это удачное название для элемента декомпозиции системы с точки зрения когнитивной психологии.

Когда мы рассматриваем отдельный элемент модели системы, мы "загружаем" в память соответствующую структуру знаний о нём (экран). Затем мы смещаем фокус (рассмотрения системы) на другой элемент и заменяем структуру знаний в памяти на новую (другой экран).

Если знания меняются, изменяем их структуру в памяти (экран).

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

Здесь я возвращаюсь к декомпозиции и абстракции. Ещё чуть-чуть, через шаг, и я дам определение этим понятиям. На следующем шаге мы, однако, рассмотрим фреймы Марвина Минского

#оффтоп

На практике, однако, мы видим, что часто в памяти макароны замещаются лапшой, и ещё чаще лапша непрерывно смешивается с макаронами

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

Читаю сейчас книгу 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

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