CC BY
23DOI: 10.24412/cl-37095-2023-1-204-215
Петров В.М., Азалецкий П.
Социоинформационные системы: противоречия и законы развития
Аннотация. Наша жизнь все больше зависит от цифровых продуктов. Мы доверяем системам автопилота в самолетах и автомобилях, врачи полагаются на цифровые системы в здравоохранении назначая лечение, деньги уступили место криптовалютам, и этот список можно продолжить. За каждым цифровым продуктом стоит организация со своей социальной структурой, культурой и ценностями. Понимание того, что информационная система не существует независимо от социальной системы создающий ее, помогает нам лучше понять принципы эволюции, системные противоречия и возможные пути совершенствования социо-информационных систем.
Эта статья исследует социально-информационные системы через призму теории решения изобретательских задач (ТРИЗ). Мы исследуем известные законы индустрии программного обеспечения, их пересечение с законами ТРИЗ и противоречия.
Ключевые слова: Социо-Информационная система, Противоречия, Законы развития систем.
ВВЕДЕНИЕ
Термин «социотехническая система» первоначально был введен Эмери и Тристом (Emery and Trist, 1960) в книге, описывающей проект, предпринятый Тавистокским институтом в британской (Tavistock Institute of Human Relations) угледобывающей промышленности. Они создали термин «социотехническая система» для описания систем, включающих сложное взаимодействие между людьми, машинами и окружающей средой. Это взаимодействие действительно для большинства корпоративных систем [1]. Эрик (Trist, Eric L) выделил три уровня социотехнических систем, хотя они взаимосвязаны [2] :
• Первичные рабочие системы - те системы, которые непосредственно выполняют набор действий в явно идентифицируемых и ограниченных рамках организации, такими как линейный отдел или сервисная единица;
• Организационная система целиком - это совокупность всех подсистем всей компании, производящих ценность;
• Макросоциальные системы - те совокупность систем, включающие системы социума, промышленности и государства, действующих на общем общества.
В этой статье мы сосредоточимся на уровне первичной рабочей системы; кроме того, мы посвятим наш анализ конкретному классу технологических систем - информационным системам и будем их рассматривать в совокупности с социальной системой создающий информационных продукт или сервис. С определенной долей уверенности, мы можем утверждать, что наши наблюдения могут быть применимы к более широкому спектру технологических систем.
Говоря о информационных системах, Леман (Lehman) выделил три типа программ с разными характеристиками: E-тип, P-тип и S-тип [3].
• Системы S-типа имеют формально определенные спецификации с четкими критериями корректного соответствия результатов реализации входным данным.
• Системы P-типа более сложны; они предназначены для решения задач с определенными правилами. Несмотря на то, что решаемая задача может быть сформулирована, успешность работы решения зависит от среды или контекста, в котором оно выполняется. Примером такой программы является алгоритм шахматной игры.
• Системы E-тип (электронного типа) - это системы реального мира, не имеющие четко вырожденных правил, фиксированной и четких спецификаций; мы говорим о программах, работающих в живых бизнес-организациях с участием людей. Принимая во внимание, что программы, как и бизнес, использующий их, постоянно подстраиваются к изменяющимся
условиям среды, корректность работы не может быть однозначно определена и постоянна. Примерами таких программ являются системы автоматизации бизнес-процессов.
В нашей статье мы сосредоточимся в первую очередь на информационных системах Е-типа, разработанных соответствующим социальной структурой первичной рабочей системы.
1. ОПРЕДЕЛЕНИЕ СОЦИО-ИНФОРМАЦИОННОИ СИСТЕМЫ
Давайте попробуем дать более точное определение социо-информационной системы. Для этого целесообразно, использовать систему Е-тип из классификации систем Леман (Lehman). Это системы, переплетенные с процессами реальной жизни, с бизнес-процессами, с реальными людьми, где спецификация не может быть на 100% корректной всегда. Поскольку требования к системе постоянно меняются, более того, потребитель не совсем уверен, что он именно он хочет иметь. Или даже если они уверены сегодня, завтра это может быть не так. Важно подчеркнуть, что это не обязательно происходит только из-за неопределенности. Это связано с тем, что потребители существуют в среде, которая может меняться, а по мере развития, меняются потребности и людей, и бизнеса. Поэтому спецификация и требования таких систем Е-типа нестабильны.
Рис. 1. Структура социо-информационной системы
Учитывая выше сказанное и тот факт, что информационные или цифровые продукты не могут автоматически реализовывать новые требования без участия людей, нам необходимо признать наличие дополнительных структурных элементов для обеспечения жизни подобных систем. Мы называем эти элементы «социальными», что определяет человеческую организацию, ответственную за адаптацию и реализацию новых функций и полоняющие цели системы. Без человеческой организации ни один информационный или цифровой продукт не может быть создан, а если создан, то не может быть заброшен после создания, поскольку он
не сможет быть адекватным меняющейся среде, что в конечном итоге нарушает закон выполнения цели системы.
Социальная система - это живая система; следовательно, ее структура состоит из людей и их взаимоотношений (сеть), что в совокупности определяет свойство социосистемы в целом, предназначенной для жизни в среде [4]. Социальная составляющая социотехнических систем хорошо известна, Бэкстер (Baxter) в своих работах выделил следующие ключевые характеристики социотехнической системы, где социальный компонент обозначен как подсистема, относящаяся к людям, работе и организации.
• Системы должны иметь взаимозависимые части.
• Системы должны адаптироваться и достигать целей во внешней среде.
• Системы имеют внутреннюю среду, состоящую из отдельных, но взаимозависимых технических и социальных подсистем.
• Системы имеют эквифинальность. Другими словами, системные цели могут быть достигнуты более чем одним способом. Это означает, что при разработке системы необходимо сделать выбор конструкции.
• Производительность системы зависит от совместной оптимизации технической и социальной подсистем. Сосредоточение внимания на одной из этих систем в ущерб другой может привести к снижению производительности и полезности системы [5].
Еще одним свидетельством, подтверждающим существование и важность социальной составляющий, является закон Конвея или гипотеза о зеркалировании, подтвержденная Аланом МакКормаком (Alan MacCormack) [6]. «Продукты имеют тенденцию «отражать» архитектуру организаций, в которых они разрабатываются. Эта динамика возникает из -за того, что структуры управления организации, процедуры решения проблем и модели коммуникации ограничивают пространство, в котором она ищет новые решения. Такая взаимосвязь важна, поскольку было показано, что архитектура продукта является важным фактором, определяющим производительности продукта». Следовательно, социальная и информационная архитектура продуктов переплетаются и должны рассматриваться как взаимосвязанные.
Социальный элемент следует рассматривать как систему, состоящую из элементов (людей), связей (социальной сети), потоков и системы управления. Следуя ТРИЗ - определению структуры системы [7], социальная система так же должна иметь следующие характеристики:
• Физические: распределение людей в пространстве, по физическим местоположениям и часовым поясам.
• Энергетические: деньги, мотивация, благополучие участников организации.
• Информационные: знания об архитектуре и структуре разрабатываемого информационного или цифрового продукта.
Эффективность всей нашей социально-информационной системы зависит от ее структуры и того, как организованы и скоординированы взаимодействия/потоки между структурными элементами в физической, энергетической и информационной сферах. Более того, социальная часть социально-информационной системы должна быть согласована с технической архитектурой, чтобы быть эффективной.
2. ЗАКОН ПОЛНОТЫ ЧАСТЕЙ СИСТЕМЫ
Социальная подсистема должна обладать компетенциями и знаниями для внесения необходимых технических изменений в информационный продукт; если человек или команда, отвечающая за работу того или иного компонента, исчез, то существование всей социально-информационной системы может быть поставлено под угрозу. В области исследований в области организационного управления мы обнаружили, что Юндт (Youndt) [8] ввел термин интеллектуальный капитал, который описывает понятие компетенции, которое подразумевалось в примере выше. Он определил интеллектуальный капитал как «сумму всех знаний, которые фирма используют для достижения конкурентного преимущества. Сумма всех знаний означает, что понятие интеллектуального капитала охватывает все активы, доступные ком-
пании. Существуют различные подразделения интеллектуального капитала на составляющие [8]. Клаас пошел дальше и выделил три типа интеллектуального капитала: человеческий капитал, социальный капитал и организационный капитал [9]. Человеческий капитал - это индивидуальные знания; социальный капитал - это социальная конструкция, которая обеспечивает инфраструктуру для взаимодействия/информационных потоков, и организационный капитал, относящийся к процессам и внешним связям с клиентами и партнерами.
С точки зрения ТРИЗ можно сказать, что в социальной подсистеме должны быть люди с их человеческим капиталом (знаниями и навыками); способ преобразования информации может быть отнесен к организационному капиталу (процессам), связи, являющиеся социальным капиталом, и система управления также могут быть отнесены к организационному капиталу.
Рис. 2. Структура системы
3. ЗАКОН МИНИМАЛЬНОГО СОГЛАСОВАНИЯ ЧАСТЕЙ И ПАРАМЕТРОВ СИСТЕМЫ
Поскольку системы состоят из множества элементов, в случае социо-информационной системы мы имеем социальную сеть и связанную с ней архитектуру информационной системы. Оба слоя имеют механизмы коммуникации и координации, которые переплетаются.
В соответствии с ТРИЗ, социальная подсистема должна обеспечивать информационную и энергетическую проводимость потоков для поддержания жизни системы. Генри Минцберг (Henry Mintzberg) предложил пять механизмов взаимодействия между элементами социальной сети организации для обеспечения координации: взаимная корректировка, прямой контроль, стандартизация процессов, стандартизация результатов и стандартизация навыков. По мере усложнения организационной работы излюбленные средства координации постоянно смещаются от взаимного приспособления к стандартизации навыков, но потом возвращаются обратно к взаимному приспособлению. В зависимости от типа бизнеса, будут расти различные части организации - операционное ядро, техно-структура, средний менеджмент, вспомогательный персонал и редко - стратегическое звено [10]. В случае социально-информационной системы операционное ядро, вспомогательный персонал и средний менеджмент представляют собой самые крупные структурные элементы систем. Подход к проектированию эффективного операционного ядра социально-информационной системы, предложенный Мануэлем Паисом и Мэтью Скелтоном (Manuel Pais, Matthew Skelton), определяет организационные конструкции, модели коммуникации и координации, которые зависят от когнитивной нагрузки человека [11].
Мы можем видеть, как механика координации развивается вместе с ростом организации. Конкурентная среда в технологическом бизнесе заставляет компании расти, чтобы адаптировать продукт к меняющейся среде; следовательно, количество компонентов информационной системы и количество людей растут, увеличивая социальные взаимодействия и когнитивную нагрузку до потолка эффективности, когда добавление большего количества людей не увеличивает производительность. Это кризисный момент, когда происходит организационная трансформация, поскольку система хочет выжить.
Следуя классификации механистической и органической организационной структуры, мы предложили упрощенное представление ниже [12]. В небольших организациях, приступающих к разработке информационной системы, мы можем наблюдать органические формы
с плоской и кросс-функциональной структурой, не нуждающиеся в дополнительных административных органах или поддержке. При росте числа компонентов информационной системы социоструктура изменяется удвоением, утроением, переходом к иерархической структуре, становясь более механистичной. Как только он достигает потолка эффективности, он снова превращается в гибкую, органичную структуру.
Рис. 3. Схематическая схема эволюции структуры организации 4. ЭВОЛЮЦИЯ СОЦИО-ИНФОРМАЦИОННЫХ СИСТЕМ
Давайте посмотрим на эволюцию архитектуры информационных систем и поместим ее в контекст социальной подсистемы, производящей цифровые/информационные продукты соответствующей архитектуры.
Общая закономерность, согласно которой развитие систем идет в направлении возрастания степени динамичности, применима и к социально-информационной системе.
Рис. 4. Переход от твердого к гибкому состоянию
Проводя параллель с архитектурой информационных систем, мы можем выделить тенденции от монолита к многослойности, микро-сервисам и бес-серверной архитектуре. У этой тенденции грануляризации системы есть один ключевой фактор - скорость, количество внедрений изменений в пределах временных рамок. Если цифровой продукт соответствует рынку, то компания, которая удовлетворяет потребности большинства пользователей самым быстрым способом без компромиссов в качестве, выигрывает рынок. Таким образом, мы можем сделать вывод, что архитектура информационной системы определяется давлением конкуренции в конкретной отрасли/области/области. Мишель Портер (Michel Porter) концептуализировал эти мысли в пяти факторах, определяющих стратегию организации, которая применима к социально-информационным системам как, к примеру любой организации, создающей ценность для своих потребителей [21].
Рис. 5. Эволюция архитектуры информационных систем
Как мы заметили ранее, архитектура продукта определяет структуру организации, производящую его; поэтому мы также должны увидеть отражение эволюции и в организационной архитектуре. Ниже мы схематически обрисовали типичную организационную структуру, поддерживающую различные архитектуры информационных систем.
Рис. 6. Организационные структуры поддерживающие разные архитектуры
информационных систем
Рассмотрим начало разработки продукта. Обычно разработку начинает небольшая команда, и часто архитектура тяготеет к шаблону монолита, когда все слои в той или иной степени связаны между собой. Если какая-либо часть системы изменится, вся система должна быть пересобрана и развернута целиком. Каждый в команде, знает каждый элемент информационной системы, чтобы внести изменения.
С успехом продукта растет спрос на его функции; следовательно, возрастает потребность в расширении инженерной команды для удовлетворения новых потребностей. В то же время плоская структура не обеспечивает эффективной координации и масштабирования. Декомпозиция команды и назначенное ответственных становятся неизбежными. Граница ответственности берет свое начало в архитектуре информационной системы. Частым является переход от монолитной системы к многоуровневой, такой как клиент-сервер, когда данные и бизнес-логика отделены от пользовательского интерфейса. Чтобы приспособиться к такой декомпозиции, социальная структура часто сводилась к функциональному разделению обязанностей, где у нас есть команды, ответственные за внедрение изменений на определенном уровне. Когда у нас есть несколько команд, вступает в действие уровень координации, чтобы убедиться, что изменения правильно интегрированы без дефектов.
Если успех продукта сохранится, спрос на функции возрастет еще больше; следовательно, количество инженеров растет, а, следовательно, снова возникает необходимость избегать конфликтов интеграции кода. Для решения этой задачи добавляется еще одно измерение и еще больше уменьшается размер элементов. Примером этого служит сервис-ориентированная архитектура. Социальная конструкция тоже получает дополнительное измерение, и переходит от функциональной как матричной. У нас архитектурные компоненты
(сервисы) включающие в себя слои и соответствующие команды, отвечающие за эти компоненты (команды могу быть функциональные внутри). Растущее количество компонентов быстро приводит к повторяющейся функциональности, реализованной по-разному той или иной командой, что не является эффективным вложением времени и замедляет скорость. Такой неблагоприятный эффект смягчается стандартизацией компонент, созданием платформ и выделением общих вспомогательных функций, решающие повседневные задачи и уменьшающими дублирование усилий. С одной стороны, это повышает производительность; однако требует больше времени, особенно для ввода нового человека в команду, так как требует изучения специализированных для этой организации стандартов. Важность подразделения интеграции компонент между собой становится очень важной, так как количество движущихся частей, которые необходимо согласовать, растет.
Если организация продолжает расти в описанной выше парадигме, то растущее число людей снова достигает точки насыщения производительности, за которой следует убывающая отдача. Часто узким местом является уровень координации и интеграции, а также дисбаланс распределения навыков между командами для создания ценности без времени ожидания друг друга. Для решения проблемы интеграции и зависимости в игру вступает архитектура микро-сервисов, в которой подчеркивается независимость доставки и развертывания каждого компонента. Чтобы обеспечить такую автономию, на первый план выходит инженерная платформа, автоматизирующая рутинную работу и обеспечивающими независимость разработки. Эволюционирует и социальная сеть: команда интеграции теряет свою востребованность, а разработка компонент управляется независимыми командами, где специализация уже не так важна, как раньше, устраняя дисбаланс навыков, а команда автоматизации наращивает свою мощь и влияние.
Организациям требуется сильная команда инженеров для создания такой платформы автоматизации, к сожалению, не все инженерные организации могут создать свою платформу. Невидимая рука рынка решает эту проблему, и мы видим растущее число облачных провайдеров, а также появление бес-серверной архитектуры, которая устраняет необходимость в создании платформы по автоматизации. Пока такая конфигурация не удовлетворит потребности в скорости доставки ценности, мы будем наблюдать продолжение тренда в облачной и бес-серверной архитектуре.
5. ОТОБРАЖЕНИЕ ЗАКЛНОВ ЭВОЛЮЦИИ ТРИЗ В ИНФОРМАЦИОННЫХ СИСТЕМАХ
Давайте рассмотрим соответствие между законами ТРИЗ и законами эволюции программных систем, чтобы исследовать пересечения и пробелы.
В ТРИЗ сформулированы шесть законов [13]:
• Изменение степени управляемости и динамичности
• Переход в надсистему или подсистему
• Переход системы на микро и макроуровень
• Согласование -рассогласование
• Свертывание -развертывание
• Сбалансированное -несбалансированное развития системы
Лехам сформулировал восемь законов [14]:
• Непрерывное изменение
• Увеличение сложности
• Саморегулирование
• Сохранение организационной стабильности
• Сохранение осведомлённости
• Непрерывное развитие [15]
• Ухудшение качества [15]
• Система обратной связи [15]
1. Изменение степени управляемости и динамичности
Такой закон описывает сочетание тенденций. Первый - усиление контроля над элементами наряду с ростом динамичности элементов. Такие тенденции отражают повышение эффективности управления петлями обратной связи в системе. Часто повышение управляемости сопровождается снижением участия человека в функционировании технических систем. Ниже вы можете найти схематическое изображение тенденции, отражающей улучшение управляемости.
Рис. 7. Переход от неуправляемой системы к управляемой
Ниже мы наметили тенденции увеличения динамики различных измерений, таких как время, пространство или состояние.
Рис. 8. Увеличение степени динамичности
Проводя параллель между ТРИЗ и законами эволюции программного обеспечения, мы наблюдаем принципиальное соответствие в роли обратной связи [16]. Процессы эволюции Е-типа представляют собой многоуровневые, многоконтурные, многоагентные системы обратной связи. Хотя тенденция управляемости и динамичности формально не артикулирована, мы можем наблюдать ее в жизненном цикле программного продукта; когда первая версия всегда ограничена и не обеспечивает достаточной гибкости, со временем программа становится более сложной, динамичной и настраиваемой. В некоторых случаях, как у Tesla, некоторые элементы программы становятся самообучающимися благодаря современным технологиям искусственного интеллекта.
2. Переход в надсистему или подсистему
Система объединяется с другой системой, создавая новую, более сложную систему [17]. В программном обеспечении мы можем это постоянно наблюдать так как обще принято пере использование компонент и систем, встраивание в уже готовые платформы и так далее.
Данные подход так же можно охарактеризовать законами возрастающей сложности и непрерывного роста.
Возрастающая сложность была сформулирована следующим образом: по мере развития системы E-типа, ее сложность возрастает, если не проводится работа по уменьшению сложности. Непрерывный рост был сформулирован: системы E-типа необходимо постоянно адаптировать, иначе они перестанут удовлетворять требованиям.
Оба закона имеют негативные последствия для скорости развития. Примером может служить цикломатическая сложность и ее влияние на производительность труда [18]. Цик-ломатическая сложность - это программная метрика, используемая для определения сложности программы. Это подсчет количества решений в исходном коде. Чем выше число, тем сложнее код. Учитывая растущую сложность и размер программы, этот показатель также увеличивается, что затрудняет внедрение новых изменений инженерами.
3. Переход системы на микро и макроуровень
Согласно ТРИЗ, системам свойственно уменьшать в размерах свои элементы; в то же время они часто увеличиваются в размерах, мощности, эффективности и других параметрах.
Глядя на эволюцию информационной архитектуры, мы видим ту же тенденцию. Компоненты становятся все более детализированными до тех пор, пока лямбда-функция не появится в облаке, где инженеру не нужно думать об инфраструктуре, он просто определяет функцию и развертывает ее у одного из облачных провайдеров. Учитывая тенденцию к уменьшению размеров компонентов информационных систем, мы наблюдаем тенденцию роста платформ для запуска таких небольших приложений на ряду с предоставляемыми функциями, масштабом, доступности и другими характеристикам.
4. Согласование - рассогласование
Согласно ТРИЗ, согласование и гармонизация внутренних элементов систем требуют минимизации негативных последствий и повышения эффективности системы. Закон Лемана (Lehman) об ухудшении качества предполагает, что внутренняя координация и гармонизация элементов - качество системы E-Type будет снижаться, если она не будет тщательно поддерживаться и адаптироваться к изменениям операционной среды. Поэтому, чтобы избежать деградации качества системы, инженеры прибегают к специальным практика поддержания чистоты кода и тестируемости.
Координация может происходить не только внутри системы, но и между системой и внешней средой. Это именно то, что мы испытываем в информационных системах. Согласно закону непрерывных изменений - система Е-типа должна постоянно адаптироваться, иначе она становится все менее удовлетворительной. Очевидно, что если спрос со стороны клиента не будет удовлетворен, то он будет искать другое решение.
Вот еще один аспект внутренней и внешней координации системы, характерный для информационных систем, известный как «закон сохранения фамильярности». Леман (Lehman) предполагает, что по мере развития системы E-типа все, кто с ней связан, например, разработчики, торговый персонал и пользователи, должны сохранять мастерство в ее содержании и поведении для достижения удовлетворительного развития. Чрезмерный рост функциональности системы уменьшает мастерство владения системой. Следовательно, средний прирост остается неизменным по мере развития системы чтобы поддерживать эффективность использования и, следовательно, удовлетворять потребность.
Законы непрерывного изменения и сохранения осведомлённости - это законы, влияющие на качественные характеристики информационной системы. Они существуют вне информационной системы так как связаны с людьми и социальной сферой. Поэтому, если мы
создаем информационную систему, чтобы сделать ее эффективной, недостаточно учитывать только архитектурные характеристики информационной системы; важно спроектировать социальную конструкцию, обеспечивающую, поддерживающую и развивающую информационную систему. Мы предполагаем, что это замечание будет актуально и для других технических систем; поэтому мы считаем это новым элементом системы ТРИЗ.
Учитывая определение социально-информационной системы и эмпирическое подтверждение закона Конвея, считаем целесообразным рассмотреть расширение аппарата ТРИЗ с введением социальной подсистемы как минимум для информационных систем.
5. Свертывание - развертывание
Закон свертывания и развертывания таков, что любая система в процессе своего развития уменьшает или увеличивает свои функции и компоненты.
Аналогичным законом в программном обеспечении является закон непрерывного роста, который мы упоминали при переходе к суперсистеме, он также применим и здесь, поскольку отражает представление о том, что система, если она не развивается должным образом, теряет свою ценность для пользователей и устаревает. Мы можем видеть множество таких случаев в программном обеспечении. Sun Microsystems больше не существует, Yahoo потеряла рынок интернет-поиска, Microsoft закрыла свой мобильный отдел, и этот список можно продолжить.
6. Сбалансированное - несбалансированное развития системы
Развитие элементов системы неравномерно, и чем сложнее система, тем менее сбалансировано развитие, предполагает ТРИЗ. Третий и четвертый законы эволюции программных систем E-типа согласуется с балансированным развитием систем и предполагают, что существует внутренняя системная динамика социально-информационных систем, которая обеспечивает сбалансированный путь эволюции системы. Саморегулирование. Закон саморегулирования гласит, что процессы эволюции систем Е-типа являются саморегулирующимися с распределением показателей развития продукта, близким к нормальному; и Сохранение организационной стабильности говорит, что средняя эффективная скорость разработки в развивающейся системе Е-типа не меняется в течение всего срока службы продукта. Можно утверждать, что эти законы отражают динамику роста информационных систем. Когда ставки успеха и неудачи повышаются, социальная система стремится свести к минимуму большие разрушительные изменения, которые могут привести к нестабильности информационной системы. Таким образом, вместе с ростом числа инженеров снижается производительность отдельных инженеров, поэтому общая скорость изменений, как правило, не зависит от количества людей и определяется архитектурой информационной системы. Однако изменение как информационной архитектуры, так и архитектуры социальной системы может привести к изменению производительности.
6. ПРОТИВОРЕЧИЯ
Как мы видели выше, социальные и технические системы дополняют друг друга, и одна не может существовать без другой. Информационная архитектура может быть блестящей, но ее реализация будет зависеть от социальной структуры, которая зависит от способности людей выполнять работу. Невозможно бесконечно увеличивать количество людей, не меняя организационную структуру, так как они должны взаимодействовать друг с другом. А изменения организационной структуры приводят в изменение архитектуры информационной системы. Невозможность линейного увеличения организационной структуры ограничено несколькими факторами: количеством социальных связей, с которыми может справиться один человек, известным как число Данбара (Dunbar) [19], и ограничениями когнитивной нагрузки [20], которые ограничивают способность выполнять умственную работу, которая является ядром разработки информационных систем. Без таких ограничений любая организация, разрабатывающая информационную систему, даже тесно связанный монолит, могла бы бесконечно масштабироваться.
7. НАПРАВЛЕНИЯ ПОСЛЕДУЮЩИХ ИССЛЕДОВАНИЙ
Целесообразно изучение социо-информационных систем за пределами первичных рабочих систем, а именно на организационном и макросоциальном уровнях. Такое исследование может выявить законы, тенденции и последствия для нас, которые авторитетные организации и технологические предприниматели могут принять во внимание, чтобы усилить положительные эффекты и смягчить неблагоприятные последствия тех или иных решений.
Еще одним направлением для дальнейших исследований является проверка гипотезы о том, закон Конвея действителен в более широкой категории технологических систем. Его подтверждение будет способствовать обобщению необходимости ввода элемента социо в состав структуры систем по ТРИЗ.
Мы также рассматриваем тестирование гипотезы о том, что только сбалансированные изменения в информационной и социальной системах могут положительно повлиять на производительность социо-информационной системы. В то время как независимые изменения в информационной системе и/или социальной системе, скорее всего, приводят к отрицательному тренду производительности и качества.
8. ЗАКЛЮЧЕНИЕ
Такое исследование выявило важность социального аспекта для анализа и проектирования информационных систем, а также для ее разработки. Это является актуальным так как растет зависимость человечества от информационных систем; следовательно, мы должны найти способ должным образом сбалансировать и гармонизировать социальные и информационные системы вместе, сводя к минимуму негативные эффекты. Ухудшение качества, растущая сложность, сохранение знакомства и последствия для состава команды - эти проблемы, связанные с человеческим аспектом, и без надлежащего решения могут привести к необратимой ситуации с критически важными системами, в здравоохранении, в производстве, в авиации, и во многих других индустриях. Мы также показали применимость законов эволюции систем по ТРИЗ, для социо-информационных систем.
Несмотря на то, что сочетание социальных систем и технологических систем является областью с прочной исследовательской базой, мы считаем, что существует большой потенциал для дальнейших исследований сочетания социальных и информационных систем на всех уровнях производства, как организационном, так и макросоциальном. Авторы намерены продолжить исследования в указанном направлении.
ЛИТЕРАТУРА
1. Gordon Baxter, Ian Sommerville Socio-technical systems: From design methods to systems engineering
2. Trist, Eric L. The evolution of socio-technical systems. Vol. 2. Toronto: Ontario Quality of Working Life Centre, 1981
3. Lehman, Meir M. «Programs, life cycles, and laws of software evolution.» Proceedings of the IEEE 68.9 (1980): 1060-1076.
4. Maturana, Humberto R. «The organization of the living: A theory of the living organization.» International journal of man-machine studies 7.3 (1975): 313-332.
5. Baxter, Gordon, and Ian Sommerville. «Socio-technical systems: From design methods to systems engineering.» Interacting with computers 23.1 (2011): 4-17.
6. MacCormack, Alan, Carliss Baldwin, and John Rusnak. «Exploring the duality between product and organizational architectures: A test of the "mirroring" hypothesis.» Research Policy 41.8 (2012): 13091324.
7. Petrov, Vladimir. TRIZ. Theory of inventive problem solving. Springer International Publishing, 2019.
8. Youndt, Mark A., Mohan Subramaniam, and Scott A. Snell. «Intellectual capital profiles: An examination of investments and returns.» Journal of Management studies 41.2 (2004): 335-361.
9. Wohlin, Claes, Darja Smite, and Nils Brede Moe. «A general theory of software engineering: Balancing human, social and organizational capitals.» Journal of Systems and Software 109 (2015): 229-242.
10. Mintzberg, Henry. Structure in fives: Designing effective organizations. Prentice-Hall, Inc, 1993.
11. Skelton, Matthew, and Manuel Pais. Team topologies: organizing business and technology teams for fast flow. It Revolution, 2019.
12. Burns, Tom, and George M. Stalker. «Mechanistic and organic systems.» Classics of organizational theory (1961): 209-214.
13. Petrov, Vladimir. TRIZ. Theory of inventive problem solving. Springer International Publishing, 2019.
14. Lehman, Meir M. «Programs, life cycles, and laws of software evolution.» Proceedings of the IEEE 68.9 (1980): 1060-1076.
15. Lehman, Manny M. «Laws of software evolution revisited.» European Workshop on Software Process Technology. Springer, Berlin, Heidelberg, 1996.
16. Lehman, Meir M. «Feedback in the software evolution process.» Information and Software technology 38.11 (1996): 681-686.
17. Souchkov, Valeri. «THE LAW OF SUPERSYSTEM COMPLETENESS.» TRIZfest-2017 (2017): 399.
18. Gill, Geoffrey K., and Chris F. Kemerer. «Cyclomatic complexity density and software maintenance productivity.» IEEE transactions on software engineering 17.12 (1991): 1284-1288.
19. Dunbar, Robin IM. «Neocortex size as a constraint on group size in primates.» Journal of human evolution 22.6 (1992): 469-493.
20. Sweller, John. «Cognitive load during problem solving: Effects on learning.» Cognitive science 12.2 (1988): 257-285.Porter, Michael E. «The five competitive forces that shape strategy.» Harvard business review 86.1 (2008): 25-40.
