Телесная инженерия -- это практика настройки/обучения/выращивания тела для свободного движения в рамках какой-то культурной телесной практики паттернированных движений (спорт, танцы, единоборства, секс, и т.д.). Как и любая инженерия, она связана с реализацией конкретных проектов в отношении своего тела: "постановка позного бега", "основной шаг сальсы", "доставать до ног, чтобы вновь завязыать шнурки", "исправить осанку и стать красивым" и т.д.. Эти проекты входят в программы телесного развития: кто-то ставит задачу просто распрямиться, кто-то -- достичь уровня владения телом достаточным, чтобы выигрывать чемпионаты мира по своей спортивной или танцевальной дисциплине. Каждому своё.

Системный фитнес -- это трансдисциплина, которая позволяет собрать воедино всю работу с телом (https://ailev.livejournal.com/1454436.html). Телесная инженерия -- это прикладная дисциплина, решающая конкретные задачи. И эти задачи по большей части типовые. В инженерии спортивного тела, в танцевальной инженерии, в "просто фитнесе" есть наборы упражнений, которые при систематическом их использовании позволяет настроить тело на свободное движение в рамках какого-то избранного культурного двигательного паттерна.

Соотношение между системным фитнесом и телесной прикладной инженерией примерно такое же, какое существует между системной инженерией и прикладными инженериями (программной инженерией, аэрокосмической инженерией, инженерией предприятия и т.д.). То есть разные телесные инженерии -- это специализации системного фитнеса для какой-то двигательной практики.

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

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

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

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

Есть три варианта борьбы с этими ошибками:
-- много заниматься целевой практикой. Обычно пять-шесть лет упорной работы, и тело подстраивается. Но это неточно: проблема (какой-нибудь жгут в бедре, системно влияющий на плавность и амплитуду движения лопатки -- в теле причины и следствия могут быть разнесены довольно далеко!) может остаться и через десять лет практики, если не повезло, и не попадаешь на какие-то паттерны движения, где эта проблема рассасывается "сама собой", или если какой-то тренер не дал упражнения, убирающие эту проблему.
-- заниматься общефизической подготовкой. Например, танцоров иногда посылают бегать кроссы. Это сильно укрепляет тело, которое было до этих кроссов совершенно неприспособлено к танцам. Но обычно в ходе общефизической подготовки а) мышцы "забиваются", то есть ситуация ухудшается за счёт наличия ещё большего количества нефункциональных напряжений, не дающих проявиться качественной работе необходимых для работы функциональных органов мелких мышц и б) подкачиваются совсем не те мышцы, которые требуются для рабочих паттернов выбранной культуры движения. Бегание кроссов никак вам не поможет подкачать мышцы, нужные для "кача в землю" в кизомбе.
-- воспользоваться методами системного фитнеса, чтобы выполнить инженерный проект -- заняться телесной (танцевальной, спортивного тела, и т.д.) инженерией.

Телесная инженерия включает:
а) инженерию телесных требований -- нужно понять, в чём потребность. Какая культурная норма, как её проинтерпретировать в терминах работы функциональных органов. Нужно также провести диагностику: что именно не работает?
б) архитектурное и детальное телесное проектирование -- нужно составить набор упражнений, который уберёт войну мышц друг с другом и затем подкачает освобождённую слабую мышцу, или растянет освобождённую напряжённую мышцу, а заодно и наладит координацию движений, обучив мозг не напрягать лишние мышцы, задействовать только нужную мускулатуру.
в) "изготовление" свободно двигающегося тела -- систематическое (т.е. дисциплинированное, без пропусков) выполнение упражнений, все эти "три раза по пять подходов". Упражнения состоят из двух частей:
-- общефункциональная подготовка тела (снятие зажимов, растяжки, подкачки, изоляция целевого функционального органа от других мышц, не участвующих в целевом паттерне движения). Например, важно прекратить войну мышц друг с другом: https://ailev.livejournal.com/1455767.html
-- тренинг собственно культурного паттерна (шага в позном беге, волны руками в вейвинге).
г) управление конфигурацией и изменениями -- прогресс регистрируем! Ну, и всё у нас "аджайл", указанная последовательность логическая, а не "стадии во времени". И одновременно идёт работа по многим паттернам движения.
д) проверка и приёмка: проверяем, удалось ли задуманное
е) использование в деле -- соревнованиях, вечеринках, просто в жизни (скажем, если речь идёт о походке, при которой перестаёт болеть спина).

