Изменения «наружной поверхности» ИС определяются развитием таких технологий, как Message-Oriented Middleware (MOM), Enterprise Service Bus (ESB), Service-Oriented Architecture (SOA), и происходят каждые 5–7 лет.

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

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

Измерение уровня адаптивности ИС

Существенным вопросом является построение системы количественного измерения уровня адаптивности ИТ-инфраструктуры. Многие авторы отмечают, что данная задача чрезвычайно сложна, поскольку само определение адаптивности (обнаружение изменений и реакция на них) недостаточно формализовано. Более того, количественное измерение структурных параметров системы, определяющих ее адаптивность, невозможно, поэтому приходится ограничиваться измерением операционных характеристик. В связи с перечисленными проблемами наиболее широкое распространение получили подходы, предусматривающие качественную оценку[129], а также их развитие на основе лингвистических переменных и нечеткой логики[130].

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

Время, требуемое для реакции на изменения;

Стоимость изменений;

Качество, понимаемое как устойчивость процесса изменений;

Объем изменений.

Частично этот подход реализован в банке Credit Suise Switzerland[132], где используется следующая метрика адаптивности ИС:

Здесь

– осредненное время выполнения проектов по созданию новых систем, Ti – время выполнения i-го проекта (дни), si - размер i-го проекта, выражаемый в UCP (use case points);  – осредненная стоимость проекта, Ci – затраты на выполнение i-го проекта. UCP это специальная мера функциональной сложности проекта, построенная на основе use case моделей языка UML[133]. Она предполагает выявление акторов и сценариев использования и оценку сложности на основе их весовых коэффициентов. Данная мера хорошо подходит для стандартных информационных бизнес-систем, где много пользовательского интерфейса и мало сложных алгоритмов. Альтернативами являются методика функциональных точек (functional point) и ее модификации. Таким образом, показатель, вычисляемый по приведенной формуле, представляет квадрат количества реализованной функциональности в UCP, отнесенный к произведению истраченных времени и затрат, что является комбинацией метрик времени, стоимости и объема, предложенных Р. Давом. В Credit Suise Switzerland показатель адаптивности, вычисляемый по этой формуле, в результате направленных действий вырос за 17 кварталов от 0,15 (июнь 2005) до 0,25 (сентябрь 2009). Интересно, что для проектов на базе собственной технологической платформы среднее значение показателя адаптивности за это время составило 0,24; для прочих проектов – 0,09.

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

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

На основании результатов Дж. Хоббса и Р. Шиперса[134] можно предложить модель поддержания адаптивности ИС (рис. 6.11), которая предполагает формирование действий на основе непрерывного анализа текущих и предсказания потенциальных будущих потребностей. Отметим, что под внешней средой при этом понимаются все возможные системы, находящие вне периметра ИТ-департамента (другие подразделения организации, ее партнеры и конкуренты, разработчики и поставщики технологий, регулирующие органы и т.д.).

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

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

7. Институционализация

В нашем ремесле побеждают те, у кого есть приоритеты и нет принципов.

Карлос Луис Сафон. Игра ангела.

В заключение необходимо сказать несколько слов о том, как «узаконить» предложенные методы в организации.

Нашей жизнью управляют социальные институты – общественные правила, определяющие поведение некоторого подмножества членов того или иного сообщества[135]. В качестве такого подмножества можно рассматривать компанию, различные ее подразделения и даже ограниченный круг менеджеров высшего звена. Собственно сам процесс упорядочения, формализации и стандартизации социальных отношений и называется институционализацией. Очевидно, что какие-то системы ценностей, норм, идеалов, образцов деятельности должны регулировать и поведение относительно ИТ. Вопрос в том, может ли CIO повлиять на них? По моему мнению, не только может, но и должен. Если предложить своим коллегам – менеджерам других функциональных областей обоснованные модели (например, те, что предложены в этой книге) поведения и правила оценки результатов, самому строго соблюдать эти правила, велик шанс, что они и станут таким институтом. Далее обсуждаются некоторые принципы, которые могут помочь построить открытое и честное взаимодействие ИТ и бизнеса.