Заметки по трудностям верхнеуровневого моделирования
Я даже не буду уточнять, трудности верхнеуровневого (чаще всего -- архитектурного, сценарного, требований) моделирования чего -- системы ли в системной инженерии, предпринятия ли в организационной инженерии. Эти трудности связаны с восприятием моделей стейкхолдерами, несовершенством методик моделирования, несовершенством инструментов моделирования, но не с природой объектов моделирования. Конечно, эти мои краткие заметки не имеют никаких претензий на полноту: трудностей много больше, и каждый проект с ними несчастен по-своему. Я тут пишу только про те трудности, по которым мне приходилось чаще всего беседовать с клиентами. В какой-то мере этот пост развивает тему, поднятую мной в 2009г. в http://ailev.livejournal.com/721298.html (где я спорил с Виктором Батовриным, считавшим трендом "ограниченное применение традиционных методов аналитического и имитационного моделирования с одновременным повышением роли эталонных моделей"), но акцент я тут буду ставить на верхнеуровневое моделирование.
1. Неочевидность полезности моделирования.
Люди думают в терминах сущностей (абстрактных объектов -- "требования", "процессы"), а не описывающих эти сущности артефактов ("запись о требовании", "диаграмма процесса"), и говорят в терминах сущностей, лишь по необходимости обращаясь к артефактам. Их волнует "прибыль", но много меньше внимания они уделяют вопросу явности и обсуждённости модели, которая позволит им как-то ощутить и описать эту "прибыль". Конечно, существование двадцати разных видов прибыли (валовая, чистая, атрибутивная, балансовая, бухгалтерская и т.д.), которые становятся очевидными при обсуждении модели, в разговорах о прибыли упускается, и от этого неизбежно возникают ошибки и недопонимания, требующие дополнительного времени на их устранение. Но это дополнительное время считается "нормальным", а не "дополнительным".
Увы, люди думают о "невидимом" (прибыли, требованиях, системе, работе), но большинство не особо заботится о хоть как-то формализованных средствах выражения этого невидимого, обсуждения идут в форме баек на естественном языке и картинок с никакой нотацией. Чистой воды алхимия, с поэзией и упоминаниями о необходимости сосредоточения в части "намерения" вместо формул.
Местные гении абстрактного мышления всегда будут показывать своё мыслительное преимущество: качество подготовленных без высокоуровневых моделей решений не сильно уступает качеству решений, подготовленных с такими моделями. И они правы. Вот прямо сейчас идёт переписка между адептами классической "алхимической" системной инженерии и MBSE -- олдовые системные инженеры утверждают, что MBSE нерелевантна системной инженерии (это извод "инженерии систем" без опоры на системный подход, и никакого продвижения в системной инженерии -- ибо полноценного понятия "система" в предлагаемых языках моделирования не замечено). Действительно, Appollo запускался, когда никакого SysML и в проекте не было. Ничего, свозил на Луну космонавтов, и вернул их назад живыми -- и так шесть рейсов (http://en.wikipedia.org/wiki/Apollo_program)! Современные системные инженеры отвечают, что с моделями в SysML у них иногда получается вдесятеро быстрее, чем без моделей -- и они сами в крутых проектах/кейсах участвовали, и не лыком шиты. Мой ответ -- чума на оба этих дома, они оба правы и неправы одновременно.
Да, гроссмейстеры продумывают партии "внутри головы", не глядя на доску. Но не все люди -- гроссмейстеры, плюс обдуманные в голове партии могут содержать невидимые другим людям ошибки, ибо не обсуждены. Более того, чужие (разработанные гроссмейстерами) партии простые люди просто не будут играть -- нет к ним доверия, в критических ситуациях люди предпочтут делать какие-то простые ходы, а не прибегать к разработанным гроссмейстерами непонятным хитростям. Ну, или с гроссмейстерами будут ввязываться в длинные разговоры, чтобы разобраться, что там к чему -- а это время. Анри Ги заметил, что после использования моделирования качество анализа ситуаций в Shell не изменилось, но увеличилась втрое скорость принятия решений. То, что говорит Анри Ги в части сценарного моделирования в Shell удивительным образом совпадает с тем, что говорят сторонники MBSE: решения вполне могут оказаться того же качества, но с моделированием эти решения могут быть воплощены в жизнь втрое, а то и вдесятеро быстрее. Вместо недели коллективных медитаций -- ночь моделирования и утренняя демонстрация.
То есть ответ старичкам понятен: действительно, никакого "усиления творчества", только "убыстрение разработки". Ответ приверженцам MBSE -- это как раз следующий пункт.
2. Верхнеуровневое моделирование сегодня очень и очень плохо развито, ибо оно существенно затрагивает понятие "система" -- а это понятие не поддерживается явно ни одним из современных языков моделирования. Это неважно, что слово "система" в SysML присутствует даже на уровне названия! Мой дитятко-четвероклассник тоже регулярно говорит "система", отнюдь не демонстрируя системного мышления (и это, замечу, как раз критика от приверженцев системного мышления "без этих ваших специальных моделей" приверженцам "этих самых специальных моделей" -- что эти модели не поддерживают прямо системного мышления, а лишь те или иные его аспекты).
Верхнеуровневое моделирование по определению должно удерживать целостность, быть мультипредметным, междисциплинарным, оставляя разные детали разных предметных аспектов моделируемого объекта. Ежели брать практически любые языки верхнеуровнего моделирования -- то это не "системное моделирование", а какое-то однобокое "моделирование систем" (подробнее про различие "системной инженерии" и "инженерии систем", а также анализ поддержки полноценного понятия "система" в языках моделирования см. в http://ailev.livejournal.com/1056311.html, и там ссылка на видео и слайды полного доклада). Если кратко: сегодняшнее верхнеуровневое моделирование -- это как программирование времён бейсика и кобола. С одной стороны, свои три раза по скорости мы получаем, но нам-то этого мало!
Я сам вижу выход из этой ситуации в создании нового поколения языков моделирования, в том числе:
-- с полноценной поддержкой понятия "система" (различение компоненты системы и физического объекта, жизненный цикл с темпоральными частями и т.д. -- подробности в уже упомянутом докладе по понятию "система" в http://ailev.livejournal.com/1056311.html) и сопутствующего понимания про множества множество stakeholder concerns и адресующих их частных пар viewpoints-views (т.е. с поддержкой мультидисциплинарности, онтологичности).
-- поддерживающего моделирование, онтологизирование, программирование (а также анализ и синтез текстов на естественном языке) как одной и той же дисциплины -- информатики (например, http://ailev.livejournal.com/947180.html, http://justy-tylor.livejournal.com/151557.html, и про информатику в целом http://ailev.livejournal.com/989001.html, http://ailev.livejournal.com/1008054.html);
-- поддерживающих разные теории понятий (так, язык может отражать логическую парадигму, как ArchiMate или ISO 15926; прототипную парадигму -- можно думать о Lua-на-стероидах для моделирования и онтологизирования; традиционную аристотелевскую парадигму -- это SysML+Modelica). Нужна, наверное, какая-то поддержка понятийного плюрализма -- http://ailev.livejournal.com/1008684.html, а разъяснения по поводу засилья аристотелевщины, я писал в http://ailev.livejournal.com/1019876.html). Но что там имитационное (как в MatLab или Modelica) и структурное (как в SysML и ArchiMate) моделирования, а также "классическое программирование" (т.е. исполнимость) должны идти рука об руку -- это важно.
-- это поколение языков моделирования должно учитывать, что ими пользуются простые смертные (поэтому варианты с кривыми освоения, похожими на Agda или даже Haskell -- не предлагать).
-- имеющие все черты современных языков: абстрактные, текстовые и графические синтаксисы, способы предметного расширения и иные варианты задания модульности и выхода на мегамоделирование (явная поддержка разных "мета" -- см. http://ailev.livejournal.com/1053878.html), эффективную сериализацию (без ужасов XML), достаточную проработанность метаданных для предотвращения кошмара с управлением конфигурацией.
-- являющиеся стандартами (т.е. подразумевающими конкуренцию множества инструментальных реализаций, понятно по каким правилам меняющихся, коллективно обсуждающихся на предмет исключения глупых ошибок и выдерживающих какие-то минимальные требования к формальности спецификации).
Увы, нет таких языков моделирования! Если брать любой из имеющихся (например, ISO 15926 -- он хоть как-то поддерживает понятие "система"), то всё равно получается варка супа из топора: придумывать тут больше, чем прихватывать готового.
3. Конечно, для любого такого супер-пупер системного языка моделирования требуется надлежащего качества моделер -- и тут тоже всё плохо. Я недавно выписывал чеклист для выбора моделера: http://ailev.livejournal.com/1041274.html. Ну, и где такие моделеры?!
Для таких языка и моделера потребуется разработать новые практики моделирования -- это ещё ой-ой сколько времени (как раз сейчас идёт обсуждение практик онтологизирования -- там даже не могут решить, похожи ли эти практики на практики программирования. Практики программирования изучались в ходе создания OMG Essence -- но даже сам стандарт ещё не вышел, а споры по нему бушуют. Практики же моделирования почти не обсуждаются: оно существует пока на уровне искусства).
Затем учебный аспект: всему этому нужно будет как-то научить, а создание хоть как-то приемлемой технологии обучения и учебной среды требует дополнительного времени.
Пока же желающим продемонстрировать блеск верхнеуровневого моделирования не удастся это сделать без демонстрации сопутствующей нищеты. А разбогатеть быстро не получится, за пару-тройку лет ситуацию не исправишь.
4. Сами модели (а зачастую и результаты моделирования) оказываются непонятны ключевым участникам этого моделирования:
-- стратегам (которые про бизнес: полезность модели стейкхолдерам, что даст модель акционерам в части прибыли),
-- менеджерам (которые про операции -- чтобы через предпринятие в единицу времени проходило побольше продукции и денег при имеющихся ресурсах. Их может заинтересовать факт про "втрое быстрее", но это непонятно, как демонстрировать и доказывать),
-- инженерам (которые про предметную область, но не понимают ухватывающего понятия предметной области языка моделирования и его онтологических выборов -- им, как музыкантам, проще их "музыку" делать не на лучших инструментах, а на любимых -- нельзя скрипача заставить играть на саксофоне без долгого и специального обучения, это обучение много дольше, чем длительность потенциального кейса/проекта моделирования, и поэтому никогда не происходит).
-- constraints в модели на сегодня чаще всего можно выразить только на нормальном текстовом формальном языке. Тут будет работать только модельер, предметные эксперты (и тем более стейкхолдеры) не смогут адекватно поучаствовать. А модельер обычно мало что знает про глубины предметной области. Это значит, что "демонстрационные кейсы/проекты" (где удалось получить модельера и эксперта в одном лице) будут успешны, а никакие другие кейсы/проекты с явным указанием constraints (т.е. делающие какие-то шаги от совсем уж верхнеуровневого моделирования к какой-то детализации) успешными стать не смогут.
Решение об использовании моделирования (т.е. решение о выделении денег на моделер, обучение множества людей, включение времени на моделирования в планы работ) принимают часто даже не инженеры, а менеджеры и стратеги. Из моделирования им понятна только инфографика, которая готовится обычно инженерами и модельерами по итогам моделирования вручную. Никакие моделеры сейчас не генерируют инфографику. Так что при "продаже" моделирования руководству и даже инженерам, стейкхолдеры убеждаются не непосредственно моделью и результатами моделирования, а только должным уровнем металла в голосе модельеров, как-то освоивших эту премудрость (по усилиям сравнимую с освоением какого-то иностранного языка -- любое моделирование ведь про освоение языка! Ну, и много мы знаем желающих освоить новый иностранный язык? Желающих-то много, осваивающих нет! Особенно среди стейкхолдеров, которых нет никаких стимулов заставить это сделать). Так что вместо текста на иностранном языке им показывают диафильм из красочных картинок, с минимумом незнакомых слов и скрывающихся за ними незнакомых понятий.
Даже если откатиться от инфографики к обычной графики, окажется, что для по-настоящему больших моделей этого недостаточно, большие объемы моделирования можно перемолотить только в текстовом формате (и не убеждайте меня в обратном). Любые же стейкхолдеры-не-модельеры, которые хоть как-то готовы познакомиться с чем-то сложнее инфографики, готовы "водить пальчиком" только по "просто графике", но никак не текстам на формальном языке. И это только лучшие из лучших, храбрые из храбрых -- ибо даже в книжках по вполне графическому ArchiMate рекомендуют не показывать менеджменту архитектурные диаграммы, а показывать только инфографику, подготовленную в PowerPoint на основе этих диаграмм.
Никакие моделеры сейчас не генерируют инфографику, хорошо хоть люди об этом задумались (тут можно особо похвалить Tom Graves, см., например, на его "The enterprise is a story", слайды 71-76: http://www.slideshare.net/tetradian/the-enterprise-is-the-story. vvagr любит мне напоминать, что при всей нашей в TechInvestLab приверженности к моделированию, лучшим для нас моделером, который мы можем использовать в разговорах с клиентом, является флипчарт и цветные маркеры. Вот эта презентация как раз об этом. Инициативы типа VDHL тут немного дают, но какой-то прогресс наблюдается и тут: Archi, например, поддерживает уже не только формальный ArchiMate, но и позволяет создавать canvas!
В принципе, тут можно думать и о других способах снижения интеллектуального ценза, прежде всего по линии интеллектуальных систем -- использование блендинга в частности и метафор в целом для объяснений, выход за пределы генерации и распознавания текстов на естественном языке в более сложную коммуникацию с моделью. Но это из области фантастики пока (т.е. не в пятилетней перспективе, а в десятилетней).
5. Высокоуровневое моделирование резко ускоряет выработку решений по требованиям, архитектуре и прочим высокоуровневым аспектам системы (киберфизической или социотехнической -- неважно) ровно в той мере, в какой модель коллективно разрабатывается и служит тем артефактом, который обслуживает работу команды. Для этого средства моделирования должны как-то поддерживать коллективную разработку:
-- подразумевать работу многих людей за одним экраном (для этого экран должен быть большой, шрифты и иконки регулируемого размера -- ведь чем больше людей обсуждают модель, тем дальше они от экрана, и это при том, что хочется уместить на экран как можно бОльший кусок модели).
-- иметь нормальную модульность (когда-то значительная часть развития языков программирования была посвящена разным аспектам обеспечения модульности и повторноиспользуемости. Увы, в онтологизировании и моделировании это обсуждается мало, а реализуется так и вообще из рук вон плохо).
-- поддерживать уже традиционные для программирования (но мало изученные для онтологизирования и моделирования) непрерывную интеграцию плюс верификацию (тестирование)
-- управление конфигурацией и изменениями (версионирование плюс issue tracker). Тут и так всё понятно.
-- подсказки в части методологии разработки (это новомодная идея из OMG Essence: если иметь описание практик и метода достаточно формальные -- для первого случая пойдёт и сам Essence, то софт может выдавать советы, что там делать дальше по жизненному циклу. Есть и другие реализации, типа http://www.software-development-experts.com/features.aspx, думаю, что идею поняли.
-- каким-то образом модель должна быть также привязана к организации (полномочиям, людям, их компетенциям -- чтобы к моделированию подключались правильные люди). Это как-то пересекается с частью issue tracker, но в сочетании с поддержкой методологии разработки выводит и на полную проблему case management (помним, что люди на роли в кейсе часто назначаются по ходу дела, а не заранее -- и это относится также к кейсам моделирования, т.е. работа с компетенциями и назначениями на роли в кейсах оказывается в прямой связи с моделированием).
6. Одна из мало замечаемых трудностей в высокоуровневом моделировании сегодня -- это возможность накопления знаний. По факту, практически все проекты моделирования (и онтологизирования) сегодня приходится начинать практически с нуля -- в приемлемых форматах нет библиотек (библиотеки Modelica тут не в счёт, это исключение, причём они больше не для высокоуровневого моделирования, а для низкоуровневой мультифизики), доступных архитектурных решений (приходится понимать их общие черты, а затем рисовать в том или ином моделере в каждом новом проекте), паттернов, онтологий (сегодняшние RDL в ISO 15926 -- это пока больше заявка на решение, чем полноценное решение. Одной JORD RDL маловато будет, а федераций фасадов пока нет, продолжаются переговоры на тему, как это лучше сделать -- все боятся быть первыми, это и есть мой пойнт! В языках программирования с библиотеками, закрывающими те или иные предметные области, намного проще).
Накопление знаний (т.е. повторно используемой информации) многогранно, требует самых разных решений: от поддержки модульности, развития гранулярности в языке моделирования до возможности прийти на новое место работы, рассчитывая на возможность использования библиотек моделирования, освоенных на старом месте работы. Увы, моделирование (да и онтологизирование) на сегодня в этом плане похоже на программирование, каким оно было в середине семидесятых: про удобство библиотек все знали, но библиотек в мире было крайне мало (разве что парочка фортранных библиотек с численными методами). Желающим сделать какой-то проект моделирования а хоть в SysML, а хоть в ArchiMate приходится начинать по факту с нуля. И даже если удаётся выполнить стартовый успешный проект, форма переноса знаний в следующий проект остаётся проблематичной. Поэтому начальные высокие затраты остаются высокими (каждый раз проходится один и тот же длинный путь, с нуля), а последующие затраты не снижаются.
Выход тут в поддержке библиотек, фреймворков, каталогов -- в языке, в инструментарии, и даже в бизнес-моделях (кто-то этим сохраняемым и отчуждаемым модельным знанием должен начать торговать, иначе его просто не будет).
1. Неочевидность полезности моделирования.
Люди думают в терминах сущностей (абстрактных объектов -- "требования", "процессы"), а не описывающих эти сущности артефактов ("запись о требовании", "диаграмма процесса"), и говорят в терминах сущностей, лишь по необходимости обращаясь к артефактам. Их волнует "прибыль", но много меньше внимания они уделяют вопросу явности и обсуждённости модели, которая позволит им как-то ощутить и описать эту "прибыль". Конечно, существование двадцати разных видов прибыли (валовая, чистая, атрибутивная, балансовая, бухгалтерская и т.д.), которые становятся очевидными при обсуждении модели, в разговорах о прибыли упускается, и от этого неизбежно возникают ошибки и недопонимания, требующие дополнительного времени на их устранение. Но это дополнительное время считается "нормальным", а не "дополнительным".
Увы, люди думают о "невидимом" (прибыли, требованиях, системе, работе), но большинство не особо заботится о хоть как-то формализованных средствах выражения этого невидимого, обсуждения идут в форме баек на естественном языке и картинок с никакой нотацией. Чистой воды алхимия, с поэзией и упоминаниями о необходимости сосредоточения в части "намерения" вместо формул.
Местные гении абстрактного мышления всегда будут показывать своё мыслительное преимущество: качество подготовленных без высокоуровневых моделей решений не сильно уступает качеству решений, подготовленных с такими моделями. И они правы. Вот прямо сейчас идёт переписка между адептами классической "алхимической" системной инженерии и MBSE -- олдовые системные инженеры утверждают, что MBSE нерелевантна системной инженерии (это извод "инженерии систем" без опоры на системный подход, и никакого продвижения в системной инженерии -- ибо полноценного понятия "система" в предлагаемых языках моделирования не замечено). Действительно, Appollo запускался, когда никакого SysML и в проекте не было. Ничего, свозил на Луну космонавтов, и вернул их назад живыми -- и так шесть рейсов (http://en.wikipedia.org/wiki/Apollo_program)! Современные системные инженеры отвечают, что с моделями в SysML у них иногда получается вдесятеро быстрее, чем без моделей -- и они сами в крутых проектах/кейсах участвовали, и не лыком шиты. Мой ответ -- чума на оба этих дома, они оба правы и неправы одновременно.
Да, гроссмейстеры продумывают партии "внутри головы", не глядя на доску. Но не все люди -- гроссмейстеры, плюс обдуманные в голове партии могут содержать невидимые другим людям ошибки, ибо не обсуждены. Более того, чужие (разработанные гроссмейстерами) партии простые люди просто не будут играть -- нет к ним доверия, в критических ситуациях люди предпочтут делать какие-то простые ходы, а не прибегать к разработанным гроссмейстерами непонятным хитростям. Ну, или с гроссмейстерами будут ввязываться в длинные разговоры, чтобы разобраться, что там к чему -- а это время. Анри Ги заметил, что после использования моделирования качество анализа ситуаций в Shell не изменилось, но увеличилась втрое скорость принятия решений. То, что говорит Анри Ги в части сценарного моделирования в Shell удивительным образом совпадает с тем, что говорят сторонники MBSE: решения вполне могут оказаться того же качества, но с моделированием эти решения могут быть воплощены в жизнь втрое, а то и вдесятеро быстрее. Вместо недели коллективных медитаций -- ночь моделирования и утренняя демонстрация.
То есть ответ старичкам понятен: действительно, никакого "усиления творчества", только "убыстрение разработки". Ответ приверженцам MBSE -- это как раз следующий пункт.
2. Верхнеуровневое моделирование сегодня очень и очень плохо развито, ибо оно существенно затрагивает понятие "система" -- а это понятие не поддерживается явно ни одним из современных языков моделирования. Это неважно, что слово "система" в SysML присутствует даже на уровне названия! Мой дитятко-четвероклассник тоже регулярно говорит "система", отнюдь не демонстрируя системного мышления (и это, замечу, как раз критика от приверженцев системного мышления "без этих ваших специальных моделей" приверженцам "этих самых специальных моделей" -- что эти модели не поддерживают прямо системного мышления, а лишь те или иные его аспекты).
Верхнеуровневое моделирование по определению должно удерживать целостность, быть мультипредметным, междисциплинарным, оставляя разные детали разных предметных аспектов моделируемого объекта. Ежели брать практически любые языки верхнеуровнего моделирования -- то это не "системное моделирование", а какое-то однобокое "моделирование систем" (подробнее про различие "системной инженерии" и "инженерии систем", а также анализ поддержки полноценного понятия "система" в языках моделирования см. в http://ailev.livejournal.com/1056311.html, и там ссылка на видео и слайды полного доклада). Если кратко: сегодняшнее верхнеуровневое моделирование -- это как программирование времён бейсика и кобола. С одной стороны, свои три раза по скорости мы получаем, но нам-то этого мало!
Я сам вижу выход из этой ситуации в создании нового поколения языков моделирования, в том числе:
-- с полноценной поддержкой понятия "система" (различение компоненты системы и физического объекта, жизненный цикл с темпоральными частями и т.д. -- подробности в уже упомянутом докладе по понятию "система" в http://ailev.livejournal.com/1056311.html) и сопутствующего понимания про множества множество stakeholder concerns и адресующих их частных пар viewpoints-views (т.е. с поддержкой мультидисциплинарности, онтологичности).
-- поддерживающего моделирование, онтологизирование, программирование (а также анализ и синтез текстов на естественном языке) как одной и той же дисциплины -- информатики (например, http://ailev.livejournal.com/947180.html, http://justy-tylor.livejournal.com/151557.html, и про информатику в целом http://ailev.livejournal.com/989001.html, http://ailev.livejournal.com/1008054.html);
-- поддерживающих разные теории понятий (так, язык может отражать логическую парадигму, как ArchiMate или ISO 15926; прототипную парадигму -- можно думать о Lua-на-стероидах для моделирования и онтологизирования; традиционную аристотелевскую парадигму -- это SysML+Modelica). Нужна, наверное, какая-то поддержка понятийного плюрализма -- http://ailev.livejournal.com/1008684.html, а разъяснения по поводу засилья аристотелевщины, я писал в http://ailev.livejournal.com/1019876.html). Но что там имитационное (как в MatLab или Modelica) и структурное (как в SysML и ArchiMate) моделирования, а также "классическое программирование" (т.е. исполнимость) должны идти рука об руку -- это важно.
-- это поколение языков моделирования должно учитывать, что ими пользуются простые смертные (поэтому варианты с кривыми освоения, похожими на Agda или даже Haskell -- не предлагать).
-- имеющие все черты современных языков: абстрактные, текстовые и графические синтаксисы, способы предметного расширения и иные варианты задания модульности и выхода на мегамоделирование (явная поддержка разных "мета" -- см. http://ailev.livejournal.com/1053878.html), эффективную сериализацию (без ужасов XML), достаточную проработанность метаданных для предотвращения кошмара с управлением конфигурацией.
-- являющиеся стандартами (т.е. подразумевающими конкуренцию множества инструментальных реализаций, понятно по каким правилам меняющихся, коллективно обсуждающихся на предмет исключения глупых ошибок и выдерживающих какие-то минимальные требования к формальности спецификации).
Увы, нет таких языков моделирования! Если брать любой из имеющихся (например, ISO 15926 -- он хоть как-то поддерживает понятие "система"), то всё равно получается варка супа из топора: придумывать тут больше, чем прихватывать готового.
3. Конечно, для любого такого супер-пупер системного языка моделирования требуется надлежащего качества моделер -- и тут тоже всё плохо. Я недавно выписывал чеклист для выбора моделера: http://ailev.livejournal.com/1041274.html. Ну, и где такие моделеры?!
Для таких языка и моделера потребуется разработать новые практики моделирования -- это ещё ой-ой сколько времени (как раз сейчас идёт обсуждение практик онтологизирования -- там даже не могут решить, похожи ли эти практики на практики программирования. Практики программирования изучались в ходе создания OMG Essence -- но даже сам стандарт ещё не вышел, а споры по нему бушуют. Практики же моделирования почти не обсуждаются: оно существует пока на уровне искусства).
Затем учебный аспект: всему этому нужно будет как-то научить, а создание хоть как-то приемлемой технологии обучения и учебной среды требует дополнительного времени.
Пока же желающим продемонстрировать блеск верхнеуровневого моделирования не удастся это сделать без демонстрации сопутствующей нищеты. А разбогатеть быстро не получится, за пару-тройку лет ситуацию не исправишь.
4. Сами модели (а зачастую и результаты моделирования) оказываются непонятны ключевым участникам этого моделирования:
-- стратегам (которые про бизнес: полезность модели стейкхолдерам, что даст модель акционерам в части прибыли),
-- менеджерам (которые про операции -- чтобы через предпринятие в единицу времени проходило побольше продукции и денег при имеющихся ресурсах. Их может заинтересовать факт про "втрое быстрее", но это непонятно, как демонстрировать и доказывать),
-- инженерам (которые про предметную область, но не понимают ухватывающего понятия предметной области языка моделирования и его онтологических выборов -- им, как музыкантам, проще их "музыку" делать не на лучших инструментах, а на любимых -- нельзя скрипача заставить играть на саксофоне без долгого и специального обучения, это обучение много дольше, чем длительность потенциального кейса/проекта моделирования, и поэтому никогда не происходит).
-- constraints в модели на сегодня чаще всего можно выразить только на нормальном текстовом формальном языке. Тут будет работать только модельер, предметные эксперты (и тем более стейкхолдеры) не смогут адекватно поучаствовать. А модельер обычно мало что знает про глубины предметной области. Это значит, что "демонстрационные кейсы/проекты" (где удалось получить модельера и эксперта в одном лице) будут успешны, а никакие другие кейсы/проекты с явным указанием constraints (т.е. делающие какие-то шаги от совсем уж верхнеуровневого моделирования к какой-то детализации) успешными стать не смогут.
Решение об использовании моделирования (т.е. решение о выделении денег на моделер, обучение множества людей, включение времени на моделирования в планы работ) принимают часто даже не инженеры, а менеджеры и стратеги. Из моделирования им понятна только инфографика, которая готовится обычно инженерами и модельерами по итогам моделирования вручную. Никакие моделеры сейчас не генерируют инфографику. Так что при "продаже" моделирования руководству и даже инженерам, стейкхолдеры убеждаются не непосредственно моделью и результатами моделирования, а только должным уровнем металла в голосе модельеров, как-то освоивших эту премудрость (по усилиям сравнимую с освоением какого-то иностранного языка -- любое моделирование ведь про освоение языка! Ну, и много мы знаем желающих освоить новый иностранный язык? Желающих-то много, осваивающих нет! Особенно среди стейкхолдеров, которых нет никаких стимулов заставить это сделать). Так что вместо текста на иностранном языке им показывают диафильм из красочных картинок, с минимумом незнакомых слов и скрывающихся за ними незнакомых понятий.
Даже если откатиться от инфографики к обычной графики, окажется, что для по-настоящему больших моделей этого недостаточно, большие объемы моделирования можно перемолотить только в текстовом формате (и не убеждайте меня в обратном). Любые же стейкхолдеры-не-модельеры, которые хоть как-то готовы познакомиться с чем-то сложнее инфографики, готовы "водить пальчиком" только по "просто графике", но никак не текстам на формальном языке. И это только лучшие из лучших, храбрые из храбрых -- ибо даже в книжках по вполне графическому ArchiMate рекомендуют не показывать менеджменту архитектурные диаграммы, а показывать только инфографику, подготовленную в PowerPoint на основе этих диаграмм.
Никакие моделеры сейчас не генерируют инфографику, хорошо хоть люди об этом задумались (тут можно особо похвалить Tom Graves, см., например, на его "The enterprise is a story", слайды 71-76: http://www.slideshare.net/tetradian/the-enterprise-is-the-story. vvagr любит мне напоминать, что при всей нашей в TechInvestLab приверженности к моделированию, лучшим для нас моделером, который мы можем использовать в разговорах с клиентом, является флипчарт и цветные маркеры. Вот эта презентация как раз об этом. Инициативы типа VDHL тут немного дают, но какой-то прогресс наблюдается и тут: Archi, например, поддерживает уже не только формальный ArchiMate, но и позволяет создавать canvas!
В принципе, тут можно думать и о других способах снижения интеллектуального ценза, прежде всего по линии интеллектуальных систем -- использование блендинга в частности и метафор в целом для объяснений, выход за пределы генерации и распознавания текстов на естественном языке в более сложную коммуникацию с моделью. Но это из области фантастики пока (т.е. не в пятилетней перспективе, а в десятилетней).
5. Высокоуровневое моделирование резко ускоряет выработку решений по требованиям, архитектуре и прочим высокоуровневым аспектам системы (киберфизической или социотехнической -- неважно) ровно в той мере, в какой модель коллективно разрабатывается и служит тем артефактом, который обслуживает работу команды. Для этого средства моделирования должны как-то поддерживать коллективную разработку:
-- подразумевать работу многих людей за одним экраном (для этого экран должен быть большой, шрифты и иконки регулируемого размера -- ведь чем больше людей обсуждают модель, тем дальше они от экрана, и это при том, что хочется уместить на экран как можно бОльший кусок модели).
-- иметь нормальную модульность (когда-то значительная часть развития языков программирования была посвящена разным аспектам обеспечения модульности и повторноиспользуемости. Увы, в онтологизировании и моделировании это обсуждается мало, а реализуется так и вообще из рук вон плохо).
-- поддерживать уже традиционные для программирования (но мало изученные для онтологизирования и моделирования) непрерывную интеграцию плюс верификацию (тестирование)
-- управление конфигурацией и изменениями (версионирование плюс issue tracker). Тут и так всё понятно.
-- подсказки в части методологии разработки (это новомодная идея из OMG Essence: если иметь описание практик и метода достаточно формальные -- для первого случая пойдёт и сам Essence, то софт может выдавать советы, что там делать дальше по жизненному циклу. Есть и другие реализации, типа http://www.software-development-experts.com/features.aspx, думаю, что идею поняли.
-- каким-то образом модель должна быть также привязана к организации (полномочиям, людям, их компетенциям -- чтобы к моделированию подключались правильные люди). Это как-то пересекается с частью issue tracker, но в сочетании с поддержкой методологии разработки выводит и на полную проблему case management (помним, что люди на роли в кейсе часто назначаются по ходу дела, а не заранее -- и это относится также к кейсам моделирования, т.е. работа с компетенциями и назначениями на роли в кейсах оказывается в прямой связи с моделированием).
6. Одна из мало замечаемых трудностей в высокоуровневом моделировании сегодня -- это возможность накопления знаний. По факту, практически все проекты моделирования (и онтологизирования) сегодня приходится начинать практически с нуля -- в приемлемых форматах нет библиотек (библиотеки Modelica тут не в счёт, это исключение, причём они больше не для высокоуровневого моделирования, а для низкоуровневой мультифизики), доступных архитектурных решений (приходится понимать их общие черты, а затем рисовать в том или ином моделере в каждом новом проекте), паттернов, онтологий (сегодняшние RDL в ISO 15926 -- это пока больше заявка на решение, чем полноценное решение. Одной JORD RDL маловато будет, а федераций фасадов пока нет, продолжаются переговоры на тему, как это лучше сделать -- все боятся быть первыми, это и есть мой пойнт! В языках программирования с библиотеками, закрывающими те или иные предметные области, намного проще).
Накопление знаний (т.е. повторно используемой информации) многогранно, требует самых разных решений: от поддержки модульности, развития гранулярности в языке моделирования до возможности прийти на новое место работы, рассчитывая на возможность использования библиотек моделирования, освоенных на старом месте работы. Увы, моделирование (да и онтологизирование) на сегодня в этом плане похоже на программирование, каким оно было в середине семидесятых: про удобство библиотек все знали, но библиотек в мире было крайне мало (разве что парочка фортранных библиотек с численными методами). Желающим сделать какой-то проект моделирования а хоть в SysML, а хоть в ArchiMate приходится начинать по факту с нуля. И даже если удаётся выполнить стартовый успешный проект, форма переноса знаний в следующий проект остаётся проблематичной. Поэтому начальные высокие затраты остаются высокими (каждый раз проходится один и тот же длинный путь, с нуля), а последующие затраты не снижаются.
Выход тут в поддержке библиотек, фреймворков, каталогов -- в языке, в инструментарии, и даже в бизнес-моделях (кто-то этим сохраняемым и отчуждаемым модельным знанием должен начать торговать, иначе его просто не будет).