Анатолий Левенчук - Системное мышление

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

Следующий уровень – это команды и прочие организационные звенья (в предприятиях – подразделения), получаемые из организованных (то есть с понятными полномочиями по использованию труда друг друга и других ресурсов) людей. Сервисы команд, сервисы подразделений, оказываемые ими на их интерфейсах, обсуждение интерфейсов-каналов для общения с ними являются типичным предметом обсуждения, сервисы пытаются стандартизовать. Предприятие буквально составлено, собрано, сделано из своих подразделений – это конструктивные, а не функциональные подразделения. Из обсуждения организационной диаграммы не скажешь, как работает предприятия, какие функции подразделений по отношению друг ко другу, и именование оргзвеньев это часто отражает. Цех №5, палата №6 – простые номера в именах, из которых не следует функций, являются типичными указателями на конструктивное рассмотрение. Функций, исполняемых конструктивными элементами предприятия, может быть множество, и самых неожиданных. С другой стороны, если «подразделение переезжает в другое здание», то это описание связи ипостасей конструктивной и размещения. «Подразделение будет выполнять новые виды деятельности» – это обсуждение связи функциональной и конструктивной ипостасей подразделения.

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

Вот компьютерная симуляция зависимости от числа попыток улучшений падения стоимости разработки при улучшении n отдельных модулей, при d связей каждого из них 130 130 http://www.pnas.org/content/108/22/9008.full :

Видно, что если связь одна, то стоимость разработки с каждым улучшением падает быстро по экспоненте, слабо зависящей от числа модулей. Но если связей больше, то снижение стоимости идёт плохо.

Каждая связь имеет свою цену, не было бы этой цены, мы не имели бы даже в живой природе «органов», «клеток» и других модулей 131 131 http://arxiv.org/abs/1207.2743 . Но модульность человеческого организма не идёт ни в какое сравнение с модульностью современного компьютера или смартфона, собираемого из стандартизованных деталей. Поэтому слабомодульный человеческий организм не очень понятно как улучшать или даже просто лечить, а компьютер или смартфон удаётся улучшать конструктивно и лечить-ремонтировать много проще.

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

Есть множество методов, которые помогают уменьшать связность модулей в создаваемой системе. Одним из наиболее известных таких методов является DSM (design/dependency structure matrix) 132 132 http://www.dsmweb.org/ .

Минимальная связность модулей нужна и в «железных» системах, и в программных системах, и в организационных, и даже в танцах. Это совсем не означает, что части системы/подсистемы не находятся в тесном взаимодействии друг с другом. Это означает, что эти взаимодействия ставятся под жёсткий контроль, и подсистемы можно улучшать, а в случае стандартизации интерфейса даже заменять на принципиально другие по конструкции и принципу действия, не рискуя при этом ухудшить работу всей системы в целом.

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

Edsger Dijkstra в 1974 году ввёл 133 133 http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html понятие разделения интересов (separation of concerns) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одному интересу за раз, удерживая внимание на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании одного аспекта проблемы и одновременно всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one – and multiple-track minded simultaneously».

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

Сложность обсуждения системы тем самым падает по двум направлениям:

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

• деление полного обсуждения каждого холона на обсуждение отдельных ипостасей этого холона как прозрачного ящика: принципов организации взаимодействия и структуры частей холона. Важнейшие из этих определений – это архитектура(architecture), а все остальные определения с точностью, достаточной для изготовления – это неархитектурная часть проекта(non-architectural part of design).