Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности - страница 33
технологии (инструменты, используемые при решении задач),
задачи (цели и способы, которыми они достигаются).
Следует отметить, что границы между компонентами размыты, но все они связаны друг с другом. Их взаимодействие складывается как из линейных связей типа «причина – следствие» (причем эти связи, как правило, проектируются заранее), так и из нелинейных, спонтанно возникающих, часто непредсказуемых отношений. Поэтому невозможно оптимизировать только один аспект системы – социальный или технический. На ИС непрерывно воздействуют внешние события, связанные с изменением окружающей среды (под окружающей средой понимаются как другие системы организации, так и внешние по отношению к организации системы), которые нарушают согласованность компонентов системы. К числу таких событий могут относиться появление новых технологий, оптимизация бизнес-процессов, изменение состава или количества пользователей и даже изменение команды разработчиков, например, приход на работу нового аналитика или архитектора и т.д. События вызывают рассогласование между компонентами системы (см. таблицу 6.1). При наличии такого рассогласования система предпринимает действия по его устранению. Отметим, что не все действия ведут к успеху, в общем случае возможны четыре исхода:
разрыв устраняется инкрементальными изменениями компонент;
разрыв не устраняется;
разрыв устраняется революционной трансформацией ИС в новую систему;
попытки устранения рассогласования между двумя компонентами приводят к его распространению на другие компоненты.
Таким образом, согласно модели Лиитинена и Ньюмана под воздействием потока внешних событий система большую часть времени развивается эволюционно, при этом инкрементально изменяются ее компоненты. Длительные периоды эволюционного развития прерываются революционными изменениями, когда система радикально изменяет за короткий промежуток времени свою структуру и правила связывания компонентов. В целом поведение системы является хаотическим. Основываясь на этой модели, мы можем уточнить определение адаптивной системы:
Адаптивная система должна компенсировать максимально возможное количество рассогласований между компонентами, вызываемых внешними событиями, путем инкрементальных изменений.
Это должно обеспечиваться ее структурными свойствами, которые определяются на стадии проектирования. Варианты такого дизайна будут рассмотрены в следующем разделе.
Стратегия обеспечения адаптивности должна быть частью общей ИТ-стратегии, независимо от того, в каком виде последняя институционализирована в организации – как план или как принцип поведения.
Операционные параметры адаптивной организации исследовал Р. Дав[112], к их числу относятся: время и затраты на проведение изменений, объем изменений, устойчивость процесса проведения изменений.
Таким образом, опираясь на результаты Шарифи и Джанга, Лиитинена и Ньюмена и Дава можно предложить модель адаптивной информационной системы, представленную на рис. 6.3.
Обеспечение адаптивности ИС
Общие закономерности создания систем различного рода выделены в методологии аксиоматического проектирования, разработанной профессором Массачусетского технологического института Су Нам-пио[113]. Этот подход выделяет несколько независимых доменов (домен потребителей, а также функциональный, физический и процессный домены, см. рис. 6.4), каждый из которых характеризуется вектором определенных параметров (соответственно атрибуты потребителя, функциональные требования, параметры проектирования и переменные процессов). Во время проектирования производится отображение параметров одного домена на параметры другого. Если связи между параметрами верхнего уровня недостаточно детализированы, проектировщик вынужден их декомпозировать, возвращаясь к предыдущему домену и обратно, используя движение зигзагом (рис. 6.5).
Аксиоматическое проектирование построено на двух аксиомах. Первая (аксиома независимости) требует поддерживать независимость функциональных требований. Собственно, проектирование продукта (системы) это отображение вектора функциональных требований [FR] на вектор параметров проектирования [DP]. В случае ИС проектными решениями могут быть декомпозиция ее на сервисы, программные модули, объекты и т.п. Обсуждаемое отображение может быть представлено в виде произведения [FR]=[A][DP], где [A] – матрица проектирования. Вид этой матрицы определяет качество проектирования. В идеальном случае она должна быть диагональной, т.е. каждому функциональному требованию должно соответствовать только одно проектное решение. В случае треугольной матрицы [A] каждое функциональное требование влияет на несколько проектных решений, но обратного влияния нет. Эти два случая удовлетворяют аксиоме независимости. Во всех прочих случаях одно проектное решение может быть реализацией нескольких функциональных требований, что приводит к взаимному влиянию функциональных требований друг на друга.
