Постоянные компромиссы ведут к революции или еще про поддержание сложности

 Уже писал про поддержание сложности по совсем другому поводу

Когда мы говорим о развитии систем, неизбежно это связывается с понятиями системной сложности. Сложность системы характеризуется количеством элементов в системе, взаимосвязей между ними и разнообразием видов элементов.

Развитие системы протекает через ряд возникающих противоречий и их разрешение.

Как правило, такое разрешение происходит путём компромисса. («Демократия – путь компромиссов»)

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

Снижение адаптивности, эффективности и накопление противоречий вытесняет систему из стабильного режима развития работы в к точкам бифуркаций.  Когда при бифуркации рвутся связи, то система обретает дополнительные степени свободы, что позволяет по-новому (и не факт, что наилучшим образом) разрешить внутрисистемные противоречия.

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

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

Следовательно, чтобы избежать бифуркационного пути развития системы, очевидно, нужно:

  1. прогнозировать и постоянно мониторить внутрисистемные напряжения,
  2. при появлении признаков усиления напряжений на каких- то взаимосвязях -
  3. проводить изменение архитектуры системы

Для определения участков напряжения в системе должны подойти методики из  Theory of Constraints by Eliyahu Goldratt. http://en.wikipedia.org/wiki/Theory_of_Constraints

Для изменения архитектуры системы представляется подходящим аппарат ТРИЗ, однако готовых методик реинжиниринга  я там  не нашёл…

Внимание, вопрос: как произвести изменение архитектуры системы максимально безболезненно, или, что более математично – с минимальной потерей связности по   времени и объёму?  Ответ...