Что моделировать в организации, или опять о софте 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 надлежащие вводные на этот счёт.
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 надлежащие вводные на этот счёт.