Системы систем
1. Системы систем -- это направление системной инженерии, занимающееся инженерией систем, отдельные части которых могут существовать автономно, были разработаны независимо друг от друга, и тем самым представляют собой полноценную целевую систему. Тем не менее, из этих автономных и независимых систем (кому-то) хочется сделать систему с эмерджентными свойствами.
2. Примеры, из-за которых пришлось вводить понятие системы систем:
а) телекоммуникационные системы ("сети сетей"), прежде всего интернет.
б) мультимодальные транспортные системы
в) обеспечивающие системы ("расширенное предприятие") в любом большом проекте системной инженерии
г) всякие взаимодействия родов войск в театре военных действий
д) любая организационная система (с быстрым проскоком всех уровней от "группы людей" до "общества в целом" и выхода на сплошную гуманитарщину безо всякой инженерии -- но с некоторыми особенностями, см. пункт 10). Тем самым в подходе "инженерии системы систем" можно рассматривать инженерию обеспечивающей системы проекта системной инженерии (см. пункт 11), реинжиниринг (или даже инжиниринг, в системах систем эти границы зыбки) какого-нибудь промышленного холдинга, тимбилдинг, создание страновых блоков, образование картелей, функционирование консорциумов, государственное строительство и т.д.. Как всегда в случае пересечения инженерных технологий и систем из (в конечном итоге) людей, делаю оговорку о безопасности (см. также пункт 10в).
3. Основная проблема в том, что для так определенной системы не подходят традиционные методы системной инженерии:
а) системы (подсистемы целевой системы) не нужно проектировать, закупать и т.д.. Они, как правило, уже есть -- уж какие есть.
б) совсем необязательно системный инженер (в том числе архитектор) имеет влияние на владельцев систем-составляющих. Его могут слушать, а также могут и не слушать.
в) поскольку автономные системы обычно должны продолжать работать, а "составлять из себя новую систему" у них является лишь дополнительной функцией к их основным функциям, то нельзя "все остановить, создать и отладить систему, а затем запустить в работу заново". Приходится править на ходу, согласовывая тщательно небольшие изменения (отсюда практически консенсус: говорят не столько о стадийном жизненном цикле, сколько об "эволюции", "инкрементальных изменениях", "мониторинге изменений"). Более того, править каждую систему, скорее всего, будет персонал этой системы-составляющей -- а не сотрудники целевой системы систем, у которой часто и персонала-то нет.
г) особо нужно отметить, что заказ на систему систем осуществляется в терминах capabilities (возможностей), а не functions (функций каких-то систем). То есть заказчики пытаются купить возможность что-то достичь, а не собственно системы. Системы уже давно куплены, существуют, у них есть владельцы и все необходимые функции. Но нужно достичь возможности что-то этим системам совместно сделать, тогда и говорят о системе систем.
Capabilities формулируются как "данная система должна обеспечивать возможность [и далее хотя бы один глагол того действия, которое она должна давать возможность сделать]".
д) системы систем появляются там и тогда, где у отдельных систем разные собственники, и для их совместной работы нужно устраивать переговорный процесс (по теории речевых актов Хабермаса иметь два уровня: дискурса с договоркой о протоколе взаимодействия и затем следование протоколу взаимодействия с регулярным вываливанием в дискурс в случае неработы этого протокола). В частности, собственники системы вряд ли строят свои системы на базе какой-то общей онтологии: у них своя (по типу) деятельность, и поэтому с необходимостью используется разная онтология (то есть их взгляды на мир отнюдь не разные группы описаний одной архитектуры! Ведь общей архитектуры у составляющих систем без системы систем по определению нет! Тем самым для описания системы систем нам нужно применять хитрое семантическое моделирование -- мы не можем гарантировать парадигмальную единообразность описания при декомпозиции, причем эта неоднородность совсем другого сорта, чем парадигмальное разнообразие при описании со сменой метода описаний (viewpoint) при сдвижке от стейкхолдера к стейхолдеру: для каждой составляющей системы в SoS меняется весь набор заинтересованных сторон и предпочитаемые ими языки и нотации! Так что "традиционная" моделеориентированная инженерия требований тут будет тоже хромать.
4. В литературе рассматриваются самые разные варианты появления заинтересованных в системе систем сторон: кто-то один с деньгами или без, несколько в разном заинтересованных сторон с деньгами и без, а также ситуации, когда в число этих сторон входят или не входят владельцы составляющих системы. Тем самым разговор о системе систем возникает каждый раз, когда речь идет о социотехнической системе.
5. В программировании, моделировании все чаще говорят о программировании и моделировании-в-большом, когда нужно сделать большую программную систему из разных компонент, работающих на разных компьютерах. Теория этого in-the-lagre только-только появляется, в жизни основные проблемы переходят туда (вместо программирования отдельных коротких автономных программ все чаще приходится программировать связки между такими программами). Более того, все чаще говорят, что "все, что могли, уже автоматизировали -- и теперь стоит задача интеграции островков автоматизации". Greenfield программирование перешло в brownfield. Вот ровно то же самое обсуждается для системы систем. Отличие в том, что составляющие системы с системе систем -- акторы (т.е. обладают собственным поведением). Если продолжить программистские аналогии, то разница между "системами систем" и "просто системами" как между Smalltalk-71 и Smalltalk-80 -- а именно, встроенным в них акторским пониманием. "Просто системы" -- это объект-ориентированный подход с пассивными объектами, которые "не могут ослушаться", а системы систем -- это акторы, которые работают асинхронно и автономно, и требуют для своей организации совсем другого отношения (парадигмы программирования), нежели объекты. Отсюда забавные следствия для объект-ориентированного моделирования (например, SysML/UML): поскольку оно не актор-ориентированное, то для описания архитектуры системы систем нужно как минимум менять язык моделеориентированной системной инженерии! С UML/SysML-диаграммами в системах систем делать нечего, хотя таких работ огромное количество.
6. Тема системы систем -- самая главная сейчас тема в западных военных закупках. Ибо оружия уже накуплено столько, что можно убить всех (на глобусе, а не только в стане потенциального противника) тысячу раз. Систем разведки уже есть столько, что можно разведать все и еще чуть-чуть. Транпорта хоть отбавляй. Единственная задача: нужно, чтобы все это как-то работало вместе -- договариваясь о целях, средствах, времени нанесения ударов, понимая последствия, оценивая риски, помогая друг другу. А вместе все современные военные системы не работают, и как этого добиться без совместного проектирования заново всех уже имеющихся систем, в общем случае непонятно. Поэтому военные сильно вкладываются в проблематику системы систем -- навязывая свою терминологию, засоряя Сеть своими "писанными кровью" уставами инженерии систем систем, и "просто систем" с обязательным добавлением туда случаев системы систем (http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf, http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Support%20Documentation/Early%20Systems%20Engineering%20Guide%2031Mar09.pdf и т.д.).
7. Выделяют следующие виды системы систем:
-- управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы составляющим системам и распоряжается ресурсами.
-- подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать составляющие системы самоизмениться согласно разработанной им архитектуре.
-- сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет.
-- виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга (например, современный интернет. Smart Grid тоже собирается быть такой системой).
8. У военных же есть и другой частый случай, который "путается" с системами систем: семейство систем -- когда все системы, составляющие семейство, не обнаруживают эмерджентности при взаимодействии -- но заказываются, используются, разрабатываются вместе. К этой концепции семейства систем близка концепция продуктных линий, о которой совсем отдельная песня: http://jcse.org.za/upload/events/100/product_lines_2_0_jcse_30apr2010presentation.pdf (тем не менее, близость "семейств" и "системы систем" даже в этой презентации тоже отмечается -- "The System of Systems engineering community speaks of directed vs. collaborative vs. acknowledged systems of systems. These correspond to proactive (top-down), proactive (bottom-up), and reactive software product lines.".
9. Большинство работ по инженерии систем представляют собой шаблон, в котором
а) формулируется сложность проблемы системы систем (сводящаяся к "не хотят, гады"!),
б) постулируется полное отсутствие методов работы с системами в системной инженерии (ибо системная инженерия занимается менеджентом технических систем, а не человеческих) и необходимость делать хоть что-нибудь
в) радостного замечания, что "вот тут совсем случайно мы обнаружили метод [далее взахлеб рассказывается о давным давно известных в менеджменте, экономике, социологии, проектном управлении, политологии и т.д. "гуманитарных" школах мысли -- но используется терминология "системы систем" и "эволюция"], и применили этот метод в [описание какого-нибудь "пилотного проекта"]".
Тем самым текущая "наука" про системы систем сводится к пересказу идей, давно и хорошо известных гуманитарщикам инженерным языком.
10. Тем не менее, инженерная специфика в системах систем важна: она вполне может позволить сделать прорывы в тех самых гуманитарных дисциплинах, ибо
а) основным методом работы с системами систем предлагается получение их архитектуры as is и архитектуры to be. Для этого прежде всего нужно понять и отмоделировать (перейти от понимания архитектуры к архитектурному описанию) "систему систем". Особо отмечу, что "архитектура" определяется в ISO 42010 как основная организация системы (а не основная структура: в пример приводится как раз интернет, у которого структуры по факту нет, а вот организация есть). "Организация", кстати, в наиболее общем онтологическом смысле -- это распределение функций по материалу, из которого сделана система. Именно архитектурное описание должно быть основным интеграционным средством, вокруг которого разворачивается коммуникация владельцев составляющих систем и других заинтересованных сторон, ведущих эволюцию системы систем.
б) поскольку основное в архитектуре -- это модели, то разговор об архитектуре с неизежностью требует формального моделирования (с указанием выбранного языка, нотации, контролем конфигурации получающейся архитектурной мегамодели и т.д.). Это дает строгость в рассуждениях, обычно недоступную для представителей гуманитарных дисциплин. Вокруг формальных моделей трудно эмоционально спорить, аргументируя размахиванием рук. Поэтому у инженеров есть шанс продвинуть теории, которые долго и с весьма переменным успехом разрабатывали гуманитарщики.
в) Отдельно оставим вопрос о безопасности: конечно, инженерные решения для создания системы систем могут привести к вполне инженерному созданию организаций-систем систем, само существование которых трудно оправдать морально или этически. Но эта дискуссия о безопасности встроенна в современную инженерию (но зачастую не встроена в "гумантираные науки", как это ни удивительно), поэтому есть шанс продвинуться и в этом вопросе.
11. Особым случаем "системы систем" является обеспечивающая система проекта системной инженерии: та организация (в системной инженерии определяемая как совокупность людей, оборудования с понятным разделением труда, полномочиями и ответственностью), которая продвигает целевую систему по ее жизненному циклу. Эта обеспечивающая система является системой систем по определению: там ведь есть люди, которые владеют собой сами, и лишь договариваются работать вместе в организации -- частью эти договоренности являются явными, а частью представляют собой эхо представлений о таких договоренностях, находящихся "в культуре" (устной, письменной, в стандартах, а то и в законодательстве -- т.е. не только в договоренностях, но и обычаях, и даже законах).
12. Еще один "особый случай" -- это понимание того, как устроена современная промышленность, которая медленно, но верно ползет от непосредственного конструирования своих изделий и сервисов к проектированию изделий из покупных деталей, самих по себе довольно сложных. Производители компьютеров закупают микросхемы и разъемы, нефтяники закупают насосы и трубопроводную арматуру, все что-то закупают на базе промышленных каталогов. И потом вся эта "система производственных систем" действует, как Промнет.
13. Smart Grid, определяемая ныне, как Enernet (такое название дал недавно автор Ethernet Боб Меткалф -- http://news.cnet.com/8301-11128_3-10203683-54.html). Генераторы-потребители, каждый из которых работает автономно, и то ли продает, то ли покупает энергию в зависимости от ситуации. Владельцы линий электропередачи, владельцы средств телекоммуникаций, и многие другие агенты, которые составляют из себя сеть. В случае России ситуация немного другая, нежели во всем мире: у нас уже есть объединенная энергосистема (к которой многие страны только хотят приблизиться), и нужно решать, как на этой живой инфраструктуре разворачивать ("эволюционировать") Smart Grid как систему систем.
14. Остается понять, в чем состоит специфика подхода инженерии системы систем и какие можно предложить методы этой инженерии:
а) практически консенсус, что взаимодействие (interoperability) обеспечивается стандартами (внутрисистемными, или -- о чем проще договориться -- внешними, т.е. отраслевыми или международными).
б) практически консенсус, что изменения инкрементальны, и описываются словом "эволюция". Более того, признается, что пока меняется составляющая система А, составляющая система B может попасть в суровый переплет с изменением всех планов, и вся "эволюция" остальных систем должна на это отреагировать. Поэтому у архитекторов странная дополнительная функция "мониторинга" неожиданного изменения составляющих систем своей системы систем (представьте себе системного инженера, у которого вдруг турбина проектируемой электростанции вдруг под давлением внешних обстоятельств решила изменить свое выходное напряжение и способ подключения к сети в одностороннем порядке -- и даже забыла об этом его уведомить! А ведь это в системах систем штатная ситуация).
в) практически консенсус, что системы должны рефлексировать то, что они сейчас делают (моделировать методы своей работы). Ибо без этого оказывается невозможным что-то поменять. Для меня это означает, что для работы с системами систем нужно использовать ISO 24744, позволяющий отмоделировать метод (я считаю, что этот стандарт может быть применен не только к методам разработки, но и просто к методам работы в целом).
г) постепенно зреет консенсус, что от "словарных" взаимодействий информационных систем придется переходить к семантическим технологиям (это идет от американской армии, флота, и авиации, которые выяснили, что их "сетевые взаимодействия" другим способом просто не обеспечить, и поэтому "эволюционно" переходят сейчас на семантические технологии). Мне в этом случае проще думать об использовании ISO 15926.
д) зреет понимание, что придется импортировать современные методы менеджмента организационных изменений -- попутно формализовав и заменив терминологию на "системную".
е) нормативную базу (например, регламенты деятельности каждой отдельной системы) правильно было бы оцифровать (те же "семантические технологии"), чтобы иметь хоть какую-то возможность валидизировать их потенциальную совместную работу при функционировании в системе систем. Можно, конечно, и "вручную", но компьютером всяко поиск коллизий проще делать. Тут, конечно, нужно ехидно заметить, что одновременно нужно разбираться с обеспечением соответствия "процессов в жизни" и "процессов из регламентов" -- написано и вбито в программы компьютеров одно, а делается обычно совсем другое. Но никто не говорил, что будет легко.
е) всякие "теории сложности" и прочие похожие заклинания по линии "продвинутого системного мышления", увы, пока не показали своей применимости (равно как и многие чисто кибернетические идеи с "обратными связями"). Хотя публикаций, конечно, хватает.
ж) реальный прогресс нужно ожидать тогда, когда гуманитарные (менеджмента, конфликтологии, политологии и т.д.) теории, агентский подход (с его "желаниями", "моделью мира" и "сотрудничеством" агентов) и системно-инженерный подход (с понятиями систем-холонов, каждая из которых является частью целого и в свою очередь целым одновременно, жизненного цикла, а также архитектурными идеями и идеями моделирования) склеются в месте. Это и будет будущая системо-системная инженерия.
Анонс: в Москве 18-20 октября будет проходить международный семинар по системам систем -- http://personal.stevens.edu/~bsauser/System_Readiness_Level/ICUMT_2010.html, я планирую там выступить. Чтобы попасть туда, пишите на указанные в тексте по ссылке контактные адреса.
2. Примеры, из-за которых пришлось вводить понятие системы систем:
а) телекоммуникационные системы ("сети сетей"), прежде всего интернет.
б) мультимодальные транспортные системы
в) обеспечивающие системы ("расширенное предприятие") в любом большом проекте системной инженерии
г) всякие взаимодействия родов войск в театре военных действий
д) любая организационная система (с быстрым проскоком всех уровней от "группы людей" до "общества в целом" и выхода на сплошную гуманитарщину безо всякой инженерии -- но с некоторыми особенностями, см. пункт 10). Тем самым в подходе "инженерии системы систем" можно рассматривать инженерию обеспечивающей системы проекта системной инженерии (см. пункт 11), реинжиниринг (или даже инжиниринг, в системах систем эти границы зыбки) какого-нибудь промышленного холдинга, тимбилдинг, создание страновых блоков, образование картелей, функционирование консорциумов, государственное строительство и т.д.. Как всегда в случае пересечения инженерных технологий и систем из (в конечном итоге) людей, делаю оговорку о безопасности (см. также пункт 10в).
3. Основная проблема в том, что для так определенной системы не подходят традиционные методы системной инженерии:
а) системы (подсистемы целевой системы) не нужно проектировать, закупать и т.д.. Они, как правило, уже есть -- уж какие есть.
б) совсем необязательно системный инженер (в том числе архитектор) имеет влияние на владельцев систем-составляющих. Его могут слушать, а также могут и не слушать.
в) поскольку автономные системы обычно должны продолжать работать, а "составлять из себя новую систему" у них является лишь дополнительной функцией к их основным функциям, то нельзя "все остановить, создать и отладить систему, а затем запустить в работу заново". Приходится править на ходу, согласовывая тщательно небольшие изменения (отсюда практически консенсус: говорят не столько о стадийном жизненном цикле, сколько об "эволюции", "инкрементальных изменениях", "мониторинге изменений"). Более того, править каждую систему, скорее всего, будет персонал этой системы-составляющей -- а не сотрудники целевой системы систем, у которой часто и персонала-то нет.
г) особо нужно отметить, что заказ на систему систем осуществляется в терминах capabilities (возможностей), а не functions (функций каких-то систем). То есть заказчики пытаются купить возможность что-то достичь, а не собственно системы. Системы уже давно куплены, существуют, у них есть владельцы и все необходимые функции. Но нужно достичь возможности что-то этим системам совместно сделать, тогда и говорят о системе систем.
Capabilities формулируются как "данная система должна обеспечивать возможность [и далее хотя бы один глагол того действия, которое она должна давать возможность сделать]".
д) системы систем появляются там и тогда, где у отдельных систем разные собственники, и для их совместной работы нужно устраивать переговорный процесс (по теории речевых актов Хабермаса иметь два уровня: дискурса с договоркой о протоколе взаимодействия и затем следование протоколу взаимодействия с регулярным вываливанием в дискурс в случае неработы этого протокола). В частности, собственники системы вряд ли строят свои системы на базе какой-то общей онтологии: у них своя (по типу) деятельность, и поэтому с необходимостью используется разная онтология (то есть их взгляды на мир отнюдь не разные группы описаний одной архитектуры! Ведь общей архитектуры у составляющих систем без системы систем по определению нет! Тем самым для описания системы систем нам нужно применять хитрое семантическое моделирование -- мы не можем гарантировать парадигмальную единообразность описания при декомпозиции, причем эта неоднородность совсем другого сорта, чем парадигмальное разнообразие при описании со сменой метода описаний (viewpoint) при сдвижке от стейкхолдера к стейхолдеру: для каждой составляющей системы в SoS меняется весь набор заинтересованных сторон и предпочитаемые ими языки и нотации! Так что "традиционная" моделеориентированная инженерия требований тут будет тоже хромать.
4. В литературе рассматриваются самые разные варианты появления заинтересованных в системе систем сторон: кто-то один с деньгами или без, несколько в разном заинтересованных сторон с деньгами и без, а также ситуации, когда в число этих сторон входят или не входят владельцы составляющих системы. Тем самым разговор о системе систем возникает каждый раз, когда речь идет о социотехнической системе.
5. В программировании, моделировании все чаще говорят о программировании и моделировании-в-большом, когда нужно сделать большую программную систему из разных компонент, работающих на разных компьютерах. Теория этого in-the-lagre только-только появляется, в жизни основные проблемы переходят туда (вместо программирования отдельных коротких автономных программ все чаще приходится программировать связки между такими программами). Более того, все чаще говорят, что "все, что могли, уже автоматизировали -- и теперь стоит задача интеграции островков автоматизации". Greenfield программирование перешло в brownfield. Вот ровно то же самое обсуждается для системы систем. Отличие в том, что составляющие системы с системе систем -- акторы (т.е. обладают собственным поведением). Если продолжить программистские аналогии, то разница между "системами систем" и "просто системами" как между Smalltalk-71 и Smalltalk-80 -- а именно, встроенным в них акторским пониманием. "Просто системы" -- это объект-ориентированный подход с пассивными объектами, которые "не могут ослушаться", а системы систем -- это акторы, которые работают асинхронно и автономно, и требуют для своей организации совсем другого отношения (парадигмы программирования), нежели объекты. Отсюда забавные следствия для объект-ориентированного моделирования (например, SysML/UML): поскольку оно не актор-ориентированное, то для описания архитектуры системы систем нужно как минимум менять язык моделеориентированной системной инженерии! С UML/SysML-диаграммами в системах систем делать нечего, хотя таких работ огромное количество.
6. Тема системы систем -- самая главная сейчас тема в западных военных закупках. Ибо оружия уже накуплено столько, что можно убить всех (на глобусе, а не только в стане потенциального противника) тысячу раз. Систем разведки уже есть столько, что можно разведать все и еще чуть-чуть. Транпорта хоть отбавляй. Единственная задача: нужно, чтобы все это как-то работало вместе -- договариваясь о целях, средствах, времени нанесения ударов, понимая последствия, оценивая риски, помогая друг другу. А вместе все современные военные системы не работают, и как этого добиться без совместного проектирования заново всех уже имеющихся систем, в общем случае непонятно. Поэтому военные сильно вкладываются в проблематику системы систем -- навязывая свою терминологию, засоряя Сеть своими "писанными кровью" уставами инженерии систем систем, и "просто систем" с обязательным добавлением туда случаев системы систем (http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf, http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Support%20Documentation/Early%20Systems%20Engineering%20Guide%2031Mar09.pdf и т.д.).
7. Выделяют следующие виды системы систем:
-- управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы составляющим системам и распоряжается ресурсами.
-- подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать составляющие системы самоизмениться согласно разработанной им архитектуре.
-- сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет.
-- виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга (например, современный интернет. Smart Grid тоже собирается быть такой системой).
8. У военных же есть и другой частый случай, который "путается" с системами систем: семейство систем -- когда все системы, составляющие семейство, не обнаруживают эмерджентности при взаимодействии -- но заказываются, используются, разрабатываются вместе. К этой концепции семейства систем близка концепция продуктных линий, о которой совсем отдельная песня: http://jcse.org.za/upload/events/100/product_lines_2_0_jcse_30apr2010presentation.pdf (тем не менее, близость "семейств" и "системы систем" даже в этой презентации тоже отмечается -- "The System of Systems engineering community speaks of directed vs. collaborative vs. acknowledged systems of systems. These correspond to proactive (top-down), proactive (bottom-up), and reactive software product lines.".
9. Большинство работ по инженерии систем представляют собой шаблон, в котором
а) формулируется сложность проблемы системы систем (сводящаяся к "не хотят, гады"!),
б) постулируется полное отсутствие методов работы с системами в системной инженерии (ибо системная инженерия занимается менеджентом технических систем, а не человеческих) и необходимость делать хоть что-нибудь
в) радостного замечания, что "вот тут совсем случайно мы обнаружили метод [далее взахлеб рассказывается о давным давно известных в менеджменте, экономике, социологии, проектном управлении, политологии и т.д. "гуманитарных" школах мысли -- но используется терминология "системы систем" и "эволюция"], и применили этот метод в [описание какого-нибудь "пилотного проекта"]".
Тем самым текущая "наука" про системы систем сводится к пересказу идей, давно и хорошо известных гуманитарщикам инженерным языком.
10. Тем не менее, инженерная специфика в системах систем важна: она вполне может позволить сделать прорывы в тех самых гуманитарных дисциплинах, ибо
а) основным методом работы с системами систем предлагается получение их архитектуры as is и архитектуры to be. Для этого прежде всего нужно понять и отмоделировать (перейти от понимания архитектуры к архитектурному описанию) "систему систем". Особо отмечу, что "архитектура" определяется в ISO 42010 как основная организация системы (а не основная структура: в пример приводится как раз интернет, у которого структуры по факту нет, а вот организация есть). "Организация", кстати, в наиболее общем онтологическом смысле -- это распределение функций по материалу, из которого сделана система. Именно архитектурное описание должно быть основным интеграционным средством, вокруг которого разворачивается коммуникация владельцев составляющих систем и других заинтересованных сторон, ведущих эволюцию системы систем.
б) поскольку основное в архитектуре -- это модели, то разговор об архитектуре с неизежностью требует формального моделирования (с указанием выбранного языка, нотации, контролем конфигурации получающейся архитектурной мегамодели и т.д.). Это дает строгость в рассуждениях, обычно недоступную для представителей гуманитарных дисциплин. Вокруг формальных моделей трудно эмоционально спорить, аргументируя размахиванием рук. Поэтому у инженеров есть шанс продвинуть теории, которые долго и с весьма переменным успехом разрабатывали гуманитарщики.
в) Отдельно оставим вопрос о безопасности: конечно, инженерные решения для создания системы систем могут привести к вполне инженерному созданию организаций-систем систем, само существование которых трудно оправдать морально или этически. Но эта дискуссия о безопасности встроенна в современную инженерию (но зачастую не встроена в "гумантираные науки", как это ни удивительно), поэтому есть шанс продвинуться и в этом вопросе.
11. Особым случаем "системы систем" является обеспечивающая система проекта системной инженерии: та организация (в системной инженерии определяемая как совокупность людей, оборудования с понятным разделением труда, полномочиями и ответственностью), которая продвигает целевую систему по ее жизненному циклу. Эта обеспечивающая система является системой систем по определению: там ведь есть люди, которые владеют собой сами, и лишь договариваются работать вместе в организации -- частью эти договоренности являются явными, а частью представляют собой эхо представлений о таких договоренностях, находящихся "в культуре" (устной, письменной, в стандартах, а то и в законодательстве -- т.е. не только в договоренностях, но и обычаях, и даже законах).
12. Еще один "особый случай" -- это понимание того, как устроена современная промышленность, которая медленно, но верно ползет от непосредственного конструирования своих изделий и сервисов к проектированию изделий из покупных деталей, самих по себе довольно сложных. Производители компьютеров закупают микросхемы и разъемы, нефтяники закупают насосы и трубопроводную арматуру, все что-то закупают на базе промышленных каталогов. И потом вся эта "система производственных систем" действует, как Промнет.
13. Smart Grid, определяемая ныне, как Enernet (такое название дал недавно автор Ethernet Боб Меткалф -- http://news.cnet.com/8301-11128_3-10203683-54.html). Генераторы-потребители, каждый из которых работает автономно, и то ли продает, то ли покупает энергию в зависимости от ситуации. Владельцы линий электропередачи, владельцы средств телекоммуникаций, и многие другие агенты, которые составляют из себя сеть. В случае России ситуация немного другая, нежели во всем мире: у нас уже есть объединенная энергосистема (к которой многие страны только хотят приблизиться), и нужно решать, как на этой живой инфраструктуре разворачивать ("эволюционировать") Smart Grid как систему систем.
14. Остается понять, в чем состоит специфика подхода инженерии системы систем и какие можно предложить методы этой инженерии:
а) практически консенсус, что взаимодействие (interoperability) обеспечивается стандартами (внутрисистемными, или -- о чем проще договориться -- внешними, т.е. отраслевыми или международными).
б) практически консенсус, что изменения инкрементальны, и описываются словом "эволюция". Более того, признается, что пока меняется составляющая система А, составляющая система B может попасть в суровый переплет с изменением всех планов, и вся "эволюция" остальных систем должна на это отреагировать. Поэтому у архитекторов странная дополнительная функция "мониторинга" неожиданного изменения составляющих систем своей системы систем (представьте себе системного инженера, у которого вдруг турбина проектируемой электростанции вдруг под давлением внешних обстоятельств решила изменить свое выходное напряжение и способ подключения к сети в одностороннем порядке -- и даже забыла об этом его уведомить! А ведь это в системах систем штатная ситуация).
в) практически консенсус, что системы должны рефлексировать то, что они сейчас делают (моделировать методы своей работы). Ибо без этого оказывается невозможным что-то поменять. Для меня это означает, что для работы с системами систем нужно использовать ISO 24744, позволяющий отмоделировать метод (я считаю, что этот стандарт может быть применен не только к методам разработки, но и просто к методам работы в целом).
г) постепенно зреет консенсус, что от "словарных" взаимодействий информационных систем придется переходить к семантическим технологиям (это идет от американской армии, флота, и авиации, которые выяснили, что их "сетевые взаимодействия" другим способом просто не обеспечить, и поэтому "эволюционно" переходят сейчас на семантические технологии). Мне в этом случае проще думать об использовании ISO 15926.
д) зреет понимание, что придется импортировать современные методы менеджмента организационных изменений -- попутно формализовав и заменив терминологию на "системную".
е) нормативную базу (например, регламенты деятельности каждой отдельной системы) правильно было бы оцифровать (те же "семантические технологии"), чтобы иметь хоть какую-то возможность валидизировать их потенциальную совместную работу при функционировании в системе систем. Можно, конечно, и "вручную", но компьютером всяко поиск коллизий проще делать. Тут, конечно, нужно ехидно заметить, что одновременно нужно разбираться с обеспечением соответствия "процессов в жизни" и "процессов из регламентов" -- написано и вбито в программы компьютеров одно, а делается обычно совсем другое. Но никто не говорил, что будет легко.
е) всякие "теории сложности" и прочие похожие заклинания по линии "продвинутого системного мышления", увы, пока не показали своей применимости (равно как и многие чисто кибернетические идеи с "обратными связями"). Хотя публикаций, конечно, хватает.
ж) реальный прогресс нужно ожидать тогда, когда гуманитарные (менеджмента, конфликтологии, политологии и т.д.) теории, агентский подход (с его "желаниями", "моделью мира" и "сотрудничеством" агентов) и системно-инженерный подход (с понятиями систем-холонов, каждая из которых является частью целого и в свою очередь целым одновременно, жизненного цикла, а также архитектурными идеями и идеями моделирования) склеются в месте. Это и будет будущая системо-системная инженерия.
Анонс: в Москве 18-20 октября будет проходить международный семинар по системам систем -- http://personal.stevens.edu/~bsauser/System_Readiness_Level/ICUMT_2010.html, я планирую там выступить. Чтобы попасть туда, пишите на указанные в тексте по ссылке контактные адреса.