Обсуждение

Вот вопрос возник! Автор пишет: "Не знаю, куда это публиковать -- в dot15926 или praxos. Это застряло посредине, плюс прихватывает тему качества данных, которая пока никуда не пристроена. Так что пусть пока побудет тут, в Лабораторном Журнале.". То есть у автора проблема: в какой раздел каталога помещается "текст". Если бы инструмент под названием "публикатория-имени-ЛайвДжорнал" поддерживал гмперссылки между "вхождениями каталога" (или, другими словами, между карточками каталога), то можно было бы опубликовать текст в одном каталоге, а из другого раздела каталога сделать карточку (публикацию) со ссылкой на первую публикацию. Еще более мягкий способ (метод!) - публиковать текст в репозитории (=библиотека с книжными полками или с бесконечной лентой конвейера с РФИД-метками); а в карточках каталога делать ссылки на запись в репозитории. Абсолютно мягкий вариант: публиковать "текст" во всех каталогах, к которым онтологизируется данный текст (то есть опубликовать пост и в дот15926, и в Праксос). Самый жесткий вариант: публиковать текст только в одном разделе каталога (или в одной книжной полке), а поскольку "текст" многосмысловый, то "притяжение" текста к той или иной книжной полке (=блогу, или Сообществу) определять по онтологической метрике расстояния. Я так понимаю, что автор намеренно написал последнюю фразу, чтобы подчеркнуть сложность темы каталогизации.

Подумалось. Про акторов и сервисы. Их близость (иногда до степени неразличимости) исходит во многом от ролевой модели определения акторов. Т.е. если актор - это роль, которую они играет в процессе, то очевидно, что в сервисном описании эта роль сопровождается конечным набором сервисов, которые данный актор по идее должен предоставлять (условному) процесс-менеджеру для того, чтобы процесс работал и совершенствовался. Другой вопрос связан с тем, что есть довольно непустое (иногда также до степени смешения) пересечение между акторами и стейкхолдерами. А роли стейкхолдеров в процессе не так модельны, т.е. могут меняться. Все это заставляет задуматься о том, что есть capabilities (например, выразимо ли они через сервисы), и как стыковать их (а значит и сервисы) с стейкхолдерами (и их ресурсами). Еще также про каталог методических комплектующих. Если Вы хотите method parts, то Вам (очевидно) не обойтись без моделей интеграции этих запчастей в общий метод. Тут, очевидно встает вопрос - а можно ли выразить эту модель опять же через сервисную логику. И как это сделать - специальным языком, на котором можно было бы писать компиляторы более сложных сервисов на основе более простых? И не соответствует ли это тому, что в пределе любой процесс можно представить как сервис, а в method parts хранить только описанные на этом языке субпроцессы, и так вниз по иерархии до каких-то элементарных процессов. Ведь в этом случае дизайн системы это не более чем выбор базы элементарных комплектующих + система скриптов, описывающих иерархическую модель, по которой данная система собирается в единый сложный сервис.

P.S. Да, кстати, сервисную иерархическую систему будет в excel уже не представить, т.к. ее суть - скорее иерархия в стиле ООП. Соответственно, реестр методов вполне может существовать, но будет играть второстепенную роль (если продолжать аналогию с ООП, то часть методов вполне могут быть "приватными", т.е. недоступными для исполнения вне какого-либо контекста, и тогда они по идее не должны попадать в реестр на общих началах).

Нужно сказать, что текст программы -- это все-таки не иерархия (хотя, если говорить об AST, то дерево может быть налицо). Так и "текст метода" может быть неиерархичен, а "программоподобен". Пока мы рассматриваем ISO 24744 в качестве способа записи метода, но с ужасом думаем о трудностях стыковки его с, например, BPMN 2 (и неминуемой при этом разборке про различия метода и workflow, включая различия в ролях/акторах и описаниях взаимодействия -- хореографии).

Тема не только каталогизации, а мастер-данных (учета) вообще.