По сути, для самых разных паттернов движения:
-- меняется набор упражнений для исправления тела (у каждого свои главные проблемы в разных проблемных движениях, их решение требует разных наборов упражнений. Кому-то нужны упражнения на вращатели ног, кому-то на вытяжители рук). Эти упражнения обычно трансдисциплинарны, но они специально отбираются под проблему (см. про системный фитнес как трансдисциплину -- https://ailev.livejournal.com/1454436.html).
-- более-менее одинаково ставится прикладная работа по овладению целевым паттерном: речь идёт об упражнениях, которые позволяют задействовать функциональные органы в культурном движении целевой практики. Например, ставится "рамка" у танцоров, делаются упражнения по улучшению ведения и ведомости, делается постановка практики "кача в пол" в африканских танцах, отрабатывается техника броска в борьбе, постановка ног при боковых передвижениях в волейболе, и т.д.

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

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

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

Цепочка текстов "Системный фитнес" -- https://ailev.livejournal.com/1429126.html

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214252870609738

https://ailev.livejournal.com/1456631.html

То, что мы танцуем на кизомба-вечеринках -- это чувственная компа, sensual kompa/konpa/compas, на гаитянском креольском это будет gouyad -- sexually suggestive dance moves, sensuous body movement (basically). То есть так и нужно искать "чувственную компу" (при этом чувственность там однозначно понимаемая -- не любовь к Родине, не любовь к мороженому). Поиск по слову kompa даёт чуть больше результатов, чем по слову konpa -- это по факту синонимы, а вот compas правильные найти невозможно (забиваются compass-компасом, а ещё по-испански compas это "ритм", и в результате в выдаче больше шума, чем искомой компы, среди которой ещё нужно ухитриться найти "чувственную" с её характерным саундом. В википедии, тем не менее, главным термином даётся именно compas -- https://en.wikipedia.org/wiki/Compas ).

У меня общее ощущение, что международный пик моды на компу прошёл -- он пришёлся где-то на 2015 год (и гугль-тренды это, вроде, подтверждают, и находимые треки и альбомы). Другое дело, что до кизомба-вечеринок это ещё только-только добирается. И танцуют в Москве под компу просто кизомбу, а не компу с её специфическими переносами веса. Но посмотрим, что будет дальше. Поветрия приходят и уходят, а мода приходит и остаётся. Компа как музыкальный жанр существует с конца 50-х, хотя обсуждаемый gouyad с характерным электрогитарным звучанием и синтезаторным lead соло, конечно, появился попозже.

Удивительно, но я могу слушать эти компы дольше, чем кизомба-музыку. Вероятно, сказывается то, что During and after the US occupation, the word jazz has become synonymous with music bands in Haiti. So the mini-jazz is a reduced m'eringue-compas band. The movement started in the mid-1960s when young small neighborhood bands played konpa featuring paired electric guitars, electric bass, drum set-conga-cowbell; some use an alto sax or a full horn section, others use a keyboard, accordion. Так что компа имеет некоторый джазовый оттенок, что для моего уха весьма приятно.

А вот кизомба-музыку я долго слушать не могу, могу только танцевать -- она для меня не джазова, а жутко попсова, я это не выдерживаю. Но у меня есть подозрение, что компу я наоброт -- один или два трека смогу протанцевать, а три трека подряд это уже будет много (выглядит этот танец как на этом видео -- https://vk.com/wall247400234_333, хитрости работы бёдер я описывал в https://ailev.livejournal.com/1450716.html). Хотя на занятиях сейчас и два часа танцую. Но это далеко не танцую ещё, это ещё "отрабатываю". Но если этот танец станет популярным, то он наверняка будет усложняться, так что и танцевать его будет не скучно. Ну, и его наверняка будут миксовать со всей остальной кизомбой, как сейчас миксуют всё многочисленное семейство тарраш*.

У кого ВКонтакте, идите в музыку и ищите momento mizik -- там сплошь медитативные инструментальные медленные классические компы с абсолютно характерным саундом. Хотя они и сильно напоминают по звучанию midi-файлы, если вы понимаете, о чём я. Но ВКонтакте там не самое свежее, увы. В яндекс.музыке есть их альбом 2018 года -- https://music.yandex.ru/album/4957172. Ужасно унылая вроде бы и однообразная (что твой нью-эйдж на три аккорда) штука, но почему-то не могу оторваться. Какие-то совершенно дикарские лады, во много слоёв, абсолютно крышесносно. Оцените, например, гармонию и мелодику в Chale Gouyad в альбоме по ссылке. Любителям джаза это будет очень знакомо, но очень нелегко. Хотя после десятой-двенадцатой мелодии ухо привыкает и уверенно считает всё это довольно логичным, гармоничным и мелодичным. В наушниках там ещё и совсем глубокий бас, что добавляет. Всё, что со словом gouyad, похоже, совсем классический саунд. Когда на urban kiz вечеринках U Party в MadMan (https://vk.com/hellokizomba) ставят сейчас компу раза три за вечер, это как раз они и есть. Это ни с чем не спутаешь.

А вот образчик конпы с вокалом -- выпущен (группой? лейблом?) Zo Konpa, альбом 2018 года -- https://music.yandex.ru/album/5967305. Там написано, что это zouk, но прислушайтесь -- с первой же песни это ж как раз та самая компа, абсолютно характерный саунд! Хотя да, зук там наливают из той же бочки (и из этой же ритмической бочки m'eringue-compas наливают ещё и коладейру, кизомбу и даже cadence-lypso и soca). А альбомов 2018 года у Zo Konpa восемь штук, редкостная плодовитость!

Более точно и продуктивно искать сладкие компы по слову gouyad где-нибудь в ютьюбе -- https://www.youtube.com/watch?v=Y6iSzeXTBrk (это микс 2018 года). Эти новые песни миксуют невероятной длины, минут по восемь один трек (типа https://www.youtube.com/watch?v=PEkdXupZyxo). И в soundcloud их тоже полно, по тому же магическому слову gouyad -- https://soundcloud.com/oswaldsxm/dj-skety-oh-oswald-bob-marley-dadju-gouyad

https://ailev.livejournal.com/1456281.html

Опубликованы видео моих выступлений на SECR'18 (https://ailev.livejournal.com/1448663.html).

1. Стейкхолдерское мастерство (http://0x1.tv/20181012AC, 30 минут):
Когда человек играет стейкхолдерские роли, то он одновременно и личность со своими личными заботами, и профи-по-роли – программист, менеджер проекта, архитектор. Этих ролей десятки, и нужно уметь их играть.

Лидерство – это практика в помощи людям занять их ролевые позиции с целью катализировать сотрудничество в группе.

Руководителей лидерству учат. А вот учат ли всех остальных занимать ролевые позиции?

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

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



2. Как и какое мышление нужно развивать (http://0x1.tv/20181012AJ, 1 час 30 минут):
Приход технологий искусственного интеллекта с неизбежностью ведёт к перестройке технологического стека во многих и многих отраслях. Так что и руководителям, и инженерам, и всем остальным нужно быть готовыми к быстрой смене рода деятельности.

Что позволяет нам быстро перестраиваться, быстро меняться? Фундаментальное образование, развивающее как формальное, так и неформальное мышление.

Такое образование долго получать, его сложно получать в зрелом возрасте, но на его базе легко осваивать разные практики. Проблема в том, что сегодняшнее state-of-the-art фундаментальное образование оказывается другим, нежели которому учат в школах и университетах. Так какое же мышление нужно развивать в рамках этого нового фундаментального образования?

Мастер-класс был посвящён ответу на этот вопрос.



Спасибо Стасу Фомину за эти видео ( https://www.facebook.com/stas.fomin )! На страницах видео (короткие ссылки на них даны в заголовках докладов) на сайте http://0x1.tv/Медиатека можно оставлять комментарии -- и там же можно найти другие доклады SECR'18. Сейчас на этом сайте собрано 2337 докладов 1499 докладчиков с 59 конференций).

Эти два доклада представляют часть того, что я даю на курсе "Дисциплины для апгрейда образования инженера, менеджера, предпринимателя" (state-of-the-art дисциплины второго бакалавриата) -- http://system-school.ru/uptodate.

https://ailev.livejournal.com/1456022.html

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

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

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

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

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

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

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

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

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

Мы будем задействовать намерением работы наши функциональные органы: струны натяжения, спирали вращения, паровозы напряжения. С этой целью будем делать в каждой позе растяжения цикл дорасслабления через пост-релаксации (http://medrich.ru/publication_p_2.html?id=146), но проводимые не в ходе массажа, а самостоятельно под контролем сознания. Каждая мышца при достаточной нагрузке становится заметна -- и в момент снятия нагрузки происходит весьма заметное в ощущениях её обмякания (релаксации). Вот это ощущение обмякания какой-то ранее не чувствовавшейся мышцы нужно почувствовать, сознательно усилить и заодно запомнить, где и как это ощущается (чтобы потом смочь воспроизвести осозанно без предварительной изотонической нагрузки). И после дополнительного сознательного обмякания этих мышц (на это уйдёт сначала 5 секунд, потом меньше и меньше) уходить дальше в растяжку. Цикл нужно делать по всем функциональным органам. Например, если речь идёт о ноге, то её нужно практически не двигая (как в изометрической гимнастике) упирать вправо, влево, вверх, вниз, вытягивать, втягивать, скручивать вправо-влево -- запоминая ощущение обмяканий отдельных мышц при отмене каждой пятисекундной нагрузки и сознательно пробуя усилить эти ощущения, т.е. дообмякнуть. Вот прохождение этого малого цикла (в одной позе, большой цикл, например, для формирования-выучивания какой-то струны, может включать несколько поз) и есть "упражнение системного фитнеса на контроль обмякания".

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

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

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

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

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

Цепочка текстов "Системный фитнес" -- https://ailev.livejournal.com/1429126.html

https://ailev.livejournal.com/1455767.html

В системной инженерии подчёркивается, что она одновременно системна (systemic) и систематична (systematic).

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

Систематичность -- это совсем другое, это просто честное формальное (а не интуитивное) обращение внимания на то, на что внимание нужно обратить в ходе какой-то системноинженерной практике. Дисциплину (во всех смыслах этого слова) нужно чтить. И хотя жизненный цикл можно адаптировать -- но только сознательно, исключая "не сделали, потому что забыли, и вообще не до того было". Все предписанные практиками жизненного цикла все рабочие продукты нужно честно сделать, выполнив с ними все предписанные работы. Если речь идёт о системной схеме проекта с семью альфами, то это честное обращение внимания на все семь альф, без пропусков. Если речь идёт о design structure matrix (матрица, в которой показываются связи каждой части системы с каждой другой частью системы), то нужно честно продумать каждую клеточку. Дисциплина -- это много-много рутинного труда. Именно этот рутинный труд позволяет "не быть лохом", вовремя находить ошибки и неожиданные решения -- а потом так же дисциплинированно исправлять эти ошибки и воплощать решения.

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

Систематичность сразу подразумевает огромное количество умственной работы, причём документируемой -- вгрызание в какие-то детали с упорством маньяка. Системность повышает вероятность, что это важная работа, а не лишняя и зряшная. Системность и систематичность живут рука об руку, они в балансе (http://incoseonline.org.uk/Normal_Files/WhatIs/Systems_Engineering.aspx?CatID=What_Is_SE, https://www.researchgate.net/publication/327073164_Envisioning_Systems_Engineering_as_a_Transdisciplinary_Venture).

Всё то же самое относится не только к системной инженерии, но и к системному менеджменту, системному предпринимательству, и даже системному фитнесу как практикам. Человек, занимающийся системным фитнесом (https://ailev.livejournal.com/1429126.html) может сколько угодно разбираться в мышлении, как налаживать себе роскошное подвижное тело. Но если он систематично не будет делать предписанных "пять подходов по 30 секунд вытяжения", не определив перед этим, какое место в теле у него наиболее проблемное, чтобы эти пять подходов наносили непоправимую пользу ("документировать" результаты мышления), то это не будет означать, что он практикует системный фитнес. Он будет системен, но не систематичен. А для получения результатов в проектах любого сорта нужна не только системность, но и систематичность. Одновременно. Дисциплина мышления и дисциплина действия.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214233809253216

https://ailev.livejournal.com/1455596.html

Определилась дата четвёртого потока курса "Дисциплины для апгрейда образования инженера, менеджера, предпринимателя" -- 9 декабря 2018. Подзаголовок курса -- state-of-the-art дисциплины второго бакалавриата. Потихоньку меняется содержание курса, и поэтому название опять поменялось.

Третий поток "Системного менеджмента и стратегирования v2" я начинаю уже в это воскресенье, а с начала этих марафонов это уже 12й поток!

Свёрстана зимняя программа и для остальных преподавателей. Оргизменения и распределённое лидерство (А.Турханов) -- 8 декабря 2018. Системная инженерия и менеджмент продукта (В.Мизгулин) -- 9 декабря 2018. Очередной поток системного фитнеса (А.Климат) -- 5 января 2019. Системный подход в инженерии и менеджменте (вводный курс, Ц.Церенов) -- 19 января 2019. Очередные потоки онтологики -- попозже зимой. Всё медленно, но движется -- сами смотрите на карту курсов: http://system-school.ru/#courses

Осознал, что наплодил за последние годы кучу "цепочек" текстов, но нет нигде места, где их все можно было бы компактно найти. Поместил пока на страницу профиля в ЖЖ (https://ailev.livejournal.com/profile). Вот они:
-- подстрочник рассказа о клубе одиноких мозгов сержанта Солта -- http://ailev.livejournal.com/1287293.html
-- фундаментальное образование -- https://ailev.livejournal.com/1427073.html
-- второй бакалавриат -- https://ailev.livejournal.com/1453126.html
-- SysMoLan -- https://ailev.livejournal.com/1443879.html
-- системный фитнес (и там же кизомба) -- https://ailev.livejournal.com/1429126.html

Это "книжки для ленивого писателя" (идею я подхватил от sequences Юдковского -- какие-то курируемые наборы эссе/постов в блоге), путешествие какой-то мысли, "лабораторный журнал", но не оформленное в связный нарратив какой-то книжки. Книжку всё одно читать не будут. Впрочем, и мои тексты в блоге не читают, они все многабукофф. Дмитрий Бутрин отметил вчера (https://www.facebook.com/dmitry.butrin/posts/2062915867097851): "проблема в том, что никто ничего толком не читает, кроме вводок-сообщений информагентств-соцсетей и изредка, в совершенно другом режиме - книг, в основном легкого чтения. я уже с изумлением сталкивался среди коллег с почти полной утратой способности к пониманию смысла более или менее развернутого текста, с которыми не требуется специально работать. поверьте, я с уважением к этим коллегам отношусь до сих пор, это образованные и интеллигентные люди, много читавшие ранее, часть из них профессионально работает со словами - и сейчас тоже, эта потеря внешне на их профессиональной компетентности не сказывается. это что-то вроде болезни, на деле объем чтения рядового человека в сравнении с 20 годами ранее колоссален. я и у себя иногда вижу эту симптоматику - очень сложно настроиться на понимание среднего размера текста в течение двух-трех секунд, как ранее. усилие для преодоление этого барьера, ранее не нужное (это делалось автоматом, неосознанно) порой нужно - небольшое, но нужно. есть ощущение, что вскорости выбор будет именно таким - или очень коротко (скетч/краткое сообщение), или уже что-то очень трудоемкое (большое эссе/монография/роман)". И он делает дальше вывод: "в моем понимании, 6-9 тыс. знаков - оптимальный объем для общего представления большинства "новостей". меньший объем дает сильнейшие искажения в понимании смысла происходящего, систематически большая подробность изложения, завязанная на подробность сбора/анализа информации, для медиа в общем случае экономически невозможна. иными словами, "мелкие куски" - это когда вам кажется, что вы стали знать много больше, но на деле вы стали знать существенно меньше".

Я ему там ответил, что у меня студенты пытаются учебник "Системное мышление" (396 страниц, 107 иллюстраций) читать на телефоне. Можно ли разглядеть что-то на этих иллюстрациях (там же диаграммы!) на телефоне?! Результаты плачевны. Но эти плачевные результаты в разы лучше, чем полное отсутствие результатов у тех студентов, кто смотрит с телефона видеолекции. При этом официальная позиция в учебных заведениях, что "нужно обязательно писать видео, и этого видео должно хватать, материал там должен быть полный -- ибо современный студент читать разучился, будем учить таких разучившихся. Пусть хотя бы видео смотрят, вдруг научатся или хотя бы заинтересуются". Смотрят же главным образом с телефона, причём между станциями метро (в чём честно признаются). В головах при этом не остаётся вообще ничего, это многократно проверено.

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

Мои тематические посты "из цепочек" в ЖЖ, кстати, как раз где-то на 6-9К, ровно "раскрытие темы", хотя очень часто и длиннее бывают. Для ЖЖ это нормально, вот и не ухожу от этого. Это 2.5К в фейсбуке грабаул караулят (текст Бутрина про проблемы с чтением длинных текстов примерно такой по длине -- и его обозвали многабукофф!). Пишу в ЖЖ я больше для себя (это ж лабораторный журнал, web log), и хотя эти посты в том же фейсбуке обильно лайкают (чуть меньше лайкают ВКонтакте), но их не читают. А уж по ссылкам в посте и подавно не ходят, хотя по ссылкам там много чего интересного. На вопрос, почему лайкают, хотя не читают, отвечают: проще найти будет, если захотим прочитать потом.

В лицее вьюнош борется с химичкой. Химичка натура творческая, и преподаёт химию в устной народной традиции -- как былины. Что вспомнит из обширных знаний, то и даёт. Но если ты пропускаешь занятие, то народного эпоса не услышишь. Но "незнание закона не избавляет от его исполнения": сдавать знание рассказанного нужно. И тебя отсылают к конспектам других учеников. А конспекты других учеников -- вы представляете, что они там успевают записать? Проще считать, что их нет. К тому же химия-как-эпос рассказывалась бы вечерами в племени у костра не один раз, а несколько. Тут же концерт однократен. Поэтому проблемы с химией у многих. Материал при этом далеко выходит за границы учебника. И у нас дома есть множество учебных пособий, где есть практически всё. Проблема в том, что всего этого много! Я в университете сдавал органическую химию по учебнику-двухтомничку формата А4. Радикальное решение проблемы -- вьюнош выучивает органику в вузовском объёме. Но я сам химик по образованию, и считаю, что учить её и в школьном объёме -- лишняя трата времени. Поэтому нужно минимизировать усилия: получить где-то пару листочков программы курса, где есть темы и подтемы. И выучить материал программы по нормальным учебникам. Или хотя бы получить видео (я и сам много чего рассказываю в той же школе системного менеджмента. Но программа рассказа обычно есть на слайдах, а ещё обязательно пишется видео -- поэтому проблемы дырявых конспектов нет). Беда в том, что эту программу мы получить не можем, и подозрение в том, что её нет. Формальная (строго по учебнику) наверняка есть, а актуальной -- нет, всё идёт с голоса. Так что вьюнош воюет: "как я могу ответить ваше правило Марковникова, когда меня ему не учили!" (пропустил занятие). Я пишу ехидные заметки в чатик класса, прошу прислать программку, чтобы понять, что именно должен знать вьюнош, получаю там родительские лайки от таких же, как я, но дело стоит.

"Бороться до конца" тут никто не будет. Если потребуется (что мне сомнительно), то органику вьюнош выучит в том объёме, в каком потребуется. Только учить нужно будет не для "фундаментального образования", а для какой-то прикладной работы, если она у него случится. Я как химик по образованию точно могу сказать, что правило Марковникова и реакцию Вюрца ему для фундаментального образования знать не нужно (он, кстати, задачу на применение этого правила Марковникова сообразил как решать, и решил -- на основе общей химической эрудиции, просто не знал, что это именно "правило Марковникова" называется). Химия простирает руки свои в дела человеческие не так широко, как раньше. Уже химики моего года выпуска (1980) работали кем угодно, кроме как химиками, в химии остались буквально единицы. Поэтому абсолютно неважно, чем там кончится эта его борьба за переход от народного эпоса к какой-то письменной культуре, или даже к постписьменному визуальному современному эпосу (тексты-то не читают! и вьюнош тоже не любит читать! он бы тоже предпочёл видео перформанса от сказителя химических былин).

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

Вот такая музыка сейчас ставится на вечеринках кизомбы под именем douceur -- https://soundcloud.com/j-kee-kizomba/j-kee-my-world-vol2-crossing-kizomba-mix. Если вам нужна полуторачасовая кизомба-колыбельная, то это как раз оно. Активно обсуждается, что партнёрши под эту музыку засыпают, не прекращая танцевать -- это у них изменённое состояние сознания "космоса", или это просто транс с потерей чувства времени, или это они и впрямь спят? Нет ответа! Но под эти колыбельные можно отлично не только танцевать, но и работать, да и не менее отлично тонуть в соцсетях.

Я продолжаю ходить на вечеринки: сегодня пойду на вечеринку в 12 минутах пешком от дома в танцшколе SpicySalsa, в воскресенье чуток подальше (но всё одно меньше получаса добираться), в рестобар MadMan на Курской. А вчера я был на вечеринке в Papa Joy's на Таганке, но недолго -- всего час. Представил, как бы выглядел этот текст, если бы я писал "схожу сегодня в качалку недалеко от дома, вчера буквально час бегал трусцой на Таганке, а в воскресенье пойду на тренажёры на Курской". Нет уж, я буду ходить на вечеринки! Вот тут я "в тренажёрном зале" в прошлую среду (да, тоже забежал туда буквально на час -- это на Баррикадной -- а там случился фотограф):


Вот, семажик показывает, что в посте 10.3Кзнаков. Многабукофф. Мало кто прочтёт.

UPDATE: обсуждение ВКонтакте -- https://vk.com/wall2449939_1955 (и там фантастическая музыка инструментального хип-хопа, трип-хопа и jazz-hop).
Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214215260069498

https://ailev.livejournal.com/1455136.html

Вчера прошло совместное заседание методсовета ШСМ и русского отделения INCOSE, где обсуждали SysArсhi (https://ailev.livejournal.com/1444887.html). Большинство вопросов было к мета-модели SysArchi в части требований/целеполагания (в ней части хорошо видны -- сиреневенькая часть относится к модели требований/целеполагания, жёлтенькая к архитектуре предприятия, зелёненькая -- архитектуре целевой системы):


Видео всего заседания -- https://youtu.be/yTa9UrjQgd4. Утверждённое соглашение о моделировании SysArchi версии 1.0 -- https://yadi.sk/i/zhht0RshtJzyMQ

Мои выводы:
-- разговор про архитектуру и архитектурные описания (спасибо ISO 42010, IEC 81346 и т.д.) уже более-менее все поддерживают. И более-менее понимают про 4D экстенсионализм. И что целевая система и обеспечивающая система неразрывны и должны бы моделироваться вместе.
-- модели требований не понимает никто. В головах только понятия "требования" и где-то далеко от них понятие "стейкхолдер". Далее идёт неясная цепочка понятий, где выделяются "потребности". Что трассировка потребностей к требованиям впрямую не может быть осуществлена (там же граница системы по пути! Изменение стейкхолдеров и их viewpoints/языка, разные свойства разных систем) признаётся, но про механизмы моделирования этого никто не знает. Поэтому уйма вопросов,

Итого:
-- соглашение о моделировании утвердили в текущей версии (обозвали её версией 1.0 и призвали духов природы продолжать работать над следующими версиями -- вдруг откликнутся?), равно как и отметили, что SysArchi в его текущем виде мало поможет в больших проектах, и что мало кто может внести в эту метамодель что дельное (а что там лишее -- так запросто можно не использовать. Например, не использовать моделирование требований вообще). Дальше внимание нужно уделять SysMoLan (https://ailev.livejournal.com/1443879.html).
-- мне нужно что-то делать, чтобы в головах появилось не только представление об архитектуре и основных архитектурных решениях, но и представление о целеполагании.

GORE -- goal-oriented requirements engineering, это как раз то, что требует моделей требований. Я когда-то много об этом писал: https://ailev.livejournal.com/811715.html (2010 год), и это был фронтир (https://ailev.livejournal.com/900086.html), но за прошедшее время моделирование требований прошло по факту в мейнстрим, и даже в определении системной инженерии начали говорить не только о раннем по жизненному циклу определении/описании потребностей (stablishing stakeholders’ purpose and success criteria, and defining actual or anticipated customer needs and required functionality, early in the development cycle), но и документировании и моделировании требований: https://ailev.livejournal.com/1453390.html. Тем самым GORE и MBCD начинают смешиваться до неразличения -- и это поставлено как проблема в инженерии требований, см. соответствующий раздел в https://ailev.livejournal.com/1425741.html

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

Работа с целями обеспечивающих систем (в инженерии предприятий, по факту это практики стратегирования) -- это модели целеполагания, motivation models (например, стандарты OMG BMM, business motivation model, или OpenGroup ArchiMate 3.0 motivation extention).

Системность SysArсhi была в том, чтобы
-- моделировать целевую систему в её операционном окружении и обеспечивающие системы в рамках одной модели. И рамках одной же модели и с одинакомым подходом делать моделирование требований/целеполагания для целевой системы и для обеспечивающей (например, использовать эти модели для проведения business/mission analysis -- понимать, насколько участие в проекте какой-то целевой системы связано со стратегией предприятия обеспечивающей системы).
-- убрать дребезг, возникающий при моделировании сразу нескольких системных уровней (когда в зависимости от уровня кого-то называют то "член команды", то "(внешний) стейкхолдер" или одно и то же описание то "потребностью/требованием стейкхолдера", то "системным требованием". В Архимейте всё это одноуровнево, поэтому полно этих разделений на "внутренний-внешний". Поэтому значок используем один: "требование", а уж как его разные команды назовут (требование, потребность, ограничение/архитектурное решение) -- это уже зависит от того уровня, которым занимается команда, как целевой системой.
-- моделировать на одной диаграмме все важные описания: не только архитектурные описания, но и архитектурные потребносити/требования/стратегию (архитектурные, то есть ведущие к архитектурным решениям, потому как для детальной инженерии требований все эти визуальные языки -- слону дробина, см. подробней книжку "Визуальное мышление. Доклад о том, почему им нельзя обольщаться", там я об этом подробно написал: https://ailev.livejournal.com/1437344.html). Вот модель целеполагания и попала в мета-модель.

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

Основные различения для этого моделирования заключаются в понятиях стейкхолдер, интерес, оценка интереса, цель, принцип/дисциплина, требования. Увы, большинство обсуждающих пытаются вообразить, что бы там могло скрываться за этими обыденными словами (их не волнует обычно, что в английском для "цели" могли бы быть target, goal, object, objective, aim и даже mark, purpose и end, и это ещё не конец списка -- да и по-русски тоже есть много чего, включая канцеляритную "целеустановку". Но очень редко "мишень", хотя в английском target тут вполне немилитаристски слышится). Со словом "интерес" (concern) вообще беда. Но в данном случае непонимания моделей требований упирается не в эту игру содержанием слов (см. "слова-термины важны, и слова-термины неважны" -- https://ailev.livejournal.com/1442764.html), а именно с непониманием самой идеи моделирования требований, обсуждаемых там сущностей-концептов.

Вот онтика системных описаний, где подробно прописаны понятия интереса и оценки интереса -- https://ailev.livejournal.com/1429330.html. В том числе там прописано отличие интереса (concern) и метода описания (viewpoint). Это самая частая ошибка моих студентов. Понятие дисциплины (из которой берутся принципы, как закономерности дисциплины, и для выражения понятий которой существует метод описаний) -- вот тут. Дисциплина нам важна, как что-то, позволяющее адекватно моделировать интерес. Интерес -- это просто функциональное обозначение какой-то предметной области, необходимой стейкхолдеру для его деятельности. Он для удовлетворения своего интереса он выбирает (или ему предлагают!) какую-то дисциплину и связанный с ней метод описания объектов этой дисциплины. И далее уже описывается, что там с оценкой интереса в данном проекте. То есть "хотелка" это не интерес, а как раз оценка интереса! А цель -- это переход в действие, что нужно сделать (глагол), чтобы сдвинуть оценку интереса. Результирующие требования описываются в терминах выбранной дисциплины (и если вы не читали учебники по дисциплинам, отвечающим на те или иные интересы проекта, то вам этих требований обычно не понять. Ну, или вы просто не учтёте этих требований, потому как не знали о них! Помним, что требования открывают/discover или выявляют/elicit, а не "разрабатывают" -- сидя на диване, их не "сочинишь").

Современные методы разработки требований в этом месте не заморачиваются особо. Например, JTBD хорош для разработки приложений в телефоне (и все примеры оттуда: один человек, которого нужно обслужить по-королевски). А если вам нужно определиться с требованиями к авиадвигателю, то вечер сразу станет томным. С другой стороны, использовать для требований к авиадвигателю визуальный язык -- это неправильно вообще (правильно, если авиадвигатель из "образовательного авиастроения", по аналогии с "образовательной робототехникой". То есть самолёт и двигатель оба игрушечные, "из учебного проекта"). Так что языком моделирования требований должен быть текстовый язык.

В общем, с моделированием требований/целеполагания беда. Вывод: мне нужно об этом говорить более подробно. У меня сейчас в поддержку архитектурных описаний (кишок системы) самая толстая и сложная глава в учебнике -- пятая. А в поддержку внешних (чёрного ящика) описаний системы много меньше. А зря. Так что буду потихоньку вносить поправки в свои курсы и тексты, исправлять ситуацию.

UPDATE: Обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214214245764141

https://ailev.livejournal.com/1454948.html

Мне особенно нравится, что настоящие роботакси (без водителя-дублёра) приходят не под звуки фанфар, а буднично: https://www.bloomberg.com/news/articles/2018-11-13/waymo-to-start-first-driverless-car-service-next-month. Первая лицензия (для Waymo) для полностью безлюдных автомобилей в Калифорнии уже выдана (https://medium.com/waymo/a-green-light-for-waymos-driverless-testing-in-california-a87ec336d657), а в декабре начинают возить по ценам, конкурирующим с Uber и Lyft. Сейчас у Waymo 600 роботакси, в которых присутствуют водители-дублёры, и поездки делаются в порядке эксперимента. Но для этой новой уже коммерческой, а не экспериментальной службы роботакси уже закуплены 62тыс. автомобилей-гибридов и 20тыс. электромобилей (подробней об этих сделках -- https://venturebeat.com/2018/10/30/waymo-becomes-the-first-company-to-obtain-a-fully-driverless-car-permit-in-california/). А ещё оказывается, что водитель-дублёр только повышает опасность беспилотника -- https://medium.com/waymo/the-very-human-challenge-of-safe-driving-58c4d2b4e8ee. И любые шаги в беспилотную сторону только повышают безопасность (травм становится меньше на 60%, как показал эксперимент Intel с автобусами в Лондоне) -- https://venturebeat.com/2018/11/14/intel-claims-its-mobileye-driver-assistance-system-cut-bus-accidents-by-29-in-london-trial/

Элон Маск тем временем продолжает утверждать, что в области беспилотников именно его автомобили впереди всех (https://www.recode.net/2018/11/2/18053428/recode-decode-full-podcast-transcript-elon-musk-tesla-spacex-boring-company-kara-swisher). Хотя они и не роботакси, а просто личные машины. Но когда он за ночь обновит софт Tesla для вождения на уровне 4/5, то это затронет десятки тысяч электромобилей сразу.

И это не единственные компании, участвующие даже не в гонке, а планомерном выходе на рынок новой технологии безлюдного вождения -- https://www.bloomberg.com/news/features/2018-05-07/who-s-winning-the-self-driving-car-race (это ещё майский обзор, там и про экономику тоже замечания). Технологии, которая не только поменяет жизнь существенно, но и поменяет взгляды на жизнь. Фотографии без фотографов, машинопись без машинисток, поездки без водителей. И так далее по всему списку. Шутку про "испугались, кожаные мешки?" я опущу. Бояться тут нечего, нужно радоваться. Будет не рабочая пятидневка, а четырёхдневка (или фрилансовый её аналог -- "неполная занятость, но каждый день", или просто "не каждый день"), только и всего.

Фронтир системной инженерии -- это именно автомобили без водителя. И только во вторую очередь повторноиспользуемые космические ракеты и обеспечиваемый ими мировой интернет с низкой латентностью. А там и авиация на подходе (в пассажирскую роботов пока не пустят, но в грузовую -- всё уже в разработке -- https://www.bloomberg.com/news/articles/2018-10-10/will-you-fly-when-your-pilot-is-a-robot).

Дальше можно делать ставки: когда можно будет заказать поездку на роботакси в Москве? Через год? Через два? Через три?

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214188336676430

https://ailev.livejournal.com/1454797.html

В этом тексте я формулирую гипотезу, что системный фитнес -- это трансдисциплина для культурного (то есть паттернированного в рамках какой-то телесной лексики) человеческого движения, по образу и подобию системной инженерии для целевой системы и системного менеджмента для обеспечивающей. И тут примерно те же отношения с инженерией, что и у системного менеджмента, и системного предпринимательства: либо считать, что они все такие специальные инженерии, либо считать, что у них, как и у системного фитнеса, всё-таки свой предмет, и инженерный подход тут не очень применим (подробней я писал об этом в "трансдисциплинарность и системный кругозор", https://ailev.livejournal.com/1453619.html).

Системный фитнес добивается успешного тела примерно так же, как системная инженерия добивается успешности целевой системы, а системный менеджмент добивается успеха системы обеспечивающей. Для этого системный фитнес определяет требования к телу и перестраивает опорно-двигательный аппарат специальными тренировками для соответствия этим требованиям. Если нужно танцевать акробатический рок-н-ролл, это будет одно тело, если балет -- другое, если просто ходить, чтобы спина не болела -- третье. Под каждую проблему (целевой перформанс) можно выполнить какую-то подстройку. При этом системный фитнес учитывает, что нужно настраивать/перестраивать тело отнюдь не только в проблемном месте, но и во многих других местах (системные связи!), и кроме тела настраивать нужно ещё и мозг -- например, чтобы мозг заметил существование каких-то групп мышц и научился ими произвольно управлять: расслаблять, напрягать, контролировать развиваемое усилие.

Тут нужно уточнить понятие успешности системы, как это сделано в https://www.researchgate.net/publication/327073164_Envisioning_Systems_Engineering_as_a_Transdisciplinary_Venture. Если раньше просто говорилось о том, что учтены интересы стейкхолдеров, то теперь акцент делается на факт о прохождения валидации и реальной эксплуатации: удовлетворении потребностей (stakeholder needs) в реальном мире. И упор на то, что по факту идёт выход в эксплуатацию. При этом понятие outcome и output (при согласии, что в словаре они синонимы) различают: output это собственно целевая система, которая тут объявляется не важной. Успешность системы определяется не ей самой, не удовлетворением требований к системе. А вот outcome -- это то, что система делает в окружающем реальном мире (выход в 4D, "мечты о системе" тут не подходят). И если это приводит к удовлетворению потребностей (система прошла валидацию и эксплуатируется, нанося непоправимую пользу), то только тогда она успешна. В случае системного фитнеса успешность тела определяется удовлетворением потребностей стейкхолдеров в проектах человеческого движения (конечно, с трансдисциплинарным привлечением всех необходимых других дисциплин): старики разгибаются и дальше ходят прямо, танцоры удовлетворяют качеством своего движения себя и публику, спортсмены выигрывают соревнования, любители кама-сутры и их партнёры получают своё удовлетворение, пианисты достигают нужной техники игры, вокалисты нужной техники вокала -- и так далее по всему обширному спектру крупной и мелкой моторики.

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

Но как для предприятий не принято говорить "требования", но можно говорить о "стратегии", так и для тела язык системной инженерии не всегда применим. Стратегия тренировок (учитываем, что владелец тела -- стейкхолдер, и его мероприятия по развитию/evolution тела, это такое предприНятие для него, тренера, иногда врача и т.д., системность позволяет тут учесть многих стейкхолдеров), но к самому телу будут таки требования. И потребности, конечно, будут: использующая система для тела-в-действии всегда найдётся. И эти потребности будут у стейкхолдеров перформанса этого тела: танца, поединка, и т.д.. Успешность проектов системного фитнеса -- это по факту успешность этих самых перформансов, а не успешность самого тела. Валидация, а не верификация.

Назвать "системная телесность" -- это сразу ассоциации с психологией (все эти "телесные терапии"). Системное человеческое движение -- непонятно. В Санкт-Петербурге это называют "фитнес для умных" (https://vk.com/mozgtelopiter -- там курс планируется в январе 2019). Пусть уж остаётся системным фитнесом: приведение тела в готовность к планирующимся перформансам (fit to purpose).

И, как и в системной инженерии, может появиться множество специализированных вариантов -- как программная инженерия, или автомобильная инженерия. Например, Антон Климат решает проблемы танцоров в серии семинаров "танцевальная инженерия". Тут сходство даже в выбранном названии "инженерия" для специализации. В этих мероприятиях меньше универсальности, плюс упражнения более тесно связаны с целевой практикой. Можно точно так же делать мероприятия по "инженерии единоборств", "инженерии хорошей осанки" и т.д. -- вариантов тут не счесть, частных специализаций может быть множество. Но все они опираются на более-менее одну и ту же понятийную систему дисциплины системного фитнеса.

В таком рассмотрении системный фитнес берёт ответственность за конечный результат движения, а не просто готовит тело как полуфабрикат/заготовку для других дисциплин. И проблемы при этом будут те же, что и с системной инженерией: в какой-то момент обнаруживается, что все проекты в самых разных отраслях уже работают со стейкхолдерами и их потребностями, строят модели требований, все обязательно занимаются архитектурой, все управляют конфигурацией (а как же иначе?), проводят проверочные и приёмочные испытания -- и как рыбка не замечает воды, так люди не замечают того, что некоторое время назад всего этого не было, и осознанное выполнение всего этого в инженерном деле как раз и есть "системная инженерия" как трансдисциплина. Я был бы счастлив, если бы в работе с телом приключилось ровно это. Но пока это далеко не так, общих для самых разных двигательных дисциплин практик не наблюдается -- хотя при внимательном рассмотрении они все наличествуют, как и практики системной инженерии наличествуют во многих инженерных проектах, где системная инженерия даже не упоминается (но, например, упоминается очень близкая к ней программная инженерия -- по факту они выросли из одного корня, из опоры на системное мышление).

И тут тоже возникает проблема кругозора, связанного с телесными/двигательными практиками. Хорошо бы понимать, какие там есть стейкхолдеры, какие поддисциплины, какая их вариативность. Спорт-танцы-единоборства вспоминаются сразу, wellbeing в части "хожу, и спина не болит" -- много реже, секс замалчивается (каждый изобретает свою собственную кама-сутру, культуры движения вроде как нет, и говорить об этом не принято), игра на музыкальных инструментах и вокал вообще не считаются мышечной работой, двигательной активностью, сценическое движение маргинально (хотя с докладами многие выступают, но это ж "просто стоять" -- для этого любое тело сойдёт. Или не сойдёт?). Про мир человеческого движения нужно знать явно в объёме большем, чем даётся на уроках физкультуры в школе -- и вот системный фитнес должен обеспечить тут какой-то кругозор. Проблема тут в том, что "культура движения" уж точно включает в себя и танцы, и спорт, и этот самый фитнес. Но немного людей будут считать, что "готовность к танцу" (буквально, "фитнес") включена в системный фитнес. Ровно то же самое с системной инженерией. Для неё программная инженерия -- это просто её специализация как трансдисциплины, а для программной инженерии системная инженерия что-то глубоко внешнее, сама программная инженерия себя чувствует отдельной дисциплиной, полностью самодостаточной (в крайнем случае, частью "просто инженерии", а не "системной инженерии"). Вот с системным фитнесом, танцами и каким-нибудь футболом возможны такие же рассуждения.
Системный фитнес:
-- задаёт основную структуру предметной области на достаточно общем уровне телесного движения (см. "холархию человеческого движения", https://ailev.livejournal.com/1371120.html) на каком-то системном уровне. Скажем, если ты порвал связку -- это к врачу, это не системный фитнес, это уровнем ниже. И если ты настолько психован, что не можешь пять минут выполнять какое-то упражнение -- это к психиатру, это не проблема системного фитнеса. И все вопросы про паттернирование (танцы, спорт, секс, просто "ходить так, чтобы спина не болела", и т.д.) -- это к аналогам "инженерии по специальности", то есть к соответствующим тренерам/преподавателям по разным двигательным практикам (преподы в танцах не любят слово "тренер", они себя считают учителями -- учат культуре, а не тренируют как в спорте).
-- задаёт язык, на котором удобно инженерно (т.е. с точки зрения создания успешной системы) говорить о теле и его движении/перформансе -- и это язык ощущений/кинестетики (а не визуальный или аудиальный). Задаёт способ, которым этот кинестетический viewpoint связывать с желаемыми внешними телесными эффектами.
-- задаёт системное описание тела: функциональные органы ("вытяжители", которые вытягивают руки-ноги, скручивающие их "вращатели", струны, "анатомические поезда" по Майерсу и т.д.) и конструктивные органы (настоящие мышцы-связки-фасции, которые выполняют функции "вытяжителей", кости и т.д.).
-- устанавливает виды жизненного цикла (как и в системной инженерии, тут может быть разнообразие: например, настройка тела сначала "просто упражнениями фитнеса", а потом обучение паттернированному движению уже способного к этому движению тела, или параллельный/concurrent фитнес, когда часть тренировки(sic! в фитнесе у нас тренировки) уходит на приведение тела и мозга в порядок, а часть тренировки/занятия/перформанса уходит на целевую двигательную практику, то есть просто прямохождение, танцы, спорт, секс, игру на музыкальных инструментах, вокал и т.д.. Тут может быть множество самых разных практик, участвовать множество самых разных стейкхолдеров, компетентных в этих практиках. И даже тренировка самого фитнеса может быть адаптирована к целевым паттернам движений -- примерно так же, как системная инженерия всегда готова принять какую-то архитектурную работу, выполняемую по нормам одной из предметных инженерий. Но следит, чтобы архитектурная работа в жизненном цикле была представлена! Так и тут: системный фитнес проследит, чтобы "было чем танцевать", "было, чем прыгать" -- что паттернированное движение выполняется готовым для этого телом, и т.д.

Цепочка моих текстов "Системный фитнес" -- https://ailev.livejournal.com/1429126.html
Страница Антона Климата -- https://vk.com/klimat
Описание текущего курса системного фитнеса в ШСМ -- http://system-school.ru/move (сейчас идёт третий поток).
Пример курса танцевальной инженерии -- https://vk.com/event170522388 (и там много отзывов, курс прошёл буквально неделю назад).

https://ailev.livejournal.com/1454436.html

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

Вот пример танцевания современной компы (счастье, что есть что показать: все остальные ролики сняты на вечеринках, и там видны только смутные тени посреди цветомузыкальных всполохов) -- https://vk.com/wall247400234_333. Ведение там осуществляется хитрой африканской работой таза, изолированной от всего остального тела. Я как раз сейчас пытаюсь выучить эту довольно сложную для европейца мышечную координацию, хотя не могу сказать, что преуспел (вот тут я писал подробней -- https://ailev.livejournal.com/1450716.html). Но компа на вчерашней вечеринке U Party (в Madman) звучала трижды, и я трижды хотя бы пытался танцевать компу, а не "просто кизомбу". В Париже на кизомба-вечеринках её уже танцуют часто и регулярно, и эта мода к нам ещё докатится.

Вот ещё один широко обсуждаемый (https://vk.com/wall-167384137_30703) сегодня в кизомби-сообществе пример, это douceur ("медленная кизомба") от автора tarraxOsteo: http://www.youtube.com/watch?v=-2bAgXJg7HY. Конечно, в кадре абсолютно не видно происходящего внутри пары. Так, тени на стене от горящего внутри огня. Но это хорошая иллюстрация к вопросу о количестве событий в теле за секунду "медляка". И необходимых для этого изоляциях. И музыкальности. И что такое true kizomba в плане музыки (все эти "не настоящая кизомба, не буду танцевать"). Вообще, медленная волна по телу получается очень сложно: её нужно всё время подруливать мелкими мышцами. Это быстрая волна "сама бежит" за счёт физики. А медленная волна бежит за счёт правильных сокращений правильных мышц и правильных расслаблений правильных мышц. И мышечные удары "в натяжение" тоже хорошо видны. Рони Салех показывал технику мгновенных вытяжений как lift-tension-direction (foxkiz -- https://ailev.livejournal.com/1452638.html), но много раз оказывалось, что я единственный партнёр из пяти-шести, с кем партнёрши пробовали танцевать, который демонстрировал что-то похожее на это tension (и то только потому, что Антон Климат мне это в какой-то момент разъяснял как общий принцип). В общем, пахать нужно, чтобы и такое танцевать. И, конечно, уже танцуем — хотя и не на таком уровне. Но уж как можем.

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

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

Вот очередное моё фото для отвлечения внимания, с семинара Рони Салеха:

https://ailev.livejournal.com/1454149.html

"Как он дышит, так и пишет" -- это из окуджавского "Исторического романа" http://www.karaoke.ru/song/1327.htm. Если не так дышит -- значит, не так пишет. Или вообще перестал писать. Отвлёкся.

Вот датчик дыхания в 10 грамм весом, которое крепится на поясе с внутренней стороны и ловит паттерны дыхания -- и дальше нейронные сетки по этим паттернам определяют уровень сосредоточения-отвлечения: https://www.indiegogo.com/projects/foci-wearable-that-boosts-your-focus#/. Вроде как работает, и вроде как надёжно.

Да, это нейронные сети, глубокое обучение: распознавание состояния сознания по паттерну дыхания. Отмоделирована как раз "преподавательская чуйка". И это всё цветочки, ягодки будут, когда на тему вашего внимания с вами будут разговаривать простым и понятным для вас (например, матерным, или высоким штилем -- каждому тут своё) языком. Ну, и делать это будет не специальный "агент внимания", а ваш собственный персональный ассистент, это будет его очередная "компетенция" (skill). В этом направлении интеграции Alexa, Cortana, Siri, Bixby и т.д. с отдельными skills на общем голосовом интерфейсе работа уже кипит: https://venturebeat.com/2018/11/09/ai-weekly-tech-giants-need-developers-to-help-imagine-the-future-of-assistants-like-alexa-siri-and-bixby/

Игорь Берхин справедливо отмечает, что такие штучки через несколько лет вполне могут заменить половину учителей mindfulness -- и эти "сугубо человеческие" профессии будут автоматизированы -- https://www.facebook.com/groups/svobodauma/permalink/1986906314682191/.

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

А дальше? Можно думать про замеры cognitive load не только для человека, но и для группы (вот тут мы намечали эту тему -- https://openmeta.livejournal.com/236784.html). Интересно, что на indiegogo можно купить и 10шт. одной партией, educational pack.

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

Системная инженерия -- она сейчас в этом. Как маленькую идею быстро и дёшево воплотить "в железе", и вписать в какие-нибудь большие инфраструктурные сервисы. Называете вы это системной инженерией, или менеджментом продукта, или lean startup (системная инженерия, системный менеджмент и системное предпринимательство существенно переплетены -- см. "трансдисциплинарность и системный кругозор", https://ailev.livejournal.com/1453619.html).

https://ailev.livejournal.com/1453842.html

Студенты МФТИ у меня вышли на экзамен, а первая оценка (10 из 10) была поставлена досрочно. В целом онлайн-группа техпредов (четверо из которой ходят на "вебинары" вполне очно, ибо они в Москве) выглядит сильно получше, чем "просто студенты". Отношу это только к одному: к их кругозору. У них есть опыт работы, они не сразу после бакалавриата пришли. Это означает, что слово "стейкхолдер" они воспринимают не абстрактно, а понимают, что проект зависит от огромного количества других людей. И они представляют последствия своих решений, хотя бы чуть-чуть: что будет происходить в реальности после воплощения этих решений.

С бакалаврами же пока очень плохо. Они фантазируют, концепты из учебника привязываются ими к объектам их фантазийного мира. А фантазия, как водится, всё стерпит. И это ещё не инженерия, это пока просто системное мышление: не требуется ничего "разработать", требуется только немножко описать свой проект (но вот если в проекте ещё ничего не "разработано", то тогда да -- full stop, если нет никаких идей ни по требованиям и потребностям, ни по архитектуре). А ещё закончилась группа СМС2.2 -- так там и экзамен прошёл (в виде презентаций проектов, ровно как будет у студентов). И в целом я удовлетворён этой осенью. С учебником, задачником и людьми постарше (не по возрасту, а по опыту работы!) всё с научением получается более чем хорошо. Собрали и отзывы, "что изменилось в вашем мышлении". Исправление ошибки по "обеспечивающей системе как целевой" указывается как главный позитивный сдвиг, механика работы со стейкхолдерами занимает второе место (отделение стейкхолдера-роли от человека и его должности), третье место -- вывод функциональных рассмотрений на первое место, что особенно это круто ломает мозг айтишникам, как ни странно. У них "мышление каменщика": берём модули, и кладём из них любую форму, какую мастер скажет. Что они и есть мастера, и должны себе сами сказать -- вот это обычно крутой поворот в мозгах. Что DDD это не про модули, а про функциональность.

По факту, наши курсы сейчас переводят "бессистемный кругозор" в "системный кругозор".

Я размышляю сейчас над темой "системного кругозора" и кругозорных трансдисциплинарных (организующих другие дисциплины) практик типа системной инженерии, системного менеджмента и системного предпринимательства. В случае системной инженерии тут происходит осмысление с ней происходящего со стороны как системноинженерного, так и академического ("системные инженеры на пенсии") сообщества, а вот в случае системного менеджмента и системного предпринимательства похожих дисциплин не сформулировано. Более того, интенция системной инженерии ставить (трансдисциплина!) задачу и для менеджерских практик сформулирована уже явно. В https://www.researchgate.net/publication/327073164_Envisioning_Systems_Engineering_as_a_Transdisciplinary_Venture чётко прописано, что сама эта терминология трансдисциплинарности идёт от того, что системные инженеры должны иметь дело кроме инженеров ещё и с огромным числом самых неожиданных стейкхолдеров не-инженеров. И первое, что происходит, так это выход системных инженеров на инженерию обеспечивающей системы, что раньше было прерогативой менеджмента. И участие в замысле целевой системы, что раньше было прерогативой предпринимателя. Вот из текста по ссылке:

Transdisciplinarity connotes a strategy that crosses many disciplinary boundaries to create a holistic approach. For example, in defence and aerospace systems engineering, it is common practice to involve both operational users and specialists in human factors and psychology when formulating operational concepts, user requirements, and human-machine interface designs. In general, a transdisciplinary approach enables inputs and participation across technical and non-technical stakeholder communities and facilitates a systemic way of addressing a challenge.
Transdisciplinarity emphasises the benefits of bringing in people who actually live and breathe the problems trying to be solved, such as ordinary people, local politicians, businesses, social groups, etc. – in other words, ensuring that the key stakeholders come “into” the SE process. But it also entails having those outsider stakeholders help shape the process to be used for problem and solution space definition. This is because people bring their worldviews with them when they start examining what they think the problem really is, which carries over when you start trying to solve the "problems" you identified. You don't just invite them to design reviews to see if they concur or not. This is an example of how a system, in this case Systems Engineering itself, both changes and is changed by its environment.
Such a development would provide a Systems Engineering meta-framework for integrating all the different discipline activities – technical and non-technical, from within and far beyond engineering - in a systems context.

Нужно теперь разобраться с тем, как формулировать трансдисциплины менеджмента и предпринимательства (ну, или согласиться с системными инженерами, что "кто первым встал, того и тапки" -- что они пришли и всё захватили в других сферах деятельности, эдакий акт системноинженерного империализма. Но мне это не нравится). Кругозор при этом -- это просто натренированное знание того, как эти метадисциплины явлены в жизни. Ибо если не видел ни одного настоящего стейкхолдера (хотя и видел мельком Принца Гамлета, исполняемого учеником 9 класса Васей Пупкиным в учебном "проектном" спектакле, и даже задавал ему вопрос "любишь ли ты театр так же, как люблю его я?"), то со всей этой трансдисциплинарностью беда. Она в мозгах будет глубока отвязана от реальности. Что мы и наблюдаем у новоиспечённых бакалавров и в значительно меньшей степени -- у поработавших уже магистров, которые вернулись "заглянцевать своё образование" и системным мышлением овладевают в порядке упорядочивания уже имеющегося у них опыта, в порядке структурирования своего уже имеющегося кругозора.

Вот над этим и нужно думать. Вот эта трансдисциплинарность и есть проблема, делающая трудным освоение системной инженерии в целом и системного мышления в частности. И если сформулировать что-то про системный менеджмент и системное предпринимательство, то трудности будут теми же: кто поработал менеджером, тот сможет трансдисциплинарно структурировать и реорганизовать свои знания по менеджерским дисциплинам, а кто этого опыта не имеет, тому трансдисциплинарно нечего будет реорганизовывать. Трансдисциплинарное "Подогреть и перемешать" плохо работает с пустым котелком, в этом проблема. Нужны примеры того, как подогревать и перемешивать какие-то конкретные дисциплины, а затем ожидать, что будет достигнута генерализация. Если никогда не видел Принца Гамлета, то распознать его в проходящей мимо толпе будет очень тяжело. Если никогда не видел, и не знаешь о существовании системного архитектора, или не знаешь о роли предпринимателя, то опознать человека в этих ролях будет невозможно. Нужен системный кругозор (знание основных стейкхолдеров разных сфер деятельности, знакомство с основными дисциплинами этих сфер деятельности, см. тексты цепочки "Второй бакалавриат" -- https://ailev.livejournal.com/1453126.html) чтобы его опознать и вспомнить, из какой он пьесы.

В эту сторону и будем думать. И делать.

https://ailev.livejournal.com/1453619.html

https://ailev.livejournal.com/1453390.html

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

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

Жизнь в 21 веке резко изменилась даже по сравнению с концом 20 века:
-- Необходимость получать разные "магистерские специализации" резко выросла, профессии отмирают стремительно, а разным новым компетенциям приходится учиться чаще. Это означает, что бакалавриат должен быть ещё более общим по отношению к специализациям. Учить нужно мышлению, которое пригодится везде. И этого мышления чуток побольше, чем обычно дают в бакалавриате. По идее, часть такого общего мышления должны давать ещё в школе, но школа даёт уж настолько упрощённое мышление, что мы о ней и не говорим.
-- State-of-the-art фундаментальных знаний, их набор уже совсем другой, нежели был ещё в начале 21 века. Всё-таки от 21 века прошло уже 18%, человечество немного подразвилось. К моменту получения "второго магистерского высшего" знаниевый фундамент бакалавриата оказывается устаревшим. Системного мышления, например, в современных бакалавриатах нет. Личного стратегирования (чтобы поточней выбрать магистратуру для очередной специализации) нет.
-- Между бакалавриатом и специализацией пропадает "кругозор": знание того, какие вообще бывают магистерские специализации. Нужно давать общее знание о том, как поделена на дисциплины человеческая деятельность, хотя бы в самом общем виде. Или ты как-то систематически узнаёшь, что на свете есть инженеры, менеджеры, предприниматели, врачи с их основными разновидностями (врачи-гинекологи, которые отличаются от врачей-дантистов, инженеры по требованиям, которые отличаются от инженеров-архитекторов) и чему их всех учат, или просто "живёшь, набираешь опыт" -- и там либо тебе везёт, и у тебя сложится какое-то представление, или так и не сложится. Моё мнение, что кругозору нужно учить, и это должен быть системный кругозор (кругозор инженера, центрирующийся на целевой системе, кругозор менеджера, центрирующийся на обеспечивающей системе, кругозор предпринимателя, центрирующийся на использующей системе и увязке всех систем, и так далее по всем сферам деятельности).
Но деньги таки платят за прикладные знания, "магистерскую специализацию". Бакалавриат позволяет быть умным (не делать грубых ошибок в рассуждениях), ментально разворотливым (быть готовым к освоению каких-то неожиданных прикладных знаний), кооперативным (кругозор позволяет понимать, как твоя работа увязывается с работами других людей), но деньги платят таки за предметные ролевые компетенции, а не "общую сообразительность".

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

Удаётся ли научить кругозору? Или кругозор появляется лишь в ходе участия во множестве самых разных реальных проектов как "опыт жизни"? Я думаю, что удаётся -- если учить кругозору на базе системного мышления, заставлять решать задачи и применять знания к рабочим (а не учебным) проектам. Я обычно обещаю, что после моего курса "Системное мышление" весь проект как-то начинается умещаться в голове, "раскладываться по полочкам". И это действительно происходит. И студентам, и курсантам становится понятней, как, что и с чем связано в проекте, как взаимодействуют инженеры, менеджеры, предприниматели. А уж после крусов системной инженерии и системного менеджмента становится много проще договариваться в команде и с внешними стейкхолдерами, много проще планировать повышение своей квалификации -- но это ведь и есть курсы базового кругозора! Этому целостному кругозору, увы, не учат нигде -- ни в школе, ни в вузах (разве мои программы в МФТИ как то именно на это нацелены), ни на частных курсах (разве Школа системного менеджмента этим озаботилась, данный текст просто отражает текущую версию её стратегии).

Что хотелось бы добавить в текущую программу наших курсов, не по их предмету/дисциплине, а по их содержанию? Практичности: учить не только state-of-the-art дисциплины, но и давать какой-то обзор технологий (главным образом айтишных, и в том числе AI-технологий). У нас люди киборги по факту, организации киборги, целевые системы киборги. Вот это бы нужно учитывать в явном виде. Практика = дисциплина+технологии. Мы обязательно упоминаем технологии, но нужно бы это как-то акцентировать: например, давать обзоры state-of-the-art приложений, поддерживающих дисциплины практик.

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

Вот цепочка текстов на эту тему "второго бакалавриата" (раньше я это называл "системным развитием личности", но все эти тониробинсовские "тренинги личностного роста" и эзотерические варианты "духовного развития" навели такую тень на слова "развитие личности", что уже не хочется ими пользоваться):
-- тексты в цепочке "Фундаментальное образование" -- https://ailev.livejournal.com/1427073.html (тема кругозора была там поднята, начиная с "почему не работают трёхдневные курсы ни для менеджеров, ни для инженеров" -- и до конца цепочки). После этих текстов:
-- Глубокий стек абстрактности мышления -- https://ailev.livejournal.com/1442975.html,
-- Онтология сфер деятельности как основа для стейкхолдерского мастерства" -- https://ailev.livejournal.com/1443370.html.
-- Эскиз учебной программы для системного развития личности -- https://ailev.livejournal.com/1443837.html (по сути, именно это программа "второго бакалавриата", именно она в основе курса "чеклист для личного развития" http://system-school.ru/uptodate и моих последних публичных выступлений). Я обновил сегодня этот эскиз программы. Собственно, это центральный текст цепочки.
-- Список дисциплин личного развития как чеклист чеклистов -- https://ailev.livejournal.com/1446993.html
-- Бизнес-модель обучения "оплата только в случае успеха" -- https://ailev.livejournal.com/1446221.html
-- Кругозор: между прикладностью и фундаментальностью -- https://ailev.livejournal.com/1449158.html
-- Мои выступления на SECR'18 с презентацией списка дисциплин, https://ailev.livejournal.com/1448663.html
-- стратегический дыбр, в котором говорится, что темы кругозора, любопытства (а ещё эволюции, которая безлична и бесцельна), одни и те же для корпоративного и личного стратегирования, и для искусственного интеллекта -- https://ailev.livejournal.com/1452890.html
-- и текст предисловия к данной цепочке из текущего поста, в нём говорится про идею более специфичного "второго бакалавриата" вместо менее конкретного "личного развития".

https://ailev.livejournal.com/1453126.html

Самая часто рассказываемая мной история последней недели -- это как Jensen Huang оценивает деньги, которые люди готовы потратить на AI. Его история проста: опыт рекомендательных сервисов типа Netflix и Amazon показывает, что правильная рекомендация толкает людей на дополнительные покупки. В каком количестве? Примерно 30% от общего числа покупок. Трёть всех продаж идёт "по подсказке"! В пересчёте на всю торговлю это триллионы долларов. Вот если AI за счёт уточнения рекомендации сделает так, что вы не сможете отказаться от покупок ещё на буквально один процент больше (а этот один процент недополучат те, кто не использовал AI), то эти миллиарды и есть "влияние AI на сегодняшний бизнес". Поэтому вливания в AI идут, и немалые. И эти вливания уже окупаются, только выполняющие точную рекомендацию люди не понимают, что они тратят деньги по указивке AI.

Вообще, я новости разработки AI черпаю из ленты https://vk.com/deeplearning, а вот новости о применениях AI -- из других лент: https://venturebeat.com/category/ai/ и более скудной https://www.techspot.com/tag/ai/. Вот интересная история последних дней из этой скудной ленты: AI находит 94% источников риска в контрактах, а корпоративные юристы в среднем -- 85% (и AI тут находит столько же, сколько лучший из 20 юристов в опытной группе). При этом юристы в среднем тратили на пять контрактов 92 мминуты, а AI на эти же пять контрактов 26 секунд -- https://www.techspot.com/news/77189-machine-learning-algorithm-beats-20-lawyers-nda-legal.html. И такого много. Никакого GAI, никакого кругозора у роботов, торгуют узкой экспертизой. Да, это ужас-ужас, но люди с широким кругозором, опирающиеся на прикладные узкие способности роботов, могут сильно поменять сегодняшний уклад, и поменять его быстро.

Вот ещё про роботов-юристов: этот робот готов бороться с большими бюрократическими организациями, подавая на них мелкие иски в суд от имени потребителей -- и выигрывая половину из них: https://www.techspot.com/news/76870-robot-lawyer-donotpay-now-ios-app-you-ue.html. Дальше понятно, что будет: одни роботы будут готовить иски, другие защищаться от этих исков, третьи писать законы, непрошибаемые исками. Здравствуй, justice adversarial networks. Ночами робот-юрист будет бороться сам с собой в недрах суперкомпьютера, наращивая своё мастерство (ровно как боролся сам с собой компьютер, победивший людей в Го), а потом он будет бороться с юристами истцов и ответчиков -- пред бдительным оком робота-судьи. А вот бот, исправляющий программистские ошибки (конечно, прикидывающийся человеком -- https://habr.com/post/427775/).

Эти практические применения -- следствие прорывов в исследовательских работах, типа создания любопытных агентов в обучении с подкреплением -- https://blog.openai.com/reinforcement-learning-with-prediction-based-rewards/ (перевод на русский -- https://habr.com/post/428776/). Любопытные агенты в этом исследовании не просто решают задачу, но и исследуют окрестности потенциальных решений. В итоге они начинают выигрывать в игры, в которых нелюбопытные агенты ничего не могли сделать: по факту решена задача создания агента, выигрывающего в самую неподдающуюся до сих пор игру на Atari -- Montezuma's Revenge (счёт у первой программы AI, которая играла в эти игры по этой игре был 0 очков, у человека 4700, у нового алгоритма -- в среднем 10000, а лучший результат так и вообще 14500). Вот типичная картинка успехов в области задач искусственного интеллекта ("не шмогла, не шмогла, не шмогла -- ой, получилось!"):


Вчера закончил СМС2.2 -- основные тренинговые дни, остался только двухчасовой семинар во вторник. Курс опять поменялся, например, я давал вчера все три способа описания стратегий из курса (расширение целеполагания в ArchiMate, голдратовский strategy case aka strategy and tactic tree и остервальдовский стартапный холст/canvas) буквально за пару часов, а всё остальное время мы говорили собственно про стратегии и стратегирование. И добавлен был материал по кругозору, ибо "Системный менеджмент и стратегирование" по факту является кругозорным курсом по менеджменту (кроме финансов и контроллинга и corporate governance) и немного (стратегирование) предпринимательству. Рекомендуемые в нём прикладные практики нужно осваивать отдельно -- но курс даёт о них понятие, рассказывает об их существовании. И углубляет необходимое для этого менеджерского и предпринимательсткого кругозора фундаментальное содержание: понятие практики раскрывается более подробно, чем в курсе системного мышления. Группа попалась более-менее айтишная (что обычно редко на этом курсе). Мне кажется, что усвоение материала этой группой было побольше, чем в предыдущих группах: практически все члены группы рассказывали, что материал находит реализацию в рабочих проектах участников. Старт следующего потока (если считать с первой версии курса, то уже двенадцатого!) уже через пару недель.

Темы кругозора и любопытства (а ещё эволюции, которая безлична и бесцельна) и были главными темами дня "стратегирования" вчера. Идеи-то одни и те же в искусственном интеллекте, бизнес-стратегировании, личном стратегировании. Я ж всю жизнь был консультантом именно по стратегии. Но только сейчас у меня весь мой опыт стратегирования с самыми разными клиентами и со мной лично, а также мой собственный кругозор начинает раскладываться по полочкам в голове. И да, в стратегировании всё контринтуитивно. И вечная проблема exploitation vs exploration с критерием новизны в exploration. Рационально пофланировать ещё, или прекратить этот analysis paralysis и впахать во что-то одно, ни на что больше не отвлекаясь. Собственно, весь мой блог/дневник -- отражение именно этого неразрешимого вопроса для себя лично.

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

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214127894725419

https://ailev.livejournal.com/1452890.html

Фокскиз изобрёл Ronie Saleh -- https://www.facebook.com/RonieSaleh. Я побывал на паре его двухдневных мастерклассов, которые он вёл в Москве с Алёной Фортуновой (https://vk.com/event112773246). Мои заметки прошлого года (про разнообразие в кизомбе) в https://ailev.livejournal.com/1376152.html и https://ailev.livejournal.com/1376374.html, абзац впечатлений этого года я написал тут: https://ailev.livejournal.com/1450716.html. А сейчас я решил написать то, что понял на этих мастер-классах про foxkiz.

Фокскиз является попыткой Rinie Saleh объединить в одном танце два разных стилевых движка: кизомбический с африканскими шагами "в землю" и шведский фокстротый "над землёй". Рони комментировал, что привыкшим к шведскому фокстроту людям тяжело даётся основной шаг кизомбы с этим самым "в землю". Шведский фокстрот -- это не бальный фокстрот! Это самый популярный шведский социальный танец, который там знают все -- вот тут его объясняют: https://www.youtube.com/watch?v=8vMLhkVfbOg. Не обращайте внимания на шведскость языка, они достаточно выразительно показывают, и без перевода понятно. То, что эти шведы там на видео делают в самом конце, и впрямь очень похоже на foxkiz "вариации на трёх движениях", демонстрировавшеся Рони, вот её видео: https://vk.com/video247400234_456239132. Но, конечно, просто фокстрот, просто кизомба и фокскиз отличаются стилем. Всего я различил в фокскизе три важных элемента.

1. Слайды. При всей простоте исполнения, фокскизовские слайды хранят некоторые секреты. И это не то, что при глайде медленно приставляемая нога идёт по полу (на чём настаивал всё время Рони). Главный секрет в том, что интенция кизомбы "в пол" преодолевается, и вместо просадки на бедро идёт наоборот -- неспешный, с некоторым даже зависанием в верхней точке, фокстроный подъём вверх. По сути, foxkiz танцуется на трёх уровнях: вниз, с просадкой на бедро (как true кизомба), строго в сторону (ни рыба ни мясо, ни в землю, ни в небо), и вверху (с вытяжкой вверх, как в европейских танцах, в том числе и в шведском фокстроте -- легко, "над полом"). И в этом гениальность Рони Салеха: он разрешил смешивать стилевые движки кизомбы и европейский, использовать в одном танце оба движка (про стилевые движки см. тут: https://ailev.livejournal.com/1373388.html -- и там по первым ссылкам, плюс примеры таких же новаторов из кизомбы). Но если вы не не понимаете все эти "в пол" и "танцуют не на паркете, а над паркетом", то вы эти слайды с трудом поймёте. Мне свезло: Алёна Фортунова (https://vk.com/id247400234) тренировала нас делать эти "слайды на трёх уровнях" пару месяцев, ещё после первого приезда Рони. А Саша Сирото (https://vk.com/alexsiro) растолковала мне на языке биомеханики, что же там делается "в пол" и почему так важно ведение грудью (не "корпусом", как говорят по-русски, а именно грудью -- chest, грудная клетка в ведении элемент номер один, как говорил на мастер-классе Рони. Ведут солнечным сплетением, а не животом, как все в России понимают "корпус"). Итого у меня как-то эти "слайды на трёх уровнях в двух стилях" сложились -- танцую я их не как таксист или препод, конечно, но танцую.

2. Hard stop со сменой направления: комбинация, которую Рони назвал lift-tension-direction. Рони объясняет это в терминологии "трёх энергий". Он бы ещё заново какие-нибудь элементали изобрёл, или вибрации или ещё какую-то эзотерическую невнятицу. Ибо его рассказ и танец ни разу не про энергии. Увы, "образность" вызывает в ходе показа интерес, но только иллюзию понимания. На самом деле в этих "точках/блоках", которые надо ставить вверху (это ж фокстрот -- lift этот как раз указывает, что никакой просадки на бедро, танцуем шаг вверх, "над паркетом") речь идёт о специфической мышечной координации натяжения — работе глубоких не слишком крупных мышц, обеспечивающих вытяжение рук-ног-спины. И вот tension — это как раз оно. Если этого не понимаешь, то любой перевод не поможет (в переводе ведь будет слово "энергия" из эзотерического словаря, так?). И никакого lift-tension-direction не будет, ибо в самом объяснении слово tension не напряжение (крупных мышц), а вытяжение — при расслаблении (а не тонусе!) крупных мышц. И это tension как раз основа "третьей энергии", но Рони этих подробностей исполнения не объясняет. Кто знает (я знаю из занятий с Антон Климат), тот сделает, а кто не знает, тот не сделает: усилия напряжения (деревянный дубок) и натяжения (гибкий трос) абсолютно разные. Ну, и нужно ещё уметь эти усилия сделать быстро в точке останова, а не раньше, и мгновенно снять их после перенаправления, музыка-то играет, она не ждёт, в танце всё быстро. И вот эта мышечная координация точно за пару часов мастер-класса не может быть выучена. А ещё должны быть подкачаны эти специфические мышцы-вытяжители. У опытных танцоров они подкачаны "сами собой", а у не очень опытных — нет. Вот и воспроизведения материала на семинаре не было, тела партнёров не позволяли это всё делать. Я воспроизвёл это (и партнёрши удивлялись: передо мной они проходили пять-шесть партнёров, которые не могли делать этот hard stop с перенаправлением), но только потому, что мне свезло: про эти все "натяжения" вместо "напряжений" (то есть как делать упругий блок, а не "дубовый") я знаю из классов Антона Климата (https://vk.com/klimat).

3. А ещё в прошлом году Рони показывал (но это как-то пролетело мимоходом и не было особо мной замечено, так что спасибо Алёне Фортуновой, которая некотрое время после его мастер-класса нам это разжёвывала) фокстроные дорожки из поворотных саид -- с теми самыми фокстротными бальными/европейскими зависаниями "вверх" в конце этих дорожек. Хинт тут в том, что со стороны партнёра идёт управление инерцией пары: подруливание, а не перетаскивание себя и партнёрши "на мышцах". Фишка в том, что партнёрши в этих саидах не столько "проворачиваются", сколько проходят повороты на шагах -- и каждый поворот оказывается в конечном итоге на 360 градусов, и дорожка продолжается в движении по прямой. Или на 180 градусов, и тогда можно возвращаться по этой же прямой назад. Я люблю делать такие дорожки на краю зала -- между стоящей публикой и танцующей серединкой. Обычно это узенькая дорожка, буквально в метр шириной, и приходится быть довольно точным с доворотами, чтобы удерживаться на прямой траектории. С хорошими партнёршами это обычно получается довольно легко, а с начинашками до этого дело обычно не доходит -- с ними обычно и одной поворотной недовёрнутой саиды более чем хватает, чтобы это было сочтено "лихостью".

Я люблю танцевать фокскиз, в моём списке "предпочтений/конкурентных преимуществ" (https://ailev.livejournal.com/1448326.html) он занимает солидное место.

Картинка для отвлечения внимания (я в ходе исполнения одной из фишек, подхваченных у Ronie Saleh в этот его приезд -- заметна рука на спине партнёрши, это как раз элемент этой фишки. Мне трудно, но партнёрше, как видим, хорошо!):

https://ailev.livejournal.com/1452638.html

Вчера провели в Школе методсовет по SysMoLan.

Сначала обсудили тренды в моделировании данных/schema design (см. тут наблюдения Pascal Desmarets, CEO Hackolade -- Agile Data Modeling for NoSQL Databases, https://www.infoq.com/news/2018/10/agile-data-modeling-nosql. Conceptual data model has been replaced by domain-driven design (DDD), logical data model is no longer needed, and physical data model is replaced by physical schema design. It is critical to design data models that are application-specific, so you store information in a way that optimizes query performance. This mind shift can be a challenge for those who have been applying the principles of application-agnostic data modeling for decades. For many of us, the rules of normalization have become second nature, and we have to force ourselves to apply a query-driven approach to schema design for NoSQL databases. И далее там всё в таком же духе. Ведь трёхсхемная архитектура -- это 1987 год, за тридцать лет накопилось претензий).

Второй вопрос -- это отношение к уровню формальности и уровню абстрактности языка. Язык в его ядре должен быть не формальней Архимейта, ибо слишком формальные онтологии очень плохо садятся на предметную реальность. И язык должен быть не абстрактней Архимейта, ибо всякие более абстрактные Upper Ontologies доступны не инженерам, а онтологам -- а прикладные шаблоны, библиотеки и что там ещё может быть в них оказывается всегда "потом". Начинаем с прикладного уровня, а потом переписываем формализацию, если приспичит: так создавались все плохие, но в какой-то момент попсовые языки (UML, XML, HTML и т.д. -- первая версия неформальная, а в какой-нибудь четвёртой версии наводилась формализация).

Что мы закрываем? По диаграмме семи альф мы закрываем область интересов предпринятия/оргпроекта (её закрывает сегодня ArchiMate), область интересов инженерного решения (её закрывает сегодня SysML/AADL в части моделирования целевой системы и ISO 42010, в котором и языка-то нет -- и тут предложено поддержать эти объекты явно, сделать по аналогии с гомоиконными языками программирования гомоиконный язык моделирования. То есть в явном виде поддержать все эти view, viewpoint, model, model kind, correspondence rules и т.д., и на пару-тройку уровней viewpoints, чтобы показывать "гирлянды языков"). Дизайн цель SysMoLan -- чтобы можно было на одной диаграмме показать и целевую систему, и кто чем в этой целевой системе занимается в обеспечивающей системе. Сейчас такого языка нет, а дизайн-цель очень похожа на дизайн-цель Архимейта: тот создавался тоже, чтобы показать на одной диаграмме и организацию, и IT-решение (и в нём и софт, и железо). Область интересов клиента обычно показывается расширением целеполагания Архимейта, и мы это тоже должны поддержать.

Тем самым ставится задача создать по возможности компактный (я целюсь тут примерно на 30 концептов) язык системного моделирования, который будет показывать части системы, части предприятия и как-то отражать другие модели -- и при этом мы от риторики и сленга "моделирования данных", "интеграции данных жизненного цикла" перейдём к более инженерной риторике моделирования, а именно мультимодельного определения и описания системы. То есть мы не "данными" будем заниматься, а инженерными содержательными вопросами. Попробуем избавиться от типичного птичьего модульного языка айтишников и поговорить функциональным содержательным языком системного подхода, инженерным языком, менеджерским языком. Это трудно, но очень хочется этого добиться. Ибо как вы лодку назовёте, так она и поплывёт. Если назовёте "интеграция данных", то сколько не повторяй "жизненного цикла", ни одного инженера рядом не будет, будут сплошные айтишники. Как тут не вспомнить мудрого Захмана, который из архитектуры предприятия версии 3 убрал модели данных, обосновывая это тем, что на эти слова директор немедленно вызывает CIO, после чего умывает руки, и вместо архитектуры предприятия дальше обсуждается только архитектура IT-решения и та самая архитектура данных. А вот нам нужно, чтобы вся эта канитель с данными и онтологами была закопана глубоко внутри, а снаружи был интерфейс к инженерам. Обсуждаем системы и их модели, а не данные про системы и данные моделей. Эту мысль нужно ещё обдумать. AADL (не хочется тут приводить в пример SysML) и ArchiMate -- оба не языки моделирования данных, и поэтому у них был шанс.

Была также высказана осторожная гипотеза, что по пути Upper Ontology (одной на все модели, непобедимой и неусомневаемой) мы вряд ли сейчас пойдём. С одной стороны, все PLM по факту реализовали эту модель -- с точностью до того, что у каждой из них была своя Upper Ontology, и она была а) не слишком хороша, чаще всего объект-ориентирована, б) уровень её был обычно менее абстрактный, чем в ISO 15926, в) всё одно нейтральных по отношению к вендорам онтологий не найти, а свою делать -- запредельно дорого, г) результирующие схемы "интеграции данных" оказываются запредельно дорогими, и итог всё одно -- интеграция "точка-точка". Это дешевле, "микросервисней", не плодит метамодельных монстров, проще дебажить, более инкрементально в плане реализации и т.д. Как с этим быть? Как кодировать смысловое пространство совмещения языковых моделей (это я говорю про ту же проблему, только примерно как это обсуждается в deep learning и NLP)? Это требует дополнительных размышлений. Но проектов, которые без госфинансирования, и с развитой upper ontology (и библиотеками справочных данных, согласованных с этой upper ontology как необходимое продолжение идеи!) -- их по пальцам посчитать можно, и это не случайно. Agile, кругом agile, что не agile, то почему-то не выживает.

Цепочка текстов по SysMoLan -- https://ailev.livejournal.com/1443879.html

UPDATE: комментарии в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214109582867634

https://ailev.livejournal.com/1452502.html

Сегодня-завтра вечером тренинг по чеклистам дисциплин для личного развития (http://system-school.ru/uptodate). Наш маркетинг говорит, что с ним всё плохо, ибо надо говорить не "для личное развитие", а "фундаментальное образование" или ещё как-нибудь по-другому: слова "личное развитие" обесценились окончательно в ходе последней гастроли Тони Роббинса, и уже никому не расскажешь, что "личное развитие" это пахота по освоению совершенно конкретных содержательных учебных дисциплин (по списку в https://ailev.livejournal.com/1443837.html), а не бессодержательная мотивация себя на неважно какие дела. Содержание тренинга -- это примерно удвоенное по объёму совокупное содержание вот этого: https://ailev.livejournal.com/1448663.html. Большинство записавшихся будут в онлайне, москвичей придёт не очень много, а вещать (и делать запись) я буду из офиса Школы на ул.Щипок, 11.

В это воскресенье уже заканчиваю второй поток шестидневного марафона "Системного менеджмента и стратегирования v2", сегодня в очередной раз переделываю для него слайды. А уже 18 ноября 2018 стартует третий поток: http://system-school.ru/sms.

7 ноября 2018 на совместном заседании методсовета ШСМ и Русского отделения INCOSE попробуем финализовать соглашение о моделировании SysArchi (https://ailev.livejournal.com/1444887.html). Событие вот тут: https://www.facebook.com/events/1064520270382010/.

У студентов МФТИ в этом семестре остался экзамен: сдача эссе. В середине ноября с очередным семестром "Системного мышления" будет покончено. Но некоторые ещё и учебника не прочли. Я пытался пожаловаться одному из преподавателей, что по моему курсу учебный план выполняют ну очень немного студентов, а он лишь отмахнулся: на его курс ещё и не все получили регистрацию! МФТИ сегодня -- это бледная тень от того МФТИ, что был буквально несколько лет назад, в 2012, когда начиналась вся эта образовательная затея с системной инженерией и системным мышлением. Оценки по моему предмету все получат справедливые -- наверняка двоек будет половина. Самый продвинувшийся студент заметил, что он хорошо понимает, зачем ему мой курс, и в чём этот курс ему помогает: он уже инженер и имеет какой-то опыт разработки. А вот с бакалаврами без кругозора беда: они уже успели понять, что курс сложный, но они абсолютно не понимают, какие проблемы в жизни решает этот курс -- ибо всё, что они в жизни видели, это "учебные проекты". А учебные проекты можно обычно делать безо всякого системного мышления, да и безо всякого мышления их тоже можно делать, они ж учебные! И тем самым они этот "сложный, но непонятно, зачем он вообще" курс системного мышления они сачкуют. Ну, кто сачкует, тот сам себе злобный Буратино. На консультациях и семинарах мы разбираем их проекты -- определяем целевую систему. Их там тренируют на то, что их целевая система -- стартап, оказывающий какой-то сервис. Но это типовая ошибка менеджера. И каждый раз, когда мы находим целевую (а не обеспечивающую) систему в их проекте, то у студента возникает инсайт. Студент за студентом: проходим по всем типовым граблям-ошибкам, а затем инсайт. Видеть эти инсайты -- очень приятная штука, поэтому и соглашаюсь быть преподом.

Думаю, не сделать ли мне курс "Чеклисты по кругозору инженера, менеджера, предпринимателя", где рассмотреть чуть подробней тему кругозора — рассказать обо всех входящих практиках и их state of the art, по три часа рассказа на каждую сферу деятельности. В курсе я бы раскрыл содержание пункта два из списка https://ailev.livejournal.com/1443837.html -- на уровне основных понятий каждой практики. По факту у меня уже есть системная инженерия и менеджмент, и даже отчасти предпринимательство (стратегирование). Туда добавить какой-то сверхкраткий (три часа!) обзор других сфер деятельности. Такого курса IMHO вообще нигде нет -- ни в школе, ни в вузе, ни в частных образовательных учреждениях. Увы, краткого верхнеуровневого рассказа о человеческой деятельности в целом нет. Этот кругозор получается просто путём участия в разных проектах, работы в разных организациях, чтения разной случайной литературы. Идея в том, чтобы дать способ компактно обо всём этом думать: рассказать о паре десятков практик -- чем каждая из них занимается. С надеждой, что весь этот набор практик станет осознанным и как-то начнётся помещаться в голове. И можно будет определяться, в чём и как профессионализироваться. Кругозор, он и есть кругозор.

По SysMoLan и SysMoLan Studio написал большую серию постов по онтологизированию-моделированию, в последнем посте вышел на идею системной мереологии в отличие от формальной мереологии (https://ailev.livejournal.com/1451832.html). И одновременно опубликовал в фейсбуке фотографию своего выступления на SECR как cover foto, https://www.facebook.com/photo.php?fbid=10214090583712667&set=a.10202726060406687 (я уж совсем не похож на себя пятилетней давности с последнего фото, и решил заменить картинку). Пост по мереологии на настоящий момент (11 часов с момента публикации) получил в фейсбуке 12 лайков, фотография 49 лайков. Ну да, я устный и визуальный совершенно другой, нежели письменный -- и понятней вчетверо. Это и без подсчёта лайков было известно.

А вот как я выглядел неделю назад:

https://ailev.livejournal.com/1452149.html

Мой предыдущий пост про онтологии и SysMoLan https://ailev.livejournal.com/1449992.html поминает попытки онтологизации системной инженерии (прежде всего ST4SE), там в основе BFO 2.0. Работы Peter Simons (о них чуть ниже) показывают, что BFO негодная онтология для инженерных задач, её нельзя класть в основу инженерного моделирования: ибо она формально-мереологическая (мереология -- это дисциплина, обсуждающая отношение части и целого), рождает монстров. Как математика: она может выразить и те физические законы, которые красивы на бумаге, но которые в природе не наблюдаются. Вот теоретическая мереология ровно такая: красивые логические формулы, никакой связи с жизнью.

Корова Маргарита имеет своей частью хвост, корова Маргарита является частью коровьего стада. Нехорошо позволять говорить, что коровье стадо имеет хвост, хотя это вроде как мереологически корректно. Это корректно, но не системно, и это вроде как интуитивно понятно всем. Но интуитивно непонятно, можно ли говорить, что карбюратор -- часть автомобиля. Он отдельная часть автомобиля, или он часть топливной подсистемы, или часть двигателя?! Но вот говорить, что поршень или цилиндр двигателя это часть автомобиля -- интуитивно понятно, что это тоже неправильно, хотя "формально верно". Эмерджентность: обсуждение автомобиля требует обсуждения двигателя, но есть ли там внутри поршень -- это неважно. Управляем вниманием: на каждой границе системного уровня меняется интерес, меняются объекты внимания. Меняются ведущие дисциплины, меняется тусовка, поддерживающая разговор. На одном уровне обсуждаем хвосты и рога в корове (со всей проблематичностью выделения их как частей с определёнными границами!), на другом целых коров, быков в составе стада в целом. На одном уровне обсуждаем двигатель и салон, на другом -- поршень и цилиндр в двигателе. Разные интересы, разные языки, разные стейкхолдеры (в том числе роли которых обычно играют разные люди). Деление на части для системного подхода важно. Мереология для системного подхода важна.

Понятие "система" первого поколения привносит прежде всего понятие системного уровня с эмерджентностью. А второе поколение привносит понятие жизненного цикла со стейкхолдерами (ибо даже роботы яиц не несут, и эти системы нужно целенаправленно кому-то делать, кроме целевых и использующих систем есть обеспечивающие системы). Управление вниманием: что важно в целевой системе, что важно в её системном окружении (systems in operation environment -- системы времени работы готовой системы, функционирования/эксплуатации), что важно в части её появления на свет и последующего исчезновения (enabling systems, обеспечивающие системы).

Композиция (composition, отношения части-целого, дающие холархии) времени функционирования и процессы времени жизненного цикла ("от замысла до исчезновения/вывода из эксплуатации") -- вот это системный подход. И жизненный цикл со всеми его стейкхолдерами/интересантами определяет композицию/холархию. Делить на части систему нужно так, чтобы было удобно обсуждать эмерджентность.

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

Вот, например, свежие работы онтологов из команды ISO 15926 (последние апдейты тут -- июня 2018) по интеграции данных жизненного цикла: http://15926.org/topics/plant-lifecycle-model/index.htm. На диаграмме 81 онтологический объект, необходимый для обсуждения жизненного цикла какого-то объекта в непрерывном производстве (химзаводы, нефтепереработка, электростанции и т.д. -- где есть какой-то круглосуточный проток газов и жидкостей, и насосы и вентили в количестве). Можно обсуждать, насколько это общий случай, и насколько нужен такой уровень онтологического аннотирования, т.е. насколько по таким диаграммам можно проводить содержательные обсуждения жизненного цикла, а не только содержательные обсуждения онтологии жизненного цикла (типов) и данных жизненного цикла (данных об индивидах жизненного цикла). Меня это волнует: насколько уместен выбранный уровень абстрактности описания данных жизненного цикла и возможно ли по этим данным обсуждать сам жизненный цикл? Что содержательное могут обсуждать люди, интегрирующие данные? Это же данные: в них важна форма и логистика -- где взять, куда отдать, с чем отождествить. Это отдельная стейкхолдерская позиция, там свои интересы. И вот системный подход как раз может задать какие-то критерии для ограничений тамошнего моделирования: уровень в стеке абстрактности (на котором нужно обсуждать эмерджентность), место в спектре формальности (на котором уже можно как-то объединять формально-логически несовместимые view), уровень декомпозиции в системной холархии (опять же, для удобного обсуждения эмерджентности -- чтобы по разные стороны системного уровня говорить на разном языке). По этой линии можно брать моделирование системных холархий из самого ISO 15926, из HQDM от Matthew West, или опираться больше на работы Chris Partridge по BORO (нужно же и об инженерии предприятия не забывать! книжка по большей части об этом), но у него там есть и работы по DM2 (онтология для систем в NATO, она ведь и для инженерных систем).

А вот ещё один заход, в этот раз против классической философской/онтологической мереологии в пользу практической инженерной мереологии, возглавляет его сейчас Peter Simons (и поддерживает лично John Sowa): https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwZXRlcm1zaW1vbnN8Z3g6MmY0YmVjNThiYjM1N2VmZA коротко и полный отчёт (110 страниц) Charles Dement сотоварищи (причём без Симонса) по программе MEREOS 2000 года http://jfsowa.com/ikl/Dement01.pdf (постановка задачи на мереологию рабочих продуктов/артефактов в отличие от мереологии природных объектов -- то есть соотнесение мереологии и деятельности), http://www.tara.tcd.ie/bitstream/handle/2262/75103/Varieties%20of%20Parthood%20Compact.pdf это 2013 год с формулированием требований к отношению часть-целое. И вот в этом последнем тексте уже есть интересности, прямо указывающие на необходимость системного рассмотрения в отношении части-целое.

Многие из указанных в последнем тексте мереологических особенностей (типа "дырок" как частей системы) есть даже в моём учебнике. Но вот для полноценного моделирования нужно ещё и более детальное рассмотрение features (дно стеклянного стакана -- нет границы с остальным стаканом) и parts (отдельной части, где граница чётко определена какой-нибудь "сборкой"), а также частей в каких-нибудь материалах (например, золях, гелях или суспензиях, или микрокристаллов в металлическом сплаве).

Главное, на что указывает Simons в этом последнем тексте -- это то, что физические части имеют каузацию (ещё бы! Обсуждаются ведь артефакты, и каузация очевидна). Таким образом деление на части не произвольно, а привязано к пониманию причинно-следственных отношений. Это означает, что отношения часть-целое нужно рассматривать не сами по себе, а в привязке к каким-то схемам причинности. И хорошо определяемые отношения часть-целое, похоже, как-то должны использовать особенность человеческого мозга быть неплохим вычислителем причинности -- иначе они будут не слишком полезными, системный подход будет не способствовать хорошему мышлению, не сможет задействовать эту особенность человеческого мозга. Подробности про мозг как вычислитель причинности можно поглядеть в книге The Book of Why, о которой я писал в "ложь, наглая ложь, и причинный вывод (causal inference)" -- https://ailev.livejournal.com/1435703.html.

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

В принципе, это продолжение современными онтологами линии прагматического поворота в философии (работы Charles Sanders Pierce, любимый философ у John Sowa), а обращение к жизненному циклу -- это продолжение линии "процессной онтологии" (Alfred North Whitehead -- любимый философ у Peter Simons).

И тут мы должны вспомнить и о процессной онтологии ISO 18627 https://www.sciencedirect.com/science/article/pii/S1474667016375371 и о многочисленных похожих работах, которых гугление выдаёт десятками.

А уж если сюда включить близкие работы по interoperability (все они так или иначе пытаются определить взаимодействие между системами, которое относится к какому-то уровню системного рассмотрения), то этих работ и вовсе запредельное количество -- см., например, недавний обзор моделей взаимодействия https://www.sciencedirect.com/science/article/pii/S2452414X17300687

И нужно ещё учесть, что при рассмотрении модулей выделяют не просто отношение composition, но и два свойства ("модульность" -- https://ailev.livejournal.com/1294242.html):
-- компонуемость (composability) -- это про возможность сложить целую систему из частей-подсистем. Модульный аспект сборки, компоновки, создания холархии: интерфейсы воткнутся друг во друга, целая система, собранная из подсистем, заработает. Обратите внимание, что "выращиваемые" системы не компонуемы! Их не соберёшь из частей, и хотя в них тоже присутствует холархия, нельзя сказать, что на неё как-то существенно можно влиять, отдельные модули не взаимозаменяемы путём подключения к известному интерфейсу, требуются разные "врастания".
-- композициональность (compositionality) требует некоторого "композиторства" -- речь идёт о свойстве собранного из частей целого обходиться без неожиданной эмерджентности типа отрицательных побочных эффектов. Система композициональна по какому-то свойству, когда её это свойство напрямую трассируется к свойству отдельных модулей. Это хитрое антисистемное понятие, потому как целая композициональная система в отношении какого-то свойства не больше суммы своих частей, а равна сумме своих частей! Композициональная система имеет какое-то свойство, если её модули имеют это свойство, поэтому для композициональной системы простая сборка её из обладающих каким-то свойством модулей будет означать доказательство того, что вся система обладает этим свойством. Если модули системы критичны к работе во времени и требуется их синхронизация, то создать систему, синхронно работающую "в силу конструкции", обычно нельзя. Так что свойства с плохой композициональностью обычно попадают в список интересов стейкхолдеров отдельными пунктами и в проектах им уделяется много внимания.

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

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

При создании SysMoLan (цепочка: https://ailev.livejournal.com/1443879.html, ) нужно тем самым:
-- определиться с системной мереологией: какие свойства и ограничения на отношение "часть-целое" накладывает системный подход (с его эмерджентностью и жизненным циклом. Прагматизм, каузальность, вот это всё). Понять, какие тут возможны онтологические выборы.
-- сосредоточиться и решить, на каком уровне формальности и в рамках какой онтологической парадигмы определять отношения часть-целое в SysMoLan.
-- уточнить всё для программных объектов, ибо маловато будет сказать, что "программа тоже объект" (у нас же киберфизические системы!)
-- а ещё при этом нужно будет договориться и о том, как именовать/обозначать (designation) части, связываемые в сопряжённые холархии целевых и обеспечивающих систем этими "хорошо определёнными" отношениями композиции: полными именами? бессмысленными уникальными идентификаторами? составными (по системным уровням) кодами как в IEC81346? как именуют части системы в программной инженерии -- но там же везде по-разному, и если про модули всё понятно (системы управления версиями рулят!), то про функции и размещения уже не очень?!

И помним про коннективизм и вероятностные онтологии, связанную с ними корпусную инженерию (https://ailev.livejournal.com/1009201.html),
различие и похожести задач моделирования данных (для целей интеграции данных жизненного цикла, как в ISO 15926, а краткий обзор state of the art в моделировании данных см. в https://ailev.livejournal.com/1451630.html) и системного моделирования (для целей системного анализа и модульного синтеза в ходе инженерии требований и инженерии системной архитектуры и архитектуры предприятия как обеспечивающей системы -- цели как в SysArchi, https://ailev.livejournal.com/1444887.html, SysML, AADL).

И без хоть каких-то решений на этом пути создавать SysMoLan Studio (https://ailev.livejournal.com/1446524.html) -- это пополнять бесконечное число неудачных моделеров (ибо шикарная IDE для убогого языка не будет никогда шикарной). Помним, что архитектурно там получается несколько разных уровней договорённостей (https://ailev.livejournal.com/1451630.html?thread=15915374#t15915374):
-- Пользовательский интерфейс: IDE для exploratory modeling. Выбор хост-языка (предполагаю, что это Julia).
-- Метаметамодель, языковые вопросы: формализм языка (foundational ontology). На каком языке работаем? Парадигма и синтаксис: виртуальная машина, поддерживающая моделирование.
-- Метамодель, и к ней онтологические вопросы: описание системы, т.е. онтология системы + полноценный онтологический язык/язык моделирования данных для интеграции данных жизненного цикла (частных, несистемных описаний). И вот тут upper ontology, онтологические паттерны и прочий разговор не про форматы, а про моделирование мира. Вот особенность SysMoLan главным образом должна быть тут, но без понимания, на каком холсте эту онтологическую картину рисуем (т.е. foundational ontology и способ алгоритмической с ней работы) до этого не договоримся.
-- Модель (в которую плавно переходит метамодель): middle ontology (сами пишем системную модель), описания domain ontology (подключаемых к системной модели уточняющих её частных описаний в разных форматах разных CAD и систем моделирования).

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

По опыту предыдущих заходов на такие проекты понятно, что это работа практически full time десятка активных грамотных инженеров и онтологов лет эдак на пять. При этом нет ни ресурсов на такую работу (обычно её спонсируют какие-то промышленные консорциумы, но это не про нас), ни пяти лет: за пять лет каток искусственного интеллекта глубоко и тяжело пропашет и онтологику в целом, и мереологию как её часть. А хоть и инженерную мереологию как она бытует в среде инженеров сейчас (например, IEC81346 стал очень популярен в BIM -- и за счет этого BIM стал по факту много системней), не дожидаясь, пока "народная инженерная мереология с де-факто вкраплениями системности" будет доработана до хоть какой-то консенсусно определённой "хорошей системной" (то есть удобной для управления вниманием коллектива стейкхолдеров при мышлении о проекте -- системный подход ведь для этого!).

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

https://ailev.livejournal.com/1451832.html

Концептуальное/онтологическое моделирование можно встретить:
-- в онтологическом моделировании на языках моделирования знаний
-- в системной инженерии и инженерии предприятий на архитектурных языках
-- в моделировании данных на языках моделирования данных
В онтологических языках победил OWL и осталась мечта о Common Logic (ISO/IEC 24707:2018 -- https://www.iso.org/standard/66249.html). В архитектурных языках победил SysML и частично AADL, но бытует и Capella и в каждом PLM вендор считает за честь представить что-то своё на эту тему, а в архитектуре предприятия тоже много всякого, но лидирует ArchiMate. В языках моделирования данных в какой-то момент победили ER-диаграммы (допотопный Express за язык не считаем), и ещё пяток лет назад был настрой двигать в сторону RDF/OWL (semantic web, все дела). Но тут безо всякого web появились в количестве NoSQL, и табличные представления сначала отползли (No SQL), а затем вернулись (Not Only SQL) -- оказалось, что моделирование данных в дикой жизни стало мультипарадигмальным. При этом OWL никак не решал задач моделирования данных, ибо провести пальчиком от концептуальной модели хоть куда-нибудь в данные и уж тем более в физику не представлялось возможным. И тогда вспомнили о наследниках линии NIAM/ORM -- факт-ориентированного моделирования. Кому хочется теории связи онтологического моделирования и моделирования данных -- вот я писал ещё в 2011 году "ну, и какая у нас онтологическая традиция?", https://ailev.livejournal.com/952930.html. Про факт-ориентированное моделирование -- ещё в 2009 году, https://ailev.livejournal.com/699549.html.

Мультипарадигмальное моделирование данных с упором на факт-ориентированное представление (и очень часто с упором на графовые представления) -- это относительно свежий тренд, и тут пока не слишком много инструментария, но он есть, и он продолжает линию ОRM и моделирования данных, а не OWL и представления онтологий или представления архитектур. Всё в онтологизировании, моделировании систем, моделировании данных очень похоже, но отличия таки есть.

COMN (произносится common, Concept and Object Modeling Notation) -- это мультипарадигмальный язык моделирования данных, который явно решает онтологические задачи, но он так и не взлетел: для него до сих пор не нашлось изготовителей моделера. Но это один из идеологических лидеров направления. Вот его гнездо: http://www.dataversity.net/concept-object-modeling-notation-comn/. Вот свеженькое интервью создателя по итогам семинара на Data Architecture Summit Conference 2018 -- https://www.infoq.com/news/2018/10/hills-data-modeling-nosql-comn. Вот книжка автора, подробно всё описывающая (чем-то напоминает книжку BORO -- отчётливо виден онтологический заход на моделирование данных и забегание даже в архитектурное моделирование. Обсуждается подробно таинственное отношение "репрезентации"): Ted Hills, NoSQL and SQL Data Modeling: Bringing Together Data, Semantics, and Software -- http://b-ok.cc/book/2972540/e75b65. COMN имеет цель примерно ту же, что ArchiMate -- чтобы можно было вести пальчиком по разным уровням моделирования, отслеживая на диаграмме (визуальный язык, увы) путь презентации-репрезентации от реального объекта к концепту, от концепта к данным, от данных к физическому представлению в компьютере.

Пару лет назад COMN хотел поддержать разработчик мультипарадигмального моделера данных Hackolade -- https://hackolade.com/. Но так и не поддержал, ограничился дизайном схемы для самых разных баз данных (document, graph, column-oriented, key-value, multi-model и даже JSON), причём не только forvard engineering, но и reverse engineering в этом моделере тоже есть, за что его и любят. Но нам этот моделер не так интересен, кроме его особого внимания к reverse engineering. Я помню, как пару недель назад в одном разговоре большой айтишный начальник мечтательно говорил, что хорошо бы найти такой инструмент, который всосал бы в себя весь имеющийся зоопарк описаний данных и красиво показал в таком виде, что можно было бы разобраться. Вот этот Hackolade целится как раз в эту потребность.

И таких мультипарадигмальных NoSQL моделеров данных существует некоторое количество. Вот тут страничка с залом славы (hall of fame) моделеров для графовых баз данных: http://graphdatamodeling.com/Graph%20Data%20Modeling/HallOfFame/DMHallOfFame.html. Туда попали, конечно, не все моделеры -- а только визуальные моделеры для графовых баз данных. Эта страничка полезна, чтобы понимать богатство экосистемы NoSQL моделирования данных, где отнюдь не всё сегодня сводится к ER-моделированию. Превалируют, конечно, разные реализации моделеров для GraphML -- поэтому чаще всего там можно встретить "графы знаний" как форму моделирования самых разных данных.

Но нас там интересует поиск моделеров с какими-то более-менее универсальными языками представления данных, а не просто моделеры создания схем данных для конкретных графовых СУБД. Например, моделер Factil, предназначенный для решения задач интеграции данных -- https://www.factil.io/. В этом моделере используется FIML -- Fact-based Information Modeling Language, факт-ориентированный язык, прямой наследник ORM. И там даже делается упор на текстовое представление, при этом история очень похожа на историю XML (которым стал SGML после обрезания, если кто помнит). ORM (Object-Role Modeling, создан в 90х) имел текстовую и графическую нотацию, а в 2008 году был создан уже CQL, который текстовый ORM с возможностью запросов. FIML -- это обрезанный (подмножество) CQL, хотя и с расширениями в сторону задач интеграции данных. Вот кратенькое описание: https://www.factil.io/introduction-to-fiml.

Понятно, что RuleXpress (множество идей из CQL было использовано в SVBR -- я и об этом писал в 2009 году, https://ailev.livejournal.com/692588.html и там получился свой онтологический язык для выражения business rules и моделер для его поддержки) тоже в этом списке: http://www.rulearts.com/. Не могу не напомнить манифест организационных норм -- https://ailev.livejournal.com/693597.html. Это ж как раз оно, онтологическое моделирование предприятий и то, как нужно в организации эти онтологии использовать. И довести эти онтологии до данных в корпоративных базах данных, как же без этого.

Это я всё продолжаю не столько бежать к цели (SysMoLan), сколько медленно ползти к ней, или даже просто лежать к ней. Ибо по линии развития онтологических языков мы уже ходили, по линии архитектурных языков ходили, а вот по линии языков моделирования данных -- пока нет. Нам же нужно описывать систему, пробегая по всей цепочке от реального мира через концепты к представлению этой системы в каких-то данных. С этим нужно ещё как-то подробней разобраться, с этой идеей "одного языка, на котором можно отследить связи разных уровней моделирования" -- как в случае Архимейта с его уровнями организации/концептов-софта/данных-железа/носителей.

Ну, и чтобы два раза не вставать: мне не нравится доминирование визуальных языков моделирования данных над текстовыми языками. Вся эта история будет немасштабируема, описывать даже небольшие системы будет плохо. А ещё меня смущает не слишком большая развитость этих языков (до SQL, который в конце концов допилили до полнотьюрингового "просто языка программирования", в этих факт-ориентированных языках моделирования данных пока далеко). Но мне нравится, что цель моделирования данных в этих языках хорошо видна, в отличие от OWL. Хотя в этих языках и плохо с модульностью, всё одно придётся её как-то там наводить.

И тут будет уместно вспомнить историю про скриптование в определении сложных 3D моделей на геометрическом движке, где начиналось с графических интерфейсов, а потом таки пришло к текстовым интерфейсам на сниппетах программного кода: началось с "революционного" графического интерфейса в Antimony (https://justy-tylor.livejournal.com/254781.html), но потом там было продолжение и появился абсолютно уже текстовый https://www.mattkeeter.com/projects/ao/ для programmatic computer-aided design, там посыл был "You can think of Ao as a homoiconic kernel: even fundamental, primitive shapes are represented as code in the user-level language. It's turtles all the way down" — всё там на Scheme. А после него и вообще текстовый с подходящим случаю интерфейсом http://libfive.com/. 3D модель появляется в результате описания её скриптами, которые её строят. Вот я чешу затылок, чем такое может отличаться от модели данных. И можно ли воспользоваться homoiconic kernel на Julia, где всё про гомоиконность было слизано в этом месте из того же источника -- из Lisp. Вот в таком стиле делать модели данных, желательно мультипарадигмальные. Шаблоны, скрипты, сниппеты описания данных -- неважно. SysMoLan Studio может выглядеть как-то похоже, там ведь тоже цель programmatic computer-aided design/architecture.

https://ailev.livejournal.com/1451630.html