Многерица: единонемыслие единого

 

Суть системного подхода в том, чтобы ни в один момент времени не забывать про систему в целом – воплощение системы, которое просто по-разному представляется состоящим из разных частей разными стейкхолдерами. Это очень трудно.

В христианстве есть довольно сложно осваиваемое в мышлении понятие троицы: бог представляется одновременно и единым, и существующим в трёх ипостасях (отца, сына и святого духа).

Проблема в том, что думать о боге нужно одновременно и о как едином, и как об отдельных ипостасях – такому мышлению несколько лет обучают в семинариях. Сама идея-то понимается очень легко, но не так легко эта идея осваивается в практике мышления, метанойя происходит медленно:

 

 

То же самое есть и во многих других религиях, хотя там необязательно троица. В буддизме и индуизме иногда говорят и об аспектах (и не путайте использование этого термина тут с использованием этого термина для группировки стейкхолдерских интересов). В даосизме единое (дао) одновременно представляется как двоица (противоположности инь и янь, ипостаси дао). Впрочем, некоторые и тут видят троицу:

 

 

Беглости подобного мышления «единого-ипостасного» тоже довольно долго учат, хотя идея понимается с первого предъявления.

Все религии как-то учитывают возможность различных обликов/аспектов/ипостасей для какой-то божественной сущности – и тут нужно добавить, что религиозность и божественность тут не при чём, просто речь идёт о достаточно продвинутом мышлении. В абсолютно светском системном подходе кроме метанойи холархичности («каждое целое – это часть, каждая часть – целое») вам потребуется метанойя междисциплинарности: о какой-то системе одновременно думать как о чём-то, совмещающем разные свои ипостаси, так и как об отдельных ипостасях – в том числе при той трудности, что ипостаси этой системы нередко имеют ещё и разные имена, обозначающие систему-как-ипостась (хотя одинаковые имена для разных ипостасей встречаются даже чаще, что вносит огромную путаницу).

По сравнению с религиями трудность в том, что речь идёт не о трёх ипостасях/аспектах, не о троице, а о множестве ипостасей системы – о многерице.

Компоненты, модули, места (они же – функциональные элементы, конструктивные элементы, размещения) не единственный способ увидеть в системе части. Этих способов огромное количество. Разные стейкхолдеры по-своему выделяют части в системе, по-своему называют систему, по-своему употребляют систему. Тем не менее, какие-то общие типы основных ипостасей системы существуют, хотя и по-разному определяются в разных школах мысли:

• ISO 15926 – две основных: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.

• IEC 81346 – «по меньшей мере» три (функция, продукт, место)

• Книга Paul Clements at al., Documenting Software Architectures: Views and Beyond (2nd edition), Addison-Wesley Professional, 2010[117] – три стиля (компоненты, модули, размещения, и разные варианты внутри каждого стиля). Авторы этой книги тесно связаны с разработчиками ISO 42010, поэтому мы ориентируемся в нашем учебнике именно на эти названия – «компоненты, модули, места/размещения».

• Книга Косяков, Свит, Сеймур: «Системная инженерия. Принципы и практика»[118] – функциональный элемент, компонента (в значении «модуль» из предыдущей книги: ровно обратное использование термина!), размещение.

• СМД-методология – «по меньшей мере» пять (процессы, элементы и связи, внешние функции, морфология, материал)[119]

• … и так далее, в среднем 3—7 основных ипостасей (впрочем, «ипостаси» тоже называются везде по-разному) в разных школах системного мышления.

В нашем курсе мы примем, что системы имеют минимально три ипостаси/аспекта – компонент, модулей и размещений. И запомним, что этих ипостасей/аспектов всегда больше, плюс сами эти ипостаси/аспектов в чистом виде не встречаются и обычно тесно сплетены друг с другом («гибридны»).

Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях мышления отдельных дисциплин совершенно по-разному – но при этом в системном мышлении она будет оставаться целостной/холистичной/целокупностью всех своих ипостасей/аспектов.

 

Многерица холархий

 

Системные холархии для разных стейкхолдеров оказываются тоже разными, ибо «система в глазах смотрящего»: каждая холархия удобна для ответа на вопросы какой-то одной деятельности, а не всех сразу.

 

 

Целевая система отличается тем, что для неё компонента, модуль и место совпадают, это одно и тот же экстент в пространстве.

Но если начинать одновременно разбираться с тем, как целевая система работает (компоненты), из чего её сделать (модули), как она скомпонована (размещения), то окажется, что иногда компоненты, модули, места в ней полностью совпадают (если они образуют подсистемы – подсистемы ведь тоже системы), но иногда такого совпадения не будет.

ТРИЗ задачу своих изобретений видит в том, чтобы несколько разных функций выполнялись небольшим числом конструктивных элементов – в идеальной системе много функций выполняются нулевым числом элементов, нужно стремиться к этому. Так что гарантировать, что холархии функциональных элементов, конструктивных элементов, размещений совпадают нельзя.

Нельзя путать компоненты и модули. Нельзя путать Принца Гамлета и Василия Пупкина, даже если во время спектакля это одно и то же. Если вы будете за кулисами говорить Василию Пупкину «Ваше Высочество», а на сцене говорить Принцу Гамлету «как там твои жена и дети?», то окружающие на вас будут смотреть странно, а Василий Пупкин сильно озадачится.

Для ножниц инженеры придумывают разные формы ручки и ножевого блока, думая о ручке и ножевом блоке как компонентах. Они обсуждают ручки и ножевой блок как физически существующие (за ручку держат, считаются её размеры и гладкость, ножевым блоком режут – считаются его прочность и острота, угол раскрытия).

Если менеджеры будут воспринимать ножницы состоящими из компонент, то они попытаются заказать работы по изготовлению ручек и ножевого блока раздельно: ручки фирме, понимающей в эргономике, а режущий блок заводу, который умеет делать ножи («ножницы» как раз происходят от слова «нож»!).

Инженеры от этого в шоке, поскольку они для целей изготовления и сборки начинают думать про ножницы как состоящие из модулей: двух цельных кусков металла специальной формы, скреплённых винтиком.

Заказать можно только модули, а ручка и ножевой блок у ножниц компоненты, а не модули. Модулями в ножницах будут только две половинки ножниц (а ещё винтик).

Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение.

 

 

Менеджеры же сначала внимают доводам инженеров, но потом… смотрят на ножницы в сборе, видят в действии (эксплуатации, operations) ручку и ножевой блок – и опять пытаются с ними сделать что-то по отдельности не в момент «спектакля» (когда ножницы в сборе и работают – режут), а в момент изготовления. Например, разделить работы по сборке ручки и ножевого блока, хотя при соединении половинок ножниц винтиком разделить работы по ручке и ножевому блоку принципиально невозможно. Или сделать каталог ручек и каталог ножевых блоков и потом пытаться заставить инженеров выпускать эти якобы «детали ножниц» в виде запчастей. Список ошибок и заблуждений тут бесконечен, и эти ошибки не прекратятся: менеджеры постоянно находят «ножевой блок» и «ручки» в инженерной документации и пытаются поступать с ними как со сборочными единицами.

Правда в том, что в ножницах разные стейкхолдеры усматривают две разные холархии: одна функциональной декомпозиции («аналитическая»), а вторая модульной сборки («синтетическая»):

 

 

Целевая система едина как компонента и модуль, но вот дальше структура компонент (функциональная структура, системное разбиение) и модулей (модульная структура, конструктивное разбиение) могут существенно различаться.

В инженерных языках моделирования «железной» архитектуры, равно как и в языках моделирования предприятия, компоненты и модули имеют различные значки.

Если не понимать между ними разницу, то использование этих языков становится ошибочным. Если в проектном управлении сделать графики реализации модулей и реализации компонент – то они будут абсолютно различными, но оба могут иметь смысл!

Главное при этом – это решения создателей системы, какие элементы конструкции реализуют какие необходимые для работы системы поведения/функции, так что требуются обычно описывать и компоненты, и модули.