Кстати, SpaceX сделал ровно то же самое: изготавливает огромное количество детальков космического корабля сам, что резко уменьшило расходы на коммуникацию с контракторами. Те же принципы за программой повышения культуры "вы можете себе это позволить" (affordability) на флоте США, где идёт программа по enterprise commonality, то есть унификации модулей для всего флота-как-предприятия, (https://www.navsea.navy.mil/Media/News/Article/1391473/navsea-commonality-teams-findings-could-save-millions-in-fleet-maintenance-costs/ -- почему-то смог открыть только через VPN, там тоже свой Штаткомпозор работает. Начиналась enterprise commonality с программы замены самых разномастных дешёвых насосов на небольшую номенклатуру более дорогих насосов -- уменьшение номенклатуры и закупка типового насоса оказывается в ходе полного жизненного цикла дешевле покупки уникального самого дешёвого насоса для каждого отдельного применения).
Что мы сейчас будем делать в плане описания Школы, документирования архитектуры предприятия? Мы все наши кейсы "обоснуем" (essentialize, азаза -- essence это "основа", вот её и выделим), то есть установим проектные альфы для каждого кейса (черновой список кейсов -- https://ailev.livejournal.com/1492409.html, по каждому кейсу типовая альфа, а дальше для каждого экземпляра кейса -- экземпляр альфы), сделаем чеклисты для состояний альф, меняемых практиками (список практик для курса и потока нарезаны тут: https://ailev.livejournal.com/1496250.html). Для каждого чеклиста сделаем предложения по evidence/рабочим продуктам в виде форм, и привяжем к этому issue tracker. Потихоньку всю школу переведём на чеклисты: проверку наступления предписанных практиками событий для альф-кейсов и порождение работ, если события почему-то не наступили. Вводим учёт событий, управляем вниманием -- поднимаем осознанность в том, что происходит в Школе.
Поэтому формальный язык (SysMoLan) сначала заточим для этой чеклистизации. У нас была идея ArchiEssence, мы к ней возвращаемся на новом уровне (только альфы уже не просто основные альфы Essence, и SysMoLan вместо Архимейта). А потом да -- конфигурация описания Школы как скрипты на SysMoLan, а они конвертируются в скрипты конфигурации Айсистента (про пересечение с тематикой "скриптов как конфигурации" и RPA я писал в https://ailev.livejournal.com/1496250.html). Поэтому SysMoLan как DSL заточим поначалу на это. А пока нет DSL, будем писать просто псевдокод произвольного синтаксиса. По сути, это всё DDD -- только event storm мы делаем по идеям OMG Essence.
Отдельное дело будет -- как не забюрократизироваться. Ибо нет ничего более бюрократизирующего, чем все эти многочисленные обязательные чеклисты, от заполнения которых не даёт уклониться компьютер. Но при этом помним, что в клинике чеклист перед опирацией снижает смертность на 30% (книжка https://www.ozon.ru/context/detail/id/26845885/). Чеклисты у нас, кстати, в ходу на тех курсах, где зашкаливает количество разных мелких разномастных практик -- тот же системный фитнес. Не факт, что этими чеклистами пользуются, но при разработке курса они оказываются очень удобной формой документирования. Чеклисты не заменяют учебник, не учитывают подробности, но управляют вниманием: не дают забыть о важном. Вот это важное и пишем. Это шанс не прощёлкать важное, но и не забюрократизироваться.
А ещё договорились заседать по теме айсистента в офисе по пятницам в 18 часов. Ибо каждую неделю в проекте уже сейчас что-то происходит, работает несколько человек, и нужно удерживать проект целостным.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216791384510999