О системах систем и их моделировании
Несолько тезисов и ссылок для памяти:
1. Понятие "системы систем" (http://ailev.livejournal.com/856576.html), а также system of systems engineering стремительно распространяется по миру. Проблема в том, что вчера руководитель группы инженерии системы систем Michael Henshaw (http://www.lboro.ac.uk/departments/el/research/systems/esos/index.html) подтвердил мне, что никакой теории или формализма или каких-нибудь специальных понятий пока для системы систем не придумано (а лучшее изобретение -- классификация системы систем из пункта 7 по первой ссылке. Ага, начальная стадия любой науки -- попытки классификации замеченных феноменов, до момента нахождения основных объектов данной дисциплины). Но зато "огромный интерес к проблеме со стороны наших клиентов", "огромное финансирование со стороны Европейского Союза", "включение в учебные программы" -- и дальше есть надежда, что когда-нибудь все эти ожидания будут оправданы и та самая системы-системная инженерия (как это будет есть сказать по-русски?!) появится со своими основными понятиями и практиками. А пока -- прихват знаний изо всех других областей и пересказ этих знаний в терминах систем.
2. Попытки построить новое понятие в системах систем идут через federation, capabilities (и далее services -- по сопричастности). Придется более плотно разбираться с ними всеми. Ну, с федерированием мы по факту уже начали (http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2012_03_01 -- и там я написал некоторый ориентированный на онтологов Synthesis http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012_SystemsFederationIntegration_Synthesis), а вот с capabilities и services придется еще повозиться.
3. Вот разбирательство Chris Partridge с сервисами: http://www.modelfutures.com/file_download/17/MOD+CIO+-+Service+Analysis+Report+-+v1.3.pdf and http://www.oasis-open.org/committees/download.php/41420/Chris%20Partridge.pdf. Из этих же документов можно заключить, что ни с сервисами, ни с capability еще не всё понятно.
4. С capability возятся в INCOSE UK Chapter. Вот онтология capability тамошнего производства: http://www.incoseonline.org.uk/Groups/Capability_Working_Group/Other_Documents.aspx?CatID=Groups&SubCat=Capability_Working_Group. Понятно, что слово идёт от военных, которым нужно как-то едино мыслить результаты траты единого бюджета (каковые результаты траты абсолютно не хотят слипаться в одну супер-пупер-надсистему, которая умеет вести много-много разнородных операций на суше, на море, в воздухе и далее везде). Но всё то же самое можно мыслить и в плане соорганизации промышленной эко-системы (мобильной телефонии, или даже электроэнергетики), на уровне отраслевых консорциумов по стандартизации.
5. Еще одно место, где что-то происходит -- это инициатива INCOSE MBSE (http://www.omgwiki.org/MBSE), там есть группа System of Systems/Enterprise Modeling (http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise, самая свежая презентация -- http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:mbse_iw_2012-sos-enterprise_modeling-introduction-williamson.ppt).
6. Понятно, что в MBSE все занимаются моделями (главным образом на SysML), но есть и Ontology Action Team (http://www.omgwiki.org/MBSE/doku.php?id=mbse:ontology) куда меня в этом месяце записали, хотя еще и не отразили на этой странице. С другой стороны, там уже помянут ISO 15926 и даже есть какое-то свеженькое отражение обсуждений текущего Ontology Summit 2012 (www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:current_state_of_ontology_in_engineering_systems_29-mar-12.pdf). Вопрос, насколько мы сможем дать что-то из "систем систем" и "архитектуры/моделирования предприятий" в эту группу онтологий. Ибо мало что-то понимать в онтологии, нужно еще и прикладывать эти знания к чему-то -- то есть заниматься онтологизированием/моделированием/программированием (ну, и методологизированием до кучи).
7. Запомним: "системы систем", "распределенный", "эко-система", "федерирование" -- это про одно и то же.
8. Вот краткий списочек задач, которые неплохо бы продумать в ближайшее время:
-- насколько можно пробовать обобщить подход Архимейта к архитектуре (матрица деятельности/информологии/даталогии предприятия на выполнителей-работы-объекты) -- с учётом того, что дополнения ArchiMate 2.0 пока там пришиты сбоку и требуется какая-то унификация.
-- adaptive case management (http://ailev.livejournal.com/946134.html, и требования к IT-системам его поддержки http://mtubook.wordpress.com/2012/02/20/requirements-for-an-acm-system/) как общая парадигма разговора об управлении процессами/проектами/программами/поручениями, issue tracking и case management. Разбиения кейса (Case Breakdown Structure -- как это могло бы быть?). Жизненный цикл кейса. Специализации кейса (т.е. классификация).
-- шаблоны adaptive case management, методологии разработки/описания жизненного цикла/situational method engineering (http://ailev.livejournal.com/905099.html), дисциплины и практики -- унификация говорения об этом. Опять же: method breakdown structure -- как это могло бы быть? Какой жизненный цикл воплощения метода (от каталога метода к реализации в endeavour?), аспект-ориентированные описания (множественные классификации?) и weaving методов -- в софте и далее в жизни.
-- связь целеполагания, стратегирования, обоснований (http://ailev.livejournal.com/811715.html): как для уровня предприятия (архитектуры), так и для уровня целевой системы (того, что делает предприятие). Т.е. связь ArhciMate 2.0 motivation extension (http://pubs.opengroup.org/architecture/archimate2-doc/m/chap10.html), карт действий и результатов (http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2) времени определения системы и assurance case (http://ailev.livejournal.com/578461.html, оно же quality cases, например подход QASAR, включающий requirement и architectural case -- http://www.sei.cmu.edu/reports/06hb001.pdf) времени воплощения системы.
-- распределенный adaptive case management (или федерация issue trackers/PLM систем крупного инженерного проекта)
-- что такое управление конфигурацией для кейса (привязка действий к объектам работы), в том числе в распределенных кейсах
-- capabilities как возможность выполнения кейсов
-- распределенное управление конфигурацией (перенос опыта софтовых систем управления конфигурацией http://en.wikipedia.org/wiki/Distributed_revision_control на PLM системы -- в части как целевой системы, так и обеспечивающей системы/предприятия). Сообразить, что такое управление конфигурацией системы систем (обеспечивающая система). Сообразить, что такое для кейса (что там branching/converging в кейсах).
-- эко-система как система систем. Интеграция информации и выполнения работ уровня эко-системы
-- ОргЛан (http://praxos.livejournal.com/13689.html), на котором это всё можно выразить (а пока пользуемся Архимейтом: за неимением гербовой будем пока писать на простой).
-- собственно, онтология для capability и services в терминах всего вышесказанного, продумывание SOA на этом материале, интеграционных/федеративных архитектур для информации и кейсов/процессов/практик/проектов жизненного цикла и т.д.
-- не забыть идею про измерение качества получившихся результатов размышлений (системные инженеры мы, али кто?!). Главный критерий у нас тут -- это бОльшая компактность описаний/моделей эко-систем (и их частных случаев -- предприятий) по сравнению с сегодняшним методологическим разнотравьем. Но метрик пока нет, следовательно их нужно придумать. Ибо нужно наглядно демонстрировать окружающим, почему мы всем этим занимаемся, и почему наши результаты размышлений круче, чем любые альтернативные.
Нужно бежать со всех ног, чтобы только-только остаться на месте...
1. Понятие "системы систем" (http://ailev.livejournal.com/856576.html), а также system of systems engineering стремительно распространяется по миру. Проблема в том, что вчера руководитель группы инженерии системы систем Michael Henshaw (http://www.lboro.ac.uk/departments/el/research/systems/esos/index.html) подтвердил мне, что никакой теории или формализма или каких-нибудь специальных понятий пока для системы систем не придумано (а лучшее изобретение -- классификация системы систем из пункта 7 по первой ссылке. Ага, начальная стадия любой науки -- попытки классификации замеченных феноменов, до момента нахождения основных объектов данной дисциплины). Но зато "огромный интерес к проблеме со стороны наших клиентов", "огромное финансирование со стороны Европейского Союза", "включение в учебные программы" -- и дальше есть надежда, что когда-нибудь все эти ожидания будут оправданы и та самая системы-системная инженерия (как это будет есть сказать по-русски?!) появится со своими основными понятиями и практиками. А пока -- прихват знаний изо всех других областей и пересказ этих знаний в терминах систем.
2. Попытки построить новое понятие в системах систем идут через federation, capabilities (и далее services -- по сопричастности). Придется более плотно разбираться с ними всеми. Ну, с федерированием мы по факту уже начали (http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2012_03_01 -- и там я написал некоторый ориентированный на онтологов Synthesis http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012_SystemsFederationIntegration_Synthesis), а вот с capabilities и services придется еще повозиться.
3. Вот разбирательство Chris Partridge с сервисами: http://www.modelfutures.com/file_download/17/MOD+CIO+-+Service+Analysis+Report+-+v1.3.pdf and http://www.oasis-open.org/committees/download.php/41420/Chris%20Partridge.pdf. Из этих же документов можно заключить, что ни с сервисами, ни с capability еще не всё понятно.
4. С capability возятся в INCOSE UK Chapter. Вот онтология capability тамошнего производства: http://www.incoseonline.org.uk/Groups/Capability_Working_Group/Other_Documents.aspx?CatID=Groups&SubCat=Capability_Working_Group. Понятно, что слово идёт от военных, которым нужно как-то едино мыслить результаты траты единого бюджета (каковые результаты траты абсолютно не хотят слипаться в одну супер-пупер-надсистему, которая умеет вести много-много разнородных операций на суше, на море, в воздухе и далее везде). Но всё то же самое можно мыслить и в плане соорганизации промышленной эко-системы (мобильной телефонии, или даже электроэнергетики), на уровне отраслевых консорциумов по стандартизации.
5. Еще одно место, где что-то происходит -- это инициатива INCOSE MBSE (http://www.omgwiki.org/MBSE), там есть группа System of Systems/Enterprise Modeling (http://www.omgwiki.org/MBSE/doku.php?id=mbse:enterprise, самая свежая презентация -- http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:mbse_iw_2012-sos-enterprise_modeling-introduction-williamson.ppt).
6. Понятно, что в MBSE все занимаются моделями (главным образом на SysML), но есть и Ontology Action Team (http://www.omgwiki.org/MBSE/doku.php?id=mbse:ontology) куда меня в этом месяце записали, хотя еще и не отразили на этой странице. С другой стороны, там уже помянут ISO 15926 и даже есть какое-то свеженькое отражение обсуждений текущего Ontology Summit 2012 (www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:current_state_of_ontology_in_engineering_systems_29-mar-12.pdf). Вопрос, насколько мы сможем дать что-то из "систем систем" и "архитектуры/моделирования предприятий" в эту группу онтологий. Ибо мало что-то понимать в онтологии, нужно еще и прикладывать эти знания к чему-то -- то есть заниматься онтологизированием/моделированием/программированием (ну, и методологизированием до кучи).
7. Запомним: "системы систем", "распределенный", "эко-система", "федерирование" -- это про одно и то же.
8. Вот краткий списочек задач, которые неплохо бы продумать в ближайшее время:
-- насколько можно пробовать обобщить подход Архимейта к архитектуре (матрица деятельности/информологии/даталогии предприятия на выполнителей-работы-объекты) -- с учётом того, что дополнения ArchiMate 2.0 пока там пришиты сбоку и требуется какая-то унификация.
-- adaptive case management (http://ailev.livejournal.com/946134.html, и требования к IT-системам его поддержки http://mtubook.wordpress.com/2012/02/20/requirements-for-an-acm-system/) как общая парадигма разговора об управлении процессами/проектами/программами/поручениями, issue tracking и case management. Разбиения кейса (Case Breakdown Structure -- как это могло бы быть?). Жизненный цикл кейса. Специализации кейса (т.е. классификация).
-- шаблоны adaptive case management, методологии разработки/описания жизненного цикла/situational method engineering (http://ailev.livejournal.com/905099.html), дисциплины и практики -- унификация говорения об этом. Опять же: method breakdown structure -- как это могло бы быть? Какой жизненный цикл воплощения метода (от каталога метода к реализации в endeavour?), аспект-ориентированные описания (множественные классификации?) и weaving методов -- в софте и далее в жизни.
-- связь целеполагания, стратегирования, обоснований (http://ailev.livejournal.com/811715.html): как для уровня предприятия (архитектуры), так и для уровня целевой системы (того, что делает предприятие). Т.е. связь ArhciMate 2.0 motivation extension (http://pubs.opengroup.org/architecture/archimate2-doc/m/chap10.html), карт действий и результатов (http://praxos.ru/index.php/%D0%9A%D0%B0%D1%80%D1%82%D0%B0_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B9_%D0%B8_%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82%D0%BE%D0%B2) времени определения системы и assurance case (http://ailev.livejournal.com/578461.html, оно же quality cases, например подход QASAR, включающий requirement и architectural case -- http://www.sei.cmu.edu/reports/06hb001.pdf) времени воплощения системы.
-- распределенный adaptive case management (или федерация issue trackers/PLM систем крупного инженерного проекта)
-- что такое управление конфигурацией для кейса (привязка действий к объектам работы), в том числе в распределенных кейсах
-- capabilities как возможность выполнения кейсов
-- распределенное управление конфигурацией (перенос опыта софтовых систем управления конфигурацией http://en.wikipedia.org/wiki/Distributed_revision_control на PLM системы -- в части как целевой системы, так и обеспечивающей системы/предприятия). Сообразить, что такое управление конфигурацией системы систем (обеспечивающая система). Сообразить, что такое для кейса (что там branching/converging в кейсах).
-- эко-система как система систем. Интеграция информации и выполнения работ уровня эко-системы
-- ОргЛан (http://praxos.livejournal.com/13689.html), на котором это всё можно выразить (а пока пользуемся Архимейтом: за неимением гербовой будем пока писать на простой).
-- собственно, онтология для capability и services в терминах всего вышесказанного, продумывание SOA на этом материале, интеграционных/федеративных архитектур для информации и кейсов/процессов/практик/проектов жизненного цикла и т.д.
-- не забыть идею про измерение качества получившихся результатов размышлений (системные инженеры мы, али кто?!). Главный критерий у нас тут -- это бОльшая компактность описаний/моделей эко-систем (и их частных случаев -- предприятий) по сравнению с сегодняшним методологическим разнотравьем. Но метрик пока нет, следовательно их нужно придумать. Ибо нужно наглядно демонстрировать окружающим, почему мы всем этим занимаемся, и почему наши результаты размышлений круче, чем любые альтернативные.
Нужно бежать со всех ног, чтобы только-только остаться на месте...