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

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

Это должно обеспечиваться ее структурными свойствами, которые определяются на стадии проектирования. Варианты такого дизайна будут рассмотрены в следующем разделе.

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

Операционные параметры адаптивной организации исследовал Р. Дав[112], к их числу относятся: время и затраты на проведение изменений, объем изменений, устойчивость процесса проведения изменений.

Таким образом, опираясь на результаты Шарифи и Джанга, Лиитинена и Ньюмена и Дава можно предложить модель адаптивной информационной системы, представленную на рис. 6.3.

Обеспечение адаптивности ИС

Общие закономерности создания систем различного рода выделены в методологии аксиоматического проектирования, разработанной профессором Массачусетского технологического института Су Нам-пио[113]. Этот подход выделяет несколько независимых доменов (домен потребителей, а также функциональный, физический и процессный домены, см. рис. 6.4), каждый из которых характеризуется вектором определенных параметров (соответственно атрибуты потребителя, функциональные требования, параметры проектирования и переменные процессов). Во время проектирования производится отображение параметров одного домена на параметры другого. Если связи между параметрами верхнего уровня недостаточно детализированы, проектировщик вынужден их декомпозировать, возвращаясь к предыдущему домену и обратно, используя движение зигзагом (рис. 6.5).

Аксиоматическое проектирование построено на двух аксиомах. Первая (аксиома независимости) требует поддерживать независимость функциональных требований. Собственно, проектирование продукта (системы) это отображение вектора функциональных требований [FR] на вектор параметров проектирования [DP]. В случае ИС проектными решениями могут быть декомпозиция ее на сервисы, программные модули, объекты и т.п. Обсуждаемое отображение может быть представлено в виде произведения [FR]=[A][DP], где [A] – матрица проектирования. Вид этой матрицы определяет качество проектирования. В идеальном случае она должна быть диагональной, т.е. каждому функциональному требованию должно соответствовать только одно проектное решение. В случае треугольной матрицы [A] каждое функциональное требование влияет на несколько проектных решений, но обратного влияния нет. Эти два случая удовлетворяют аксиоме независимости. Во всех прочих случаях одно проектное решение может быть реализацией нескольких функциональных требований, что приводит к взаимному влиянию функциональных требований друг на друга.

Аналогичные рассуждения можно повторить и для разработки технологий изготовления продукта, во время которой вектор параметров проектирования [DP] отображается на вектор параметров процессного домена [PV], но при обсуждении ИС это отображение обычно не рассматривается.

Вторая аксиома (информационная) требует минимизировать объем информации в процессе проектирования или, не вдаваясь в детали, увеличить вероятность удовлетворения функциональных требований. Информация в данном случае определяется как Ii=-log2 pi , где pi – вероятность удовлетворения функционального требования FRi. Когда необходимо удовлетворить n требований, лучшим проектом будет тот, который соответствует минимальному объему информации

Рассмотрение принципов проектирования адаптивных систем необходимо начать с обсуждения возможности распространить методы гибкой разработки ПО (XP, Scrum, RUP и др.) на создание и развитие корпоративной ИС системы в целом, поскольку эти методы достигли уже значительной степени зрелости. Однако при этом возникает ряд ограничений, связанных с масштабом проектов. Фактически, команды разработчиков, следующие гибким методам, используют свою способность чрезвычайно быстро создавать программный код для выяснения и уточнения требований пользователей. Отсюда вытекают особенности организации процесса разработки – небольшие команды, сосредоточенные в одном месте, интеграция заказчика в такую команду, отказ от утвержденных спецификаций до начала разработки и т.д. Все это позволяет разрабатывать относительно небольшие слабо интегрированные в корпоративную ИС приложения. Задача распространения гибких методов на корпоративную ИС исследована Д. Леффингвеллом[114], где отмечается, что в таком случае возникают вопросы координации отдельных распределенных команд, согласования релизов, предварительной разработки общей архитектуры системы и т.п. Решение всех этих вопросов в рамках исключительно модели гибкой разработки невозможно, появляется потребность в создании единого координирующего и планирующего органа. Вторым обязательным условием реализации гибких методов на корпоративном уровне является соблюдение требований первой аксиомы аксиоматического дизайна, только это позволит обеспечить относительную автономность команд разработчиков, отвечающих за реализацию различных функциональных требований. В противном случае решения групп будут влиять друг на друга, что радикально усложнит их взаимодействие.