В новый учебник системного мышления, возможно, нужно будет включить и содержательный апдейт диаграмм, не только перепаковку текущего материала в чисто преподавательских целях.
Спасибо Александру Турханову, который подтолкнул меня к этим размышлениям: дискуссии прошли в комментах https://www.facebook.com/photo.php?fbid=10211629123980727&set=a.10210218569517747.1073741832.1145074069&type=3 (и пока это выглядело как развитие темы лидерства -- пририсовывание необходимых сущностей к классическим диаграммам, я особо не вдавался в детали), потом это было обозвано системной схемой предприятия и тут я напрягся и понял, что нужно возвращаться к доработке основных диаграмм -- в https://www.facebook.com/alex.turkhanov/posts/10211638656299029
При этом я предпочёл бы пока говорить только об альфах и классическом Essence и его расширении на иженерию предприятия, пока не переходя к ArchiEssence -- и так всё сложно, поэтому решаем задачу по частям: нужно сначала договориться об онтологии, а уж потом о том, чем эту онтологию моделировать в ArchiMate.
Повторю тут часть своих комментов по проблеме из помянутых фейсбуковских тредов:
Я предпочитаю не говорить "модель ЖЦ", но "вид ЖЦ" -- и считать, что это как-то организованные практики. Если же сам ЖЦ, то там и практики и стадии (т.е. работы) -- оба view на ЖЦ. А ЖЦ ещё и воплощение, так что говорим отдельно об определении ЖЦ и о самом ЖЦ. При этом ЖЦ проекта -- только часть полного, "истинного системного" ЖЦ, проходящего через много предпринятий, много проектов.
У меня была уже пара подходов к этому снаряду (типа просто нарисовать рядом пару диаграмм, где предпринятие одного проекта есть воплощение системы другого проекта, я ряд других подобных ходов), но они все не слишком удовлетворительны были.
Классическим ответом было бы, конечно, просто проигнорировать Essence и выдать "определение и воплощение обеспечивающей системы" в зоне интересов предпринятия, но теряется аспект execution и разные view на предприятие (процессы, артефакты, команда).
Тут ещё важно, что нельзя потерять выразительность для инженеров -- если переакцентировать схемы для менеджеров, то инженеры потеряют интерес, и адью коммуникация, будет разговор бизнес-аналитиков с бизнес-аналитиками или аналитиков с реальными менеджерами, а инженеры опять останутся без поддержки. Так сказать, повторение судьбы SPEM и ISO 24744, которые были направлены на поддержку аналитиков и методологов, а не использование стандарта на практике инженерами и менеджерами "в поле".
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10209318674857928