ИМХО (хотя я в этих вопросах необходимым опытом не обладаю), нельзя идти от одного стандарта, не имея собственной верхнеуровневой модели, кто как и с чем. Потому что как у всех есть проблемы со стыковкой стандартов друг с другом, так и у Вас будут. Мне кажется, что гораздо более правильный путь - собственная верхнеуровневая модель (по крайней мере, отвечающая на вопросы, что есть метод, процесс, актор, сервис и архитектура для его/метода содержательного описания, что есть способность/ресурс и т.п.), на основании которой строится сито - что из стандарта ISO 24744 (или любого другого) брать, а что брать только с помощью явного мэппинга (возможно даже без изоморфизма). Потому как каждый стандарт ИМХО на сегодня свалка классных находок, в перемешку с унаследованными от неудачных архитектур стереотипами. И породить систему, в которой отображены все кривости - не здорово.

Мы как раз договорились, что за собственную верхнеуровневую модель берем ISO 24744, а в качестве платформы для работы со всеми другими стандартами берем ISO 15926. Мы не хотим изобретать велосипед: если встретили 10 разных стандартов, то за основу брать не один из них (по нашей оценке самый переспективный), а выдумывать свой... Проблема в том, что названных двух стандартов для наших целей не хватает, и нужно разбираться дальше. О чем, собственно, данный постинг.

Тогда я перестал понимать Вашу логику. Как мне всегда казалось, основной смысл любой (окончательной) верхнеуровневой модели - отвечать на вопрос - зачем? и порождать требования к системам, как следствия от этого ответа. Только так можно говорить о том, что можно найти конкретное явление (конкретного потребителя), который бы даной моделью приближенно описывался, и про которго нельзя было бы сказать, что он зависим (т.е. может неожиданно и ниоткуда получить требования "сверху"), т.е. можно было бы ожидать его долгосрочной устойчивости в целях и методах. ISO 24744 (насколько я его поверхностно знаю), на таковые вопросы не отвечает. Если ссылаться на вашу трактовку важнейших терминов http://ailev.livejournal.com/816938.html, имеем "взявшееся из воздуха" определение предприятия (endeavour), которое "некоторый продукт или услугу" получает как данность. Даже если взять viewpoint обычного разработчика бизнес-плана, становится очевидным, что данное представление - не только не окончательное (имеет внешние вводы), но и не устойчивое, т.к. является функцией метода потребителя данного продукта или сервиса удовлетворять свою потребность. Более того, очевидно, что методами ИПО (IBD) рекламщики и маркетологи давно уже научились этот метод как минимум корректировать (особенно если речь идет не о манной каше, а о сложном информационно- и культуро- емком продукте или услуге), а в некоторых случаях создавать заново. Налицо целый пласт активностей, которые не охватываются данным стандартом (что ИМХО означает, что выбрано описание не некоторого независимого жизненного цикла, а его небольшой фрагмент, имеющий ввод и вывод, предшественников и последователей, по крайней мере с точки зрения преобразования информации). Что означает, что договориться о том, что именно он и будет верхнеуровневой моделью, конечно, можно, но по крайней мере, с точки зрения стратегирования ваша верхеуровневая модель уже не полна, из нее торчат во все стороны хвосты, уходящие в терминологию far beyond ее области применения. Собственно, именно поэтому был мой вопрос о том, какова же верхнеуровневая модель (и был он не потому что я Вас толкаю на изобретение велосипедов, а потому, что ИМХО на сегодня корректной стандартизированной верхнеуровневой модели не существует, несмотря на претензии отдельных стандартов, что означает, что попытки говорить о стратегии в терминах ISO 24744 конечно возможны, но они заведомо ущербны с точки зрения методов и практик, т.к. смотрят на вопрос слишком узко - вернее, однобоко).

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

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

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

Буду признателен, если Вы это однажды сделаете. Кстати, если таковая возможность существует, хотел бы прийти на ваш семинар. Поэтому хотел бы узнать, как и когда это можно было бы осуществить.

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

Понимаю, что напрашиваться в узкий круг невежливо. Поэтому жду поста - что сможете пояснить, и на том спасибо.