разрыв не устраняется;

разрыв устраняется революционной трансформацией ИС в новую систему;

попытки устранения рассогласования между двумя компонентами приводят к его распространению на другие компоненты.

Таким образом, согласно модели Лиитинена и Ньюмана под воздействием потока внешних событий система большую часть времени развивается эволюционно, при этом инкрементально изменяются ее компоненты. Длительные периоды эволюционного развития прерываются революционными изменениями, когда система радикально изменяет за короткий промежуток времени свою структуру и правила связывания компонентов. В целом поведение системы является хаотическим. Основываясь на этой модели, мы можем уточнить определение адаптивной системы:

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

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

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

Операционные параметры адаптивной организации исследовал Р. Дав[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], где отмечается, что в таком случае возникают вопросы координации отдельных распределенных команд, согласования релизов, предварительной разработки общей архитектуры системы и т.п. Решение всех этих вопросов в рамках исключительно модели гибкой разработки невозможно, появляется потребность в создании единого координирующего и планирующего органа. Вторым обязательным условием реализации гибких методов на корпоративном уровне является соблюдение требований первой аксиомы аксиоматического дизайна, только это позволит обеспечить относительную автономность команд разработчиков, отвечающих за реализацию различных функциональных требований. В противном случае решения групп будут влиять друг на друга, что радикально усложнит их взаимодействие.

Другой способ поддержания адаптивности ИС обеспечивается технологией – это концепция платформы, на базе которой создается семейство продуктов, причем и платформа, и продукты должны управляемо эволюционировать[115]. Процессы разработки и поддержки платформы и приложений на ее базе должны быть разделены. Под платформой здесь понимается не программная среда типа Java или .Net, а некий набор слабо связанных бизнес-объектов и средств интеграции и автоматизации бизнес-процессов, которые могут быть достаточно просто переконфигурированы в зависимости от текущих задач предприятия. Существующие индустриальные тренды (SOA, BPM, model business management – MBM, бизнес-правила, отделение реализации от интерфейса и т.д.)[116], кажется, позволяют создавать системы, которые могли бы в дальнейшем легко реконфигурироваться.

Такой платформой может стать и ERP система. Но при этом надо оценивать степень простоты и быстроты внесения изменений в текущую конфигурацию. Большинство предлагаемых сейчас на рынке ERP систем данному требованию не удовлетворяют. Эти системы имеют значительное количество перекрестных связей между модулями, внесение даже незначительных изменений связано с большими трудностями. Можно утверждать, что их дизайн не соответствует аксиоме независимости. Фактически эти системы жестко фиксируют существующую на момент их внедрения бизнес-практику, поэтому их изменение обходится слишком дорого.