ИТ-ландшафт как сложная система систем
Увеличение интереса к цифровизации бизнеса сегодня затрагивает практически весь спектр организаций — от стартапов до крупных корпораций, причем в самых разных сферах деятельности. Последние годы инновационные цифровые продукты кардинально изменили способы предоставления ценности потребителям и повысили скорость реакции на изменения рынка, что заставляет крупные предприятия менять свое отношение к инвестициям в ИТ, воспринимая его уже не просто как центр затрат, а как один из ключевых активов, приносящих прибыль. Однако желание корпораций, с их унаследованными за годы существования ИТ ландшафтами, участвовать в цифровой гонке наряду со стартапами нередко приводит к еще большему увеличению сложности всей ИТ инфраструктуры, что в свою очередь влечет неоправданный рост стоимости владения ИТ активами, риски нарушения безопасности и непрерывности бизнеса, а также увеличение Time-To-Market при выпуске новых продуктов.
Что такое ИТ ландшафт с точки зрения системного подхода? Что такое сложность, как она проявляется и измеряется в ИТ ландшафте?
Что ж, давайте разбираться.
Системное мышление
Системное мышление — подход, позволяющий управлять вниманием и рассуждениями в процессе анализа, проектирования и воплощения сложных объектов.
Для начала необходимо вспомнить что система — это некое целое, состоящее из частей, за счет взаимодействия которых оно проявляет свои свойства (т.н. эмерджентность) во внешней среде. Согласно системному мышлению, системы рекурсивны — каждая часть системы в свою очередь так же является системой (т.е. подсистемой по отношению к системе), а сама система входит в некую надсистему, и так далее вверх и вниз по всем системным уровням.
Для кибер-физических (инженерных) систем различают 3 вида взаимодействия системы с окружающими ее системами — вещество, энергия и информация. Очевидно, что для ИТ ландшафта как системы, состоящей из приложений, именно информационное взаимодействие между ними является основным.
Поскольку мы имеем дело не с биологическими, а кибер-физическими системами, то они, в отличие от живых организмов, не создают себя сами, для этого требуется специальная сторонняя система, управляющая жизненным циклом системы нашего интереса, — т.н. система-создатель (enabling system). Часто можно наблюдать довольно длинные цепочки систем-создателей.
Под целевой обычно понимают систему, которая имеет ценность для конечного потребителя (и который нам за нее заплатит), т.е. некий конечный продукт (товар или услуга) деятельности предприятия как системы-создателя.
Еще одно важное для нас определение системы систем (system of system, SoS) — «набор или упорядоченная совокупность систем, возникающая в результате комплексирования независимых и пригодных к работе систем в более крупную систему, обладающую новыми возможностями».
Ключевыми свойствами системы систем, отличающих ее от обычных систем (Maier, 1998), являются:
независимые системы создания/enabling ее подсистем (у ответственного за SoS нет полномочий предписать общее развитие-модернизацию для входящих в SoS систем).
подсистемы, которые могут работать независимо от существования целевой системы (нет полномочий по указанию владельцам систем, как им работать).
эмерджентность от объединения в систему (кто-то желает получить от целевой системы систем функцию/поведение, которое невозможно получить от работы с входящими в систему систем отдельными системами, и требуется совместная работа этих входящих независимых систем).
эволюционное развитие (понимание того, что будет происходить в системе систем на каждом следующем шаге программы создания системы, требует исследований и дополнительных согласований, ибо нет роли, которая знает, как в каждый момент устроена система систем — подсистемы системы систем как автономные системы меняются независимо. Поэтому идет череда модернизаций, а не разовое спроектированное проектное действие, т.е. создание типичной SoS никогда нельзя считать полностью завершенным.
географическое распределение входящих в SoS систем.
В ISO 21839:2019 выделено четыре типа SoS, отличающихся степенью связанности составляющих их систем — от сильно связанных до полностью автономных:
Управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы командам проектов составляющих систем и менеджер, который распоряжается общими ресурсами.
Подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать владельцев составляющих SoS систем изменить свои системы согласно разработанной им архитектуре (то есть у архитектора нет отношения надзора/governance, только менторинг по поводу принимаемых им архитектурных решений).
Коллаборативные (collaborative), в которых владельцы всех систем договариваются друг с другом по каждому вопросу, но нет архитектора, менеджера проекта или аналогичных выделенных оргзвеньев, занятых созданием и развитием SoS на уровне целой системы.
Виртуальные (virtual), в которых владельцы систем, входящих в SoS вообще не знают друг о друге ничего, и они тем самым не влияют друг на друга явно.
Система систем
Современные крупные компании (анг. «enterprise») обладают, как правило, очень сложной многоуровневой ИТ инфраструктурой, сформировавшейся за десятилетия непрерывного развития. Сотни и даже тысячи приложений, баз данных, серверов, хранилищ, сетевых устройств и каналов, находящихся как в собственных ЦОД, так и в «облаке», — все это объединяется десятками тысяч взаимосвязей в систему, которую обычно называют ИТ ландшафтом предприятия.
Однако в целях упрощения под ИТ ландшафтом мы будем понимать только совокупность всех приложений (ПО и данных) и их интеграций, поскольку именно они, как правило, находятся в фокусе внимания, когда речь идет о сложности ландшафта.
Итак, мы имеем в фокусе внимания «нашу» систему под названием «ИТ ландшафт». Первое, что необходимо сделать для рассмотрения этой системы, — это разобраться с ее надсистемой, системой-создателем, а главное с тем, что для нас является целевой системой.
Предположим, что наше предприятие — розничный банк, предоставляющий физлицам продукты кредитования и сбережения накоплений. В этом случае целевыми системами для нас будут собственно результаты оказания соответствующих услуг — выданные заемщику кредитные средства и хранение полученных от клиента средств на счете в безналичной форме.
Сам банк по отношению к этим целевым системам будет являться системой-создателем.
Разобравшись с надсистемой, пришло время заглянуть внутрь системы нашего предприятия и выяснить, что какие именно его части реализуют требуемую клиентам эмерджентность в рамках целевых систем.
В составе системы-банка должны присутствовать подсистемы-провайдеры для соответствующих продуктов, а также их системы-создатели, роль которых играют соответствующие бизнес-подразделения (оргзвенья). Отделы придумывают концепцию использования сервисов, предоставляемых своими продуктами клиентам, создают описание концепции самих продуктов (из каких функциональных компонентов они состоят, как эти функции взаимодействуют, какие роли участвуют в процессах, какие практики выполнения работ этими ролями применяются, какие документы порождаются и т.д.).
Каких-нибудь 100 лет тому назад на этом можно было бы остановиться, поскольку все указанные функции по обработке информации в рамках продукта выполнялись исключительно людьми с использованием подсобных инструментов (канцтоваров), не требуя никаких дополнительных сервисов. При этом системы-провайдеры продуктов не зависели друг от друга.
С появлением компьютеров картина существенно изменилась. Практически все функции стали реализовываться сервисами, предоставляемыми ИТ системами (приложениями), и придаными им сотрудниками фронт- и бэк-офиса. В результате чего и возникла «наша» система — ИТ ландшафт, а также ее система-создатель — оргзвено «Отдел ИТ», положив начало разделению организации на «Бизнес» и «ИТ».
Поначалу все выглядело относительно просто. В ИТ ландшафте присутствовала одна основная система, которая как конструктивный элемент воплощала практически все требуемые функции для систем-провайдеров бизнеса (что является идеальным с точки системной инженерии) и при этом практически не взаимодействовала с другими системами. В случае банка таковой являлась Автоматизированная Банковская Система (АБС).
Частота появления новых продуктов (а значит и новых систем-провайдеров для них) и изменения существующих была крайне невысокой, с чем небольшой отдел ИТ вполне справлялся путем изменения настроек коробочной системы, тем более что архитектура ее, как правило, была модульная, что позволяло докупать необходимые стандартные модули по мере развития бизнеса и появления потребности в новых продуктах. При этом общий уровень развития и проникновения информационных технологий в клиентуре и партнерской среде был относительно низким, что не требовало предоставления каких-либо сервисов предприятия посредством цифровых каналов. Стоит, однако, отметить, что у систем-провайдеров продуктов теперь появилась общая зависимость от одной системы-создателя — АБС, что привносит риски для непрерывности бизнеса.
Однако последующее взрывное развитие информационных технологий с одновременным расширением их доступности привели к кратному ускорению изменений продуктовой линейки и появлению принципиально новых каналов ее доставки клиентам. Началась эпоха цифровизации, при которой продукты и сервисы либо предоставляются клиенту полностью в цифровом виде (цифровые медиа, онлайн банкинг), либо физические продукты и сервисы могут быть получены клиентом с использованием цифровых сервисов (например, онлайн каршеринг). Номенклатура доступных на рынке коробочных ИТ систем и технологий существенно расширилась. Естественно, что все эти изменения не могли не сказаться на структуре ИТ ландшафта. Началась атомизация ИТ ландшафта, где наряду с АБС как основным операционным и учетным модулем, появилось множество дополнительных приложений для реализации отдельных функций в продуктовых надсистемах бизнеса, что позволило в определенной степени повысить качество сервисов, а также увеличить скорость их изменения. Однако при этом заметно возросла и сложность самого ИТ ландшафта, поскольку приложения имели независимый жизненный цикл и, как правило, развивались автономными оргзвеньями (как системами-создателями). Кроме того, системы должны были обмениваться данными в рамках интеграционных ИТ решений по поддержке функциональности продуктовых систем-провайдеров, причем как в режиме онлайн, так и в пакетном оффлайн режиме, что приводило к усложнению интеграционной инфраструктуры.
Таким образом, стали выделяться 3 системных уровня:
Уровень собственно ИТ ландшафта (Enterprise Architecture) — совокупность всех приложений предприятия (иногда включая приложения его партнеров и клиентов) и их интеграций.
Уровень ИТ решения (Solution Architecture) — подмножество приложений ИТ ландшафта, взаимодействующих друг с другом для реализации некоего целевого поведения (процесса) в конкретной надсистеме бизнеса.
Уровень приложения (Software/System Architecture) — отдельное приложение, предоставляющее свое поведение в рамках ИТ решения посредством программных (API) и пользовательских (UI) интерфейсов.
Дополнительным фактором увеличения сложности стало использование одних и тех же приложений в качестве конструктивных модулей в большом количестве все новых и новых ИТ решений как enabling систем для систем-провайдеров продуктов, что стало приводить к конфликтам как между надсистемами-провайдерами продуктов (одному продукту нужен атрибут в сущности БД, а другому такой атрибут будет мешать), так и конфликтам между системными уровнями ИТ решения и приложения как его подсистемы (для ИТ решения требуется выполнение определенной функции приложением, а система-создатель приложения считает эту функцию для него нецелевой). Неудивительно, что данные конфликты с уровня ИТ ландшафта эскалировались по цепочке наверх, приводя к конфликтам между конечными системами-создателями — оргзвеньями бизнеса и ИТ. Разрешались же эти конфликты, как правило, либо путем внедрения новых приложений с дублированием функционала уже существующих, либо «запихивания» нецелевого функционала и данных в существующие приложения, что приводило к еще большему усложнению ИТ ландшафта.
Отдельно стоит отметить такой фактор сложности ИТ ландшафта как многочисленные слияния и поглощения, в результате которых в объединенном предприятии появлялись дублирующие друг друга системы-создатели продуктов и поддерживающие их ИТ приложения.
Очередной этап увеличения сложности связан с внедрением Agile-подходов к созданию систем-провайдеров продуктов. С точки зрения системного подхода Agile — это наделение систем-создателей в бизнесе (продуктовых бизнес-подразделений) ресурсами и полномочиями не только разрабатывать концепцию использования системы-провайдера продукта и ее функциональное описание (как это было в классической «водопадной» модели взаимодействия бизнеса и ИТ), но и самостоятельно синтезировать ее модульную структуру, а также разрабатывать сами модули-приложения (как правило, в микросервисной архитектуре), причем делать все это итеративно с быстрым получением обратной связи от внешних проектных ролей (клиентов). Такой подход привел к улучшению коммуникации бизнеса и ИТ при создании продуктов, повышению автономности продуктов, а также к появлению двухуровневой топологии ИТ ландшафта и его систем-создателей, описываемую Gartner как «двухрежимное» ИТ (Bimodal IT):
Режим 1 «Традиционное ИТ» — традиционный и последовательный, нацеленный на безопасность и надежность. Оптимизирован для более предсказуемых и понятных областей. Он фокусируется на использовании того, что известно, при обновлении устаревшей среды до состояния, пригодного для цифрового мира. В основном поддерживается монолитными приложениями, развиваемыми соответствующими отделами ИТ в рамках общекорпоративного релизного цикла.
Режим 2 «Быстрое ИТ»— исследовательский и нелинейный, обеспечивающий продуктовую гибкость и скорость Time-to-market, экспериментирующий для решения новых проблем и оптимизированный для областей неопределенности. В основном приложения в микросервисной архитектуре, развиваемые кроссфункциональными Agile-командами.
С точки зрения структуры ландшафта «Традиционное ИТ» вследствие межуровневых конфликтов со временем обретает черты «платформенности» — монолитные core-приложения предоставляют микросервисным приложениям «Быстрого ИТ» свое поведение посредством слоя стандартизованных программных интерфейсов (API). В «Быстром ИТ» так же формируется платформа, в которую выносятся общие для всех приложений инфраструктурные и бизнес-сервисы (аутентификация, журналирование, генерация и распознавание документов и др.)
К сожалению, вследствие такой «переплетенности» бизнеса и ИТ, обсуждение новых бизнес-инициатив зачастую происходит сразу на основе конструктивных/модульных описаний в терминах ИТ решения (приложений и их интеграции), минуя функциональное разбиение системы-провайдера продукта. Конструирование системы без четкого понимания целевого процесса ее функционирования приводит к большому количеству субоптимальных архитектурных решений.
Очевидно, что при всех преимуществах Agile, в отсутствие соответствующего надзора (governance), увеличение количества систем-создателей приложений, которые еще и создаются/изменяются в разном ритме, приводит к дальнейшему усложнению и даже некоторой хаотизации системы ИТ ландшафта.
Возвращаясь к понятиям системного подхода, можно с уверенностью утверждать, что ИТ ландшафт обладает всеми признаками системы систем (SoS) по критериям Maier:
Приложения, являющееся подсистемами ИТ ландшафта, создаются независимыми системами-создателями (Agile-командами и отделами ИТ).
Приложения, особенно если речь идет о «коробках», могут функционировать самостоятельно вне контекста надсистемы ИТ ландшафта конкретного предприятия.
Взаимодействующие в рамках ИТ решения приложения проявляют свою эмерджентность в виде предоставляемых сервисов для систем-провайдеров продуктов.
Развитие ИТ ландшафта идет непрерывно путем реализации ИТ решений для бизнеса, либо проектов ИТ модернизации, направленных на снижение архитектурного долга.
ИТ ландшафт современного предприятия, как правило, является геораспределенным с целью обеспечения его катастрофоустойчивости, а также как следствие активного использования «облачных» сервисов.
Согласно Косякову, со временем к этим критериям SoS были добавлены еще два важных свойства:
Самоорганизация. SoS имеет динамичную организационную структуру, способную реагировать на изменения в окружении и изменения целей и задач системы.
Адаптируемость. Вслед за ее динамичной организацией, сама структура SoS так же является динамичной и реагирующей на внешние изменения и восприятие окружения.
В зависимости от уровня зрелости, размера и стиля управления ИТ в организации могут встречаться ИТ ландшафты, относящиеся ко всему спектру типов SoS по классификации ISO 21839:2019:
Управляемый (directed) — при наличии Службы Главного Архитектора с достаточно широкими полномочиями, в том числе по распоряжению ресурсами команд проектов на реализацию архитектурных задач и задач по закрытию архдолга. Такой ИТ ландшафт характеризуется высокой структурированностью с минимальным количеством архдолга, но при этом относительно низкой скоростью изменения из-за жестких регламентов. Наблюдается в основном в средних и небольших компаниях. Строго говоря, SoS данного типа практически неотличима от обычной системы.
Подтвержденный (acknowledged) — при наличии Службы Главного Архитектора, которая способна эффективно коммуницировать с проектными командами развития приложений с целью внедрения архитектурного подхода в их практики. Наличие Архитектурного Комитета как коллективного оргзвена, обеспечивающего governance ИТ ландшафта. Характеризуется достаточно невысокой структурированностью и при этом высокой связностью приложений. Уровень архдолга может быть достаточно высоким. Наблюдается среди крупных компаний.
Коллаборативный (collaborative) — при небольшом количестве проектных команд-владельцев приложений. Характерно для небольших компаний. Архдолг не отслеживается.
Виртуальный (virtual) — при отсутствии управления ИТ как такового ИТ ландшафт в принятом нами понимании отсутствует и рассматривается в основном только как ИТ инфраструктура (серверы, хранилища и сетевые каналы).
Таким образом, ИТ ландшафт в крупных компаниях является системой систем (SoS) со всеми присущими ей свойствами.
Измеряем сложность
Несмотря на распространенность термина «сложность», на сегодняшний день для него не существует согласованного определения как в целом, так и в контексте управления архитектурой ИТ ландшафта, в частности. Кембриджский словарь, например, определяет сложность как «явление, при котором имеется множество связанных частей и которое сложно для понимания». Литература на эту тему предлагает самый широкий спектр концепций и способов измерения уровня сложности.
При этом рост сложности становится одним из ключевых факторов управляемости ИТ ландшафта, а, как известно, «невозможно управлять тем, что нельзя измерить».
Попытки измерения сложности ИТ ландшафта в крупных компаниях на сегодняшний день сводятся, как правило, к подсчету:
количества приложений;
количества информационных потоков между приложениями;
процента соответствия приложений стандартам;
количества инфраструктурных компонентов, используемых приложениями;
объема функционала приложений;
уровня дублирования функционала в приложениях.
Несмотря на то, что данные метрики являются интуитивно понятными и даже в определенной степени позволяют предсказывать затраты, они в то же время не позволяют на их основе вывести правдоподобный интегральный показатель сложности ИТ ландшафта и не имеют теоретического обоснования с точки зрения теории систем.
Питер Сенге предлагает считать, что системная сложность существует в двух основных формах:
Структурная сложность возникает в результате большого количества систем, системных элементов и установленных связей в любой из двух основных топологий (иерархия или сеть). Эта сложность связана с системами, как они есть;, а именно, с их статическим существованием.
Динамическая сложность связана с взаимосвязями, которые возникают между готовыми, функционирующими системами в процессе их работы, т. е. между ожидаемым и даже неожидаемым поведением, которое фактически возникает.
Сет Ллойд собрал некоторые примеры количественных мер сложности, которые он отнес к попыткам ответа на три вопроса:
Насколько трудно описать систему? Обычно это измеряется в битах информации, затрачиваемых на представление описания. Примеры мер: Information; Entropy; Algorithmic Complexity or Algorithmic Information Content и др.
Насколько трудно создать систему? Сложность как трудность создания измеряется во времени, энергии, стоимости и т.д. Примеры мер: Computational Complexity; Time Computational Complexity; Space Computational Complexity, Cost и др.
Какова степень организованности системы? Эту тему можно разделить на два типа метрик:
сложность описания организационной структуры, будь то корпоративная, химическая, клеточная и т. д. (Effective Complexity). Примеры мер: Metric Entropy; Fractal Dimension; Excess Entropy; Stochastic Complexity и др.
количество информации, которой обмениваются части системы вследствие ее структуры (Mutual Information). Примеры мер: Algorithmic Mutual Information; Channel Capacity; Correlation; Stored Information; Organization.
Есть также понятия, которые сами по себе не являются количественными мерами сложности, но очень близки к ним: Long-Range Order; Self-Organization; Complex Adaptive Systems; Edge of Chaos.
Применительно к ИТ ландшафту наибольший интерес представляют метрики, связанные с оценкой структурной сложности системы, основанные на неоднородности и топологии.
Так Александер Шютц и его соавторы предложили в качестве меры сложности ИТ ландшафта использовать количество и неоднородность его компонентов и их связей, где неоднородность ИТ ландшафта является статистическим свойством и относится к разнообразию атрибутов элементов ИТ ландшафта.
Шютц применил концепцию меры концентрации, главным образом энтропии Шеннона, для количественной оценки неоднородности.
, где n обозначает количество различных технических вариантов (например, количество различных используемых операционных систем), а pi обозначает относительную частоту определенного варианта i (например, количество экземпляров для типа операционной системы i).
Данный подход позволил авторам породить 10 количественных метрик сложности ИТ ландшафта, основанных на неоднородности:
Сложность типа приложения — количество и неоднородность уровней кастомизации приложений домена (make, buyAndCustomize, buy);
Сложность бизнес-функционала — количество и неоднородность бизнес-функций, поддерживаемых приложениями домена;
Сложность категорий компонентов — количество и неоднородность инфраструктурных компонентов определенной категории (ОС, СУБД и др.);
Сложность связанных доменов — количество и неоднородность функциональных доменов, с которыми связан выбранный домен, где связанность доменов определяется их приложениями и информационными потоками;
Сложность баз данных — количество и неоднородность СУБД, используемых приложениями домена;
Сложность реализации интерфейсов (приложение) — количество и неоднородность технических реализаций информационных потоков приложения;
Сложность реализации интерфейсов (домен) — количество и неоднородность технических реализаций информационных потоков приложений домена;
Сложность операционных систем — количество и неоднородность ОС, используемых приложениями домена;
Сложность типов операционных систем — количество и неоднородность типов ОС (вендор и версия), используемых приложением;
Сложность языков программирования — количество и неоднородность языков программирования, используемых приложениями домена.
Под доменами здесь понимаются оргзвенья предприятия (кредитование, депозиты, HR, риски, маркетинг, закупки и др.).
Другой метод измерения сложности ИТ ландшафта — на основе топологии — был предложен Робертом Лагерстремом с использованием широко распространенного в дисциплине архитектуры программного обеспечения подходе — Design Structure Matrix (DSM) — для визуализации скрытой структуры ИТ ландшафта и, таким образом, выявления участков повышенной сложности.
Метод, используемый для представления архитектуры сети, основан на классическом понятии связанности и расширяет его. В частности, после определения связанности (зависимости) между элементами в сложной архитектуре метод анализирует архитектуру с точки зрения иерархической упорядоченности и цикличности, позволяя классифицировать элементы с точки зрения их положения в результирующей сети.
Если DSM матрицу первого порядка возвести в последовательные степени, результат покажет прямые и косвенные зависимости, существующие для последовательных длин путей. Суммирование этих матриц дает матрицу видимости V, которая обозначает зависимости, существующие для всех возможных длин пути.
Далее для каждого приложения ИТ ландшафта в V матрице вычисляются метрики:
Visibility Fan-In (VFI) — количество приложений, которые явно или неявно зависят от текущего приложения;
Visibility Fan-Out (VFO) — количество приложений, от которых явно или неявно зависит текущее приложение.
Для измерения видимости на уровне всего ИТ ландшафта определяется показатель стоимости распространения (Propagation Cost) как плотность матрицы видимости. Интуитивно понятно, что стоимость распространения равна доле архитектуры, затронутой изменением случайно выбранного элемента (т.е. по сути это чувствительность ландшафта к изменениям). Ее можно вычислить на основе VFI или VFO:
Следующим шагом является поиск циклических групп в ИТ ландшафте. По определению каждый элемент внутри циклической группы прямо или косвенно зависит от любого другого члена группы. Найденные циклические группы называются «ядрами» системы. Самая большая циклическая группа («Ядро») играет особую роль в схеме архитектурной классификации ИТ ландшафта.
Далее на основе топологии ИТ ландшафта, т. е. приложений и их зависимостей, определяется тип его архитектуры (ядро-периферия, многоядерная или иерархическая). Все приложения ИТ ландшафта на основе их FVI и VFO подразделяются на центральные («ядровые»), управляющие, общие и периферийные. Центральные приложения определяются как самая большая группа приложений с циклическими зависимостями. Управляющие приложения имеют больше исходящих зависимостей, в то время как общие приложения имеют больше входящих зависимостей. Периферийные приложения имеют как меньше входящих, так и меньше исходящих зависимостей по сравнению с центральными. Ожидается, что особенно общие и «ядровые» приложения потребуют более высоких затрат/усилий, когда их необходимо изменить из-за их количества транзитивных зависимостей.
Используя приведенную выше схему классификации, можно построить реорганизованную DSM, которая раскрывает «скрытую структуру» архитектуры ИТ ландшафта, размещая элементы в порядке «Общие», «Ядро», «Периферия» и «Управление» вниз по главной диагонали DSM, а затем сортируя внутри каждой группы по убыванию VFI, затем по возрастанию VFO.
В отличие от других показателей сложности, связанности и модульности, данный метод «скрытой структуры» учитывает не только прямую сетевую структуру архитектуры, но и косвенные зависимости между приложениями, что вносит важный вклад в принятие управленческих решений.
Выводы
Понимание того, что в случае ИТ ландшафта мы имеем дело не с обычной системой, а именно со сложной системой систем (SoS), позволяет сделать следующие важные выводы:
Инженерия ИТ ландшафтов, особенно «подтвержденных» и «коллаборативных», должна учитывать все 7 основных характеристик SoS, поэтому базовых инструментов классической системной инженерии здесь может оказаться недостаточно.
Особая важность менеджерского аспекта (вопросы владения подсистемами и разрешение конфликтов в цепочках систем-создателей), а не только технических решений, должна обязательно учитываться при развитии ИТ ландшафта.
Структурирование ИТ ландшафта с использованием платформ и взаимодействие его подсистем на основе стандартизованных API позволяет снизить его сложность, эффективно находить консенсус при конфликтах систем-создателей и повысить уровень повторного использования ИТ активов в целевых системах бизнеса.
Измерение сложности ИТ ландшафта и противодействие ее увеличению должны являться одними из стратегических приоритетов компании.
Необходимо помнить, что при всей своей сложности ИТ ландшафт является всего лишь одной из подсистем-создателей (enabling system) внутри еще более сложной системы систем — организации.
В настоящее продолжаются активные исследования в области SoS и сложности систем, в том числе ИТ ландшафта, в различных корпорациях, университетах и государственных органах США и Европы. Возможно, в ближайшее время появятся более эффективные методы и развитый математический аппарат, применение которых поможет снизить сложность ИТ ландшафтов, а следовательно, уменьшить стоимость владения ИТ активами, снизить риски нарушения безопасности и непрерывности бизнеса, а также сократить Time-To-Market при выпуске новых продуктов.
Используемая литература
1. А. Левенчук «Практическое системное мышление — 2023».
2. А. Косяков, У. Свит, С. Бимер, С. Сеймур «Системная инженерия. Принципы и практика».
3. S. Lloyd «Measures of Complexity a non‑exhaustive list».
4. A. Schneider, T. Reschenhofer, A. Schütz, F. Matthes «Empirical Results for Application Landscape Complexity».
5. R. Lagerström, C. Baldwin, A. MacCormack, S. Aier «Visualizing and Measuring Enterprise Application Architecture: An Exploratory Telecom Case».
