Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности
Шрифт:
Системные архитекторы в этом случае рассматривают релиз целиком и декомпозируют его на отдельные задания для разработчиков. По мере завершения разработки производится тестирование интеграции и функциональности вновь создаваемых модулей. Для этого целесообразно развернуть специальную тестовую среду, повторяющую окружение промышленной системы. К такому тестированию могут быть привлечены и ключевые пользователи. Когда внутреннее тестирование релиза завершается, он переносится в промышленную систему, о чем уведомляются пользователи, заявки которых реализованы в данном обновлении. Они также должны подтвердить удовлетворение их требований.
Отметим, что подготовка нового
Модель скользящих слоев
В этом разделе мы вернемся к обсуждению вопроса правильной организации технологической платформы, на которой может быть построена адаптивная информационная система.
Самый простой путь к обеспечению адаптивности не только информационной, но и любой другой системы, это разделение ее на относительно слабо связанные модули, которые могут развиваться независимо. Поэтому проблема проектирования и управления модульными системами с адаптивным поведением является центральной в исследованиях по теории организации. Однако, как заметили Сендил Этирадж и Дэниел Левинтол[121], при этом, собственно, вопросу оптимального выделения модулей уделяется мало внимания. Проектировщики сложных систем имеют дело с четырьмя видами решений:
1. разделение системы на «правильное» количество модулей;
2. «правильное» отображение параметров проектирования на модули;
3. «правильная» организация взаимодействия элементов внутри модуля;
4. «правильная» организация интерфейсов между модулями.
Общего решения этой задачи для систем любого вида, видимо, не существует. Тем не менее, в некоторых областях человеческой деятельности достигнут определенный успех в формализации разделения системы на модули. В частности, в строительстве и архитектуре существует концепция скользящих слоев (shearing layers), выдвинутая британским архитектором Фрэнком Даффи, основное внимание в своих работах уделяющим гибкому использованию рабочего пространства. Широкую известность этот подход получил после выхода книги Стюарта Бренда «Как обучается здание: что происходит после того, как оно построено»[122].
Согласно этой концепции здание рассматривается как комбинация нескольких слоев, которые существуют в различных масштабах времени, и обмен энергией, веществом и информацией между ними сведен к минимуму (таблица 6.4). Поэтому развитие таких слоев происходит автономно, без взаимодействия друг с другом. В быстрых слоях осуществляется поиск новых возможностей, медленные обеспечивают непрерывность, они служат инфраструктурой. Здание может адаптироваться к изменяющимся условиям, если обеспечено свободное «скольжение» слоев друг относительно друга, т.е. изменение быстрых слоев не затормаживается влиянием более медленных, и быстрые слои не деформируют медленные. Именно это обеспечивает максимальную адаптивность.
Возможность применить аналогичную модель для описания адаптивных свойств информационной системы выглядит очень привлекательно, поскольку практика подсказывает, что элементы ИС также имеют различные жизненные циклы. Наиболее общий пример – различие между моделью данных и собственно данными. Данные изменяются постоянно,
Су Линг Лим и Энтони Финкельшейн[123], рассматривая задачу управления требованиями при разработке программных систем, выделили четыре элемента, которые изменяются с относительно разными скоростями. В порядке перечисления от наиболее стабильных элементов к более изменчивым это:
Паттерны – элементы функциональности, которые остаются неизменными в течение значительного времени. Они инкапсулируют данные, базовые общие функции (такие, как add, find, get и т.д.) и основные функции, специфичные для конкретного домена данных, например, «зарезервировать» для паттерна «товар».
Функциональные ограничения, которые связаны с поддержкой выполнения пользователями их задач, и остаются неизменными, пока не меняются бизнес-процессы.
Нефункциональные ограничения, которые диктуются требованиями качества (например, время реакции, доступность и т.д.). Изменения этих ограничений не зависят от функциональности и возникают тогда, когда система перестает удовлетворять возрастающим требованиям по качеству, например, при увеличении числа пользователей.
Бизнес-правила, которые меняются наиболее часто, т.к. именно они обеспечивают реакцию организации на изменения во внешней среде. Например, менеджмент может решить сократить нормативное время обработки заказа от покупателя с 1 дня до 4 часов.
Такая классификация слоев, безусловно, имеет право на существование и представляет практическую ценность, но она применима только к программным системам. Если мы обсуждаем корпоративную информационную систему как единое целое, необходимо расширить рамки.
Корпоративная ИС может рассматриваться как набор проблемно-ориентированных подсистем (ERP, PDM и др.), которые работаю совместно и формируют единое целое. Каждая подсистема имеет связи с ресурсами и другими подсистемами, что приводит к сложному взаимодействию между ними. Можно выделить три сети, обеспечивающие связь между системами (рис. 6.10)[124]:
Физическая сеть связывает элементы оборудования и обеспечивает передачу данных между системными платформами.
Программная сеть предоставляет инструменты для трансформации передаваемых данных в информацию, которая совместно используется сотрудниками организации.
Социальная сеть обеспечивает взаимодействие людей, которые также являются компонентом корпоративной системы.
Это более традиционное представление корпоративной ИС, чем взгляд на нее как на комбинацию сервисов поддержки инфраструктуры, бизнес-приложений и бизнес-процессов, предложенный выше.
Изменения в любой сети, вызванные внешними причинами, должны сопровождаться соответствующими изменениями в других сетях. Поэтому каждая подсистема может рассматриваться как состоящая минимум из трех частей – техническое обеспечение, программное обеспечение и пользователи. Отметим, что это близко к традиционному представлению архитектуры предприятия в виде четырех доменов (бизнес-процессы, данные, приложения и техническая архитектура), но в данном случае домен данных и приложений объединен в один. К сожалению, такой таксономии недостаточно, поскольку она не позволяет выделить элементы с различными циклами изменения.