?

Log in

No account? Create an account
Что моделировать в организации, или опять о софте PraxOS как "универсальном моделере" - Разработка PraxOS
July 29th, 2011
11:40 am
[ailev]

[Link]

Previous Entry Share Next Entry
Что моделировать в организации, или опять о софте PraxOS как "универсальном моделере"
Можно было бы определить предметную область PraxOS как "то, что моделируется софтом PraxOS" (и наоборот: что является предметной областью PraxOS, то и моделируется софтом PraxOS). Ну, и что должно быть описано на ОргЛане?!

1. Организационная архитектура (enterprise architecture) -- можно думать об ArchiMate (http://ailev.livejournal.com/940819.html) с его business, applications, technology покрытием. Несмотря на всеохватность этой терминологии, сама выразимая на ArchiMate архитектура не так уж и велика. Так, уже сегодня обсуждаются добавки по целеполаганию (motivational).

2. Но если поглядеть, что поддерживают своим софтом конкуренты архитектурных моделеров, то свежий июльский 2011 обзорчик Enterprise Architecture Tool Selection Guide (http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.2.pdf) показывает следующие предметные области:
-- governance, risk, compliancy
-- program management
-- enterprise/IT-portfolio management
-- Business/IT strategy
-- Enterprise Architecture
-- Solution Architecture
-- Software Engineering

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

3. Ключевое тут -- это упор в "архитектурах" из полноценного описания метода работы (и сопутствующего моделирования предпринятия/endeavour) на именно что моделирование "технологии" (инструментов и артефактов), но не:
-- собственно ситуационного метода работы (http://ailev.livejournal.com/905099.html). Даже если выполнить элементарные отождествления (ArchiMate:object/passive structure=ISO24744:WorkProduct, ArchiMate:behaviour=ISO24744:WorkUnit, AchiMate:subject/active structure=ISO24744:Performer), многое остаётся за бортом: метод ("методология разработки", как что-то сделать: независимо от организации/управления ходом работ, упор на предметное содержание) часто крутится вокруг понятия "жизненный цикл" (http://ailev.livejournal.com/917251.html), но я не встречал в архитектурных языках какого-либо упоминания "жизненного цикла".
-- "дисциплины" (то, что грузят в голову, http://ailev.livejournal.com/930608.html) и сюда бы я отнёс также методы описаний (viewpoints) -- guides, models, languages и notations из ISO 24744, architectural framework из ISO 42010.
-- "организации в узком смысле" (распределение полномочий по задействованию акторов и обработка отказов/"выходы в дискурс": работа с координационными актами в DEMO),
-- стратегирования/обоснований (что не совсем точно относить к мотивационным моделям: http://praxos.livejournal.com/6777.html).

4. Поддержки эволюции организации и модели (прежде всего а)работа с вариантами оргмодели, и контроль конфигурации модели в ходе изменений -- поддержка соответствия между разными оргбазисами). Это должна быть явная поддержка управления технологиями, как метода перескока с одного поколения технологии на другое (http://ailev.livejournal.com/928711.html). Пример того, что нужно было бы уметь поддерживать явно в развертке во времени: http://ailev.livejournal.com/939027.html, только на место "системной инженерии" там поставьте любой другой метод и соответствующие ему дисциплины и технологию.

5. Есть многое другое, что пока непонятно, как реализовывать:
-- работу с ограничениями (т.е. эксплицитное моделирование "потока", throughput и ограничений на нём), чтобы реализовать "фокусирование по Голдратту".
-- dynamic case management dynamic case management (http://ailev.livejournal.com/711517.html, плюс http://www.itbusinessedge.com/cm/community/features/interviews/blog/case-management-is-step-forward-in-bpm-evolution/?cs=39882 и много-много других работ), для которого непригодны практики BPM (business process management), к которым традиционно тяготеет современная enterprise architecture.
-- сюда же можно отнести разбирательство с complex event processing, а также работу с business rules -- они тоже пока никак не затронуты мейнстримом организационного моделирования

6. Несмотря на то, что все архитектурные языки, а также метамодели ситуационной инженерии методов поддерживают "расширения", вряд ли этих расширений будет хватать. Это общеметодологическое замечание: как микротеорию (предмет) не растягивай, толку не будет, ибо не бывает универсальных онтологий. Современным выходом из ситуации выглядит опора всех архитектурных, методических, реализационных, технологических, дисциплинарных и прочих описаний на какую-то компактную и максимально общую "верхнюю" (foundational, upper) онтологию -- а все остальные группы описаний обязаны быть привязаны к типам этой онтологии. В DoDAF это 4D онтология IDEAS, в PraxOS по факту мы выбираем близкого родственника -- ISO 15926, тоже 4D.

7. В таком подходе софт PraxOS поддерживает не только каталог компонент методов PraxOS, но тесно связанную с ним организационную архитектуру (enterprise architecture), а также много чего другого -- чем, конечно, сильно отличается от типичных "организационных моделеров". Так что задаваемый в июльском 2011 обзорчике Enterprise Architecture Tool Selection Guide (http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.2.pdf) списке требований к софту оргмоделирования можно было бы выделить три группы:
-- поддерживаемые модели (вопросы типа "поддерживаем ли ArchiMate и TOGAF 9")
-- характеристики самого софта (работа с репозиторием, многопользовательская работа, лицензирование и т.д.)
-- цели и способы использования в организации.

Софт PraxOS вполне мог бы унаследовать требования по характеристикам самого софта, но вот поддерживаемые модели и цели и способы использования в организации наследовать из традиционных оргмоделеров не нужно.

8. Интересно, что задача "догнать и перегнать гигантов современного оргмоделирования" не кажется такой уж несбыточной:
а) реализация мощного движка онтологического программирования с поддержкой DSL общего вида (проект dot15926, реализующий подход language workbench в части онтологического программирования) может дать фору в собственно программистской работе: реализация софта PraxOS как настройки этого софта "универсального моделера" на ряд определенных в PraxOS DSL оргмоделирования может оказаться более эффективной и масштабируемой по предметным областям, нежели реализация специализированного софта.
б) некоторый онтологический тренинг в разы увеличивает скорость понимания проблем тех или иных предлагаемых методов описаний (я думаю, что имеющие опыт моделирования в ISO 15926 люди читают тексты спецификации ArchiMate абсолютно другими глазами, нежели опытные объект-ориентированные или даже функциональные программисты), что даёт шанс быстрой разработки как-то совместимого между собой за счёт опоры на ISO 15926 набора микротеорий для помянутых в предыдущих пунктах постинга разных предметных областей организации деятельности.

Трудность и огромные риски проигрышу "мейнстриму оргмоделирования" лежит в задаче удобного и понятного рендеринга (см. про соотношение "написания парсеров" и "написания рендеров" в http://ailev.livejournal.com/925813.html?thread=9257845). Можно сказать, что по части "парсинга" мы вполне можем быть впереди планеты всей, но по причине де-факто нашего игнорирования рендеринга мы можем отстать принципиально. Так что сейчас в PraxOS нужно обратить особое внимание на нотации и рендеринг, чтобы дать в проект .15926 надлежащие вводные на этот счёт.

(4 comments | Leave a comment)

Comments
 
[User Picture]
From:justy_tylor
Date:July 29th, 2011 12:15 pm (UTC)
(Link)
По поводу [3]:

Отмэпить ArchiMate на ISO 24744 нельзя. Если перейти в метафору программного обеспечения, то и ArchiMate, и 24744 являются (в прагматике) не описаниями структур данных, а в чистом виде API.

Некоторые форматы данных в API могут пересекаться (например, статичная геометрия) и позволять обмен между (с определённой потерей точности).
Однако, нельзя выразить Maya API через 3DS Max API и наоборот. А для OpenGL и Direct3D, решающих идентичные задачи, вообще нет существенных общих паттернов.

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

Следующий вопрос - можно ли описать системоинженерные API по аналогии с обычными? Для обычных API существует группа языков http://en.wikipedia.org/wiki/Interface_description_language В которых уже заведены свои низкоуровневые примитивы - функция, метод, перечисление... В ISO 15926 ничего подобного нет, их придётся изобретать. И именно изобретать, а не драть с 24744, так как в 24744 более детальные паттерны и своя китайская классификация.

Третий вопрос - может ли это формальное описание быть потом хоть как-то использовано? Чем оно лучше человекочитаемого текста про ArchiMate со ссылками "если вас интересует похожее в 24744, то смотреть сюда"? Выполнение по одному API с последующей декомпиляцией в сущности другого даст нечитаемый кошмар. Какая-то интеграция - кусочек в одной подсистеме на ArchiMate, кусочек в другой на 24744 - но в каком виде? Например, возможна общая диаграммная нотация. И тогда соответствующий interface description language должен заранее разрабатываться под такие задачи.
[User Picture]
From:ailev
Date:July 29th, 2011 12:34 pm (UTC)
(Link)
Моё решение тут -- это попытаться таки от API (к какой, кстати, исполняющей машине? Мозгам специально обученных данным дисциплинам людей?) перейти к структурам данных PraxOS, единство которых поддерживается одной онтологией и терминологией.

То есть я ни в коей мере не призываю брать редактор ArchiMate и редактор ISO 24744 и как-то использовать один из них вместо другого. Тем не менее, полезно знать о том, что Passive и Active structure в одном из них примерно то же, что WorkProduct и Producer. Для многих людей знание об этой аналогии будет очень полезным.

Понятно, что для компьютера "аналогия" сегодня почти невыразима. Именно поэтому я готов долго мечтать о программах типа VivoMind и рассуждать о том, что у нас будет с понятием "паттерн".
[User Picture]
From:justy_tylor
Date:July 29th, 2011 12:50 pm (UTC)
(Link)
Да, только степень обучения чуть разная - у модельеров, которые ещё и пишут на этих API одна, а у пользователей, которые их только читают (и "выполняют" в голове) другая.
[User Picture]
From:ailev
Date:July 29th, 2011 04:05 pm (UTC)
(Link)
Я вот тут как раз поэтому про рендеры пишу в последнем абзаце -- рендеры (генераторы отчётов и прочие "денормализаторы" всех мастей) для как раз для "читателей и выполнятелей в голове", причем самой разной степени подготовки.
My Website Powered by LiveJournal.com