Юрий Зеленков - Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности

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

Су Линг Лим и Энтони Финкельшейн[123], рассматривая задачу управления требованиями при разработке программных систем, выделили четыре элемента, которые изменяются с относительно разными скоростями. В порядке перечисления от наиболее стабильных элементов к более изменчивым это:

Паттерны – элементы функциональности, которые остаются неизменными в течение значительного времени. Они инкапсулируют данные, базовые общие функции (такие, как add, find, get и т.д.) и основные функции, специфичные для конкретного домена данных, например, «зарезервировать» для паттерна «товар».

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

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

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

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

Корпоративная ИС может рассматриваться как набор проблемно-ориентированных подсистем (ERP, PDM и др.), которые работаю совместно и формируют единое целое. Каждая подсистема имеет связи с ресурсами и другими подсистемами, что приводит к сложному взаимодействию между ними. Можно выделить три сети, обеспечивающие связь между системами (рис. 6.10)[124]:

Физическая сеть связывает элементы оборудования и обеспечивает передачу данных между системными платформами.

Программная сеть предоставляет инструменты для трансформации передаваемых данных в информацию, которая совместно используется сотрудниками организации.

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

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

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

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

Также следует заметить, что в большинстве организаций подсистемы проектируются, реализуются и оптимизируются для решения относительно локальных проблем, очень редко присутствует единый взгляд на их сочетание, как корпоративную систему. Это объясняется тем, что не существует информационных систем, способных обеспечить все потребности достаточно крупной организации, приходится комбинировать продукты нескольких поставщиков. В результате подсистемы используют различные форматы и семантику данных, созданы с использованием разных языков программирования, реализуют несогласованные модели бизнес-процессов и требуют несовместимых программных платформ. Все это приводит к проблеме интеграции. Рональд Гьячетти и его коллеги[125] выделяют пять уровней интеграции: