Этот кейс вроде бы совсем не «архитектурный». Но это совершенно не так, этот кейс максимально «архитектурный».

Архитекторам часто приходится решать задачи за рамками проектирования архитектуры (High-level design) и уж тем более низкоуровневого проектирования (Low-level design).

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

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

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

#ИМХО #оффтоп

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

Да, опытным архитекторам часто приходится создавать предпосылки для успешной реализации системы (способствовать feasibility).

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

#юмор

Важная причина провалов проектов по разработке заключается в Законе Круглова, который гласит: «Структура программных систем копирует структуру амбиций и политических притязаний руководителей»

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

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

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

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

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

Не случайно Генри Минцберг, признанный гуру стратегического менеджмента, назвал один из своих бестселлеров «Структура в кулаке». И не просто так Донелла Медоуз в другом бестселлере "Азбука системного мышления" уделяет структурам особое внимание.

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

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

В 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 — наследие) — в одном из значений это решение, в котором разобраться чрезвычайно трудно или вовсе невозможно. Такое решение практически не поддаётся развитию и зачастую рациональнее его «переписать», чем пытаться развивать.