Анатолий, посмотрел запись Вашей последней лекции, и кусок о "системе систем" оставил некоторую... назовем это "неудовлетворенностью" подходом. Вы несколько раз обращаете внимание на то, что деятельность архитектора "большой" системы не может в системе систем быть поддержана типовыми практиками. В частности, что говоря о capabilities, нельзя их сводить к требованиям и т.п. И что вообще системноинженерный подход не применим к работе с этими системами.
Но IMHO здесь возможен другой взгляд, прямо следующий из основ. Ведь инженерная система не существует в природе, она определяется кем-то, кто имеет собственное (или транслирует чужое - внешних стейкхолдеров) намерение что-то этакое целенаправленно сделать. Но коли так, то система возникает в глазах смотрящего всякий раз, когда у него появляются цели и намерения. И определяется она этими целями - и ничем более.
Возьмем задачу добиться взаимодействия на поле боя ВВС, спецназа ГРУ и там каких нибудь ФАПСИ. Что мешает замыслить это будущее взаимодействие как сервис, предоставляемый некоторой новой (специально замысленной ровно для этого) системой. Здесь есть (да и есть ли? см. ниже про фермы) особенность, что архитектор системы вместо создания своего собственного ВВС с нужными интерфейсами (вот была б потеха!), хочет осущесвить бриколаж - использовать сервисы уже действующих систем, "включить" их и в свою систему тоже.
Ну и ладно - это просто расширит круг стейкхолдеров. Помимо стейкхолдеров проектируемой системы (какой-нибудь оперативный отдел Генштаба), в число стейкхолдеров, выдвигающих свои требования войдут "владельцы" всех "независимых" подсистем (командование ВВС, ГРУ, ФАПСИ). А далее включается стандартный процесс - цели, требования, архитектура, стандарты для интерфейсов. Собственно, в жизни оно так и происходит - стандарты ведь накапливаются из таких вот странных договоренностей. Когда надо ВВС совмещать и с ГРУ, и с аэродромом, и с училищами, и до хрена еще с чем.
Но подход-то все тот же самый, без изменений вообще. Вся поправка на "независимые" подсистемы сводится к расширению числа стейкхолдеров.
--- Замечание "в сторону" ---
Есть ощущение, что в классификации "систем систем" есть изрядное лукавство. Здесь происходит подмена понятий. Забывается, что система (инженерная) не существует в природе как таковая. Она делается целенаправленно. Поэтому говорить об интернет, как инженерной системе (с позиции инженера) - вообще странно. С позиции ученого - да пожалуйста! С позиции потребителя - тоже понятно, он использует возможности интернет AS IS. Оба они подходят к интернет, существующему постфактум. А вот где тут возникает позиция "инженера интернета" - непонятно. Нет такой позиции, а значит и интернета, как инженерной системы - тоже нет. Как нет инженерной системы "Земля" или "Солнечная система". Включать их в единую классификацию - это прямо по Борхесу "нарисованные тонкой кисточкой на рисовой бумаге".
Приходится разделять эволюционирующие "артефакты" (которые никто не проектирует - они системами являются лишь для постфактум-исследований) и проектируемые "инженерные системы". Первые представляют интерес для инженера как некие сущности, которыми он ПОЛЬЗУЕТСЯ, и только. Он же может пользоваться сущностью "корова" при проектировании какой-нибудь фермы. Но сам корову не проектирует. И доступа к изменению интерфейсов коровы у него нет. И с создателем интерфейсов он тоже поговорить не может за отсутствием оного. Он ее берет AS IS. А если интерфейсы коровы начнут стремительно меняться - будет приноравливаться.
Вы правы, удовлетворенности в "системах систем" нет ни у кого, и я рад, что какая-то неудовлетворенность после моей лекции остаётся -- материал не выглядит "отлитым в граните" (с).
По многим вашим замечаниям я давал пояснения, только они в силу понятных причин не в одном месте курса собраны.
Если вы определяете границы системы, то вы что-то хотите с ней сделать. А хоть и что-то исследовать (необязательно полную практику системной инженерии применять). Кстати, один из способов изготовления системы -- это её покупка, а не самостоятельное изготовление. В системах систем вы вольны определять систему, как вам хочется в зависимости от ваших потребностей -- но не факт, что вы сможете использовать какой-то традиционный жизненный цикл для этой системы. То есть определить систему вы вольны, а вот изготовить/закупить нужный функционал у вас может и не получиться: полномочий не хватит. Жизнь сложна, и каждый раз она не будет укладываться в учебную схему, нужно будет думать головой.
Ну вот мне как раз и непонятно, что мешает "уложить" в стандартный подход эту ситуацию. Я разумеется, вижу в ней особенности, но не такие, чтобы "ужас-ужас".
IMHO необходимость привлекать сторонние системы (уже работающие, со своими хозяевами, которые до сих пор ни сном, ни духом...) является настолько распространенной, что без нее вообще с социотехническими системами - никуда. То есть, ситуация системы систем - по умолчанию присутствует чуть ли не в любом проекте. Работника в нужную роль поставить - ну чем не система систем?
А вот про нехватку полномочий - тут совсем непонятно. Если я в какой-то момент понимаю, что мне полномочий не хватает (а их поначалу редко когда хватает - они появляются по мере разговоров) и договориться со всеми стейкхолдерами я не могу (получив нужные мне полномочия от них) - это IMO повод честно заявить "эту систему я сделать не могу". Или придумать другую архитектуру, в которой мне полномочий хватит.
Покупка, кстати говоря - это тот самый вариант, когда полномочия честно покупаются.
Вы с одной стороны, повторяете рассуждения сторонников подхода "системы систем" (что никакой классической системной инженерии не существует, а есть только системы систем), с другой стороны -- делаете прямо противоположный вывод :-)
Насчет покупки полномочий, так есть давнишний анекдот -- бабка купила булочку в булочной, и теперь требует чтобы на инвестированные ей деньги теперь платились ей дивиденды, можно даже булочками :-)
Сходство рассуждений в том, что отличий существенных нет. Но вывод отсюда делаю, что незачем огород городить о каких-то особых системах систем. Если они и крякают как системы, и плавают похоже...
Есть хороший аппарат системной инженерии, так его и надо расширять, причем понятно даже где: выбор архитектуры (включение "независимых" систем в качестве подсистем) может повлечь расширение границ системы - через включение дополнительных стейкхолдеров.
Как в анекдоте про кипячение чайника. Если в чайнике нет воды, нужно ее налить и поставить чайник на огонь. Если вода уже есть, вылить ее и свести задачу к предыдущей :)
Но IMHO здесь возможен другой взгляд, прямо следующий из основ. Ведь инженерная система не существует в природе, она определяется кем-то, кто имеет собственное (или транслирует чужое - внешних стейкхолдеров) намерение что-то этакое целенаправленно сделать. Но коли так, то система возникает в глазах смотрящего всякий раз, когда у него появляются цели и намерения. И определяется она этими целями - и ничем более.
Возьмем задачу добиться взаимодействия на поле боя ВВС, спецназа ГРУ и там каких нибудь ФАПСИ. Что мешает замыслить это будущее взаимодействие как сервис, предоставляемый некоторой новой (специально замысленной ровно для этого) системой. Здесь есть (да и есть ли? см. ниже про фермы) особенность, что архитектор системы вместо создания своего собственного ВВС с нужными интерфейсами (вот была б потеха!), хочет осущесвить бриколаж - использовать сервисы уже действующих систем, "включить" их и в свою систему тоже.
Ну и ладно - это просто расширит круг стейкхолдеров. Помимо стейкхолдеров проектируемой системы (какой-нибудь оперативный отдел Генштаба), в число стейкхолдеров, выдвигающих свои требования войдут "владельцы" всех "независимых" подсистем (командование ВВС, ГРУ, ФАПСИ). А далее включается стандартный процесс - цели, требования, архитектура, стандарты для интерфейсов. Собственно, в жизни оно так и происходит - стандарты ведь накапливаются из таких вот странных договоренностей. Когда надо ВВС совмещать и с ГРУ, и с аэродромом, и с училищами, и до хрена еще с чем.
Но подход-то все тот же самый, без изменений вообще. Вся поправка на "независимые" подсистемы сводится к расширению числа стейкхолдеров.
--- Замечание "в сторону" ---
Есть ощущение, что в классификации "систем систем" есть изрядное лукавство. Здесь происходит подмена понятий. Забывается, что система (инженерная) не существует в природе как таковая. Она делается целенаправленно. Поэтому говорить об интернет, как инженерной системе (с позиции инженера) - вообще странно. С позиции ученого - да пожалуйста! С позиции потребителя - тоже понятно, он использует возможности интернет AS IS. Оба они подходят к интернет, существующему постфактум. А вот где тут возникает позиция "инженера интернета" - непонятно. Нет такой позиции, а значит и интернета, как инженерной системы - тоже нет. Как нет инженерной системы "Земля" или "Солнечная система". Включать их в единую классификацию - это прямо по Борхесу "нарисованные тонкой кисточкой на рисовой бумаге".
Приходится разделять эволюционирующие "артефакты" (которые никто не проектирует - они системами являются лишь для постфактум-исследований) и проектируемые "инженерные системы". Первые представляют интерес для инженера как некие сущности, которыми он ПОЛЬЗУЕТСЯ, и только. Он же может пользоваться сущностью "корова" при проектировании какой-нибудь фермы. Но сам корову не проектирует. И доступа к изменению интерфейсов коровы у него нет. И с создателем интерфейсов он тоже поговорить не может за отсутствием оного. Он ее берет AS IS. А если интерфейсы коровы начнут стремительно меняться - будет приноравливаться.
Reply
По многим вашим замечаниям я давал пояснения, только они в силу понятных причин не в одном месте курса собраны.
Если вы определяете границы системы, то вы что-то хотите с ней сделать. А хоть и что-то исследовать (необязательно полную практику системной инженерии применять). Кстати, один из способов изготовления системы -- это её покупка, а не самостоятельное изготовление. В системах систем вы вольны определять систему, как вам хочется в зависимости от ваших потребностей -- но не факт, что вы сможете использовать какой-то традиционный жизненный цикл для этой системы. То есть определить систему вы вольны, а вот изготовить/закупить нужный функционал у вас может и не получиться: полномочий не хватит. Жизнь сложна, и каждый раз она не будет укладываться в учебную схему, нужно будет думать головой.
Reply
IMHO необходимость привлекать сторонние системы (уже работающие, со своими хозяевами, которые до сих пор ни сном, ни духом...) является настолько распространенной, что без нее вообще с социотехническими системами - никуда. То есть, ситуация системы систем - по умолчанию присутствует чуть ли не в любом проекте. Работника в нужную роль поставить - ну чем не система систем?
А вот про нехватку полномочий - тут совсем непонятно. Если я в какой-то момент понимаю, что мне полномочий не хватает (а их поначалу редко когда хватает - они появляются по мере разговоров) и договориться со всеми стейкхолдерами я не могу (получив нужные мне полномочия от них) - это IMO повод честно заявить "эту систему я сделать не могу". Или придумать другую архитектуру, в которой мне полномочий хватит.
Покупка, кстати говоря - это тот самый вариант, когда полномочия честно покупаются.
Reply
Насчет покупки полномочий, так есть давнишний анекдот -- бабка купила булочку в булочной, и теперь требует чтобы на инвестированные ей деньги теперь платились ей дивиденды, можно даже булочками :-)
Reply
Есть хороший аппарат системной инженерии, так его и надо расширять, причем понятно даже где: выбор архитектуры (включение "независимых" систем в качестве подсистем) может повлечь расширение границ системы - через включение дополнительных стейкхолдеров.
Как в анекдоте про кипячение чайника. Если в чайнике нет воды, нужно ее налить и поставить чайник на огонь. Если вода уже есть, вылить ее и свести задачу к предыдущей :)
Reply
Leave a comment