Оценка зрелости архитектуры

Как и для всякого проекта, при разработке и внедрении архитектуры предприятия нужно уметь оценивать уровень полученного результата. Для этого META Group рекомендовала использовать шкалу зрелости, аналогичную той, которая применяется в методике Capability Maturity Model (CMM), предложенной Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона CMM. Аналогичный подход был предложен для оценки архитектур ИС федеральных органов в США.

Мы неоднократно будем сталкиваться с аналогичными моделями оценки зрелости тех или иных процессов, например, процесса организации инвестиций в ИТ. В основе всех таких моделей, по большому счету, лежит новаторская работа Филиппа Кросби (Philip Crosby) " Quality is Free " (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством TQM (Total Quality Management), созданной В. Деммингом, Дж. Мураном и Ф. Кросби.

Кросби разработал методику, которая включает в себя пять стадий или уровней развития процессов, связанных с качеством. Он назвал эти стадии следующим образом:

В отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней:

Уровень 3. Определенный или регламентируемый.

В табл. 12.1 приведены общие характеристики уровней организационной зрелости.

Таблица 12.1. Характеристики уровней организационной зрелости
Уровень	Основные характеристики
1. Начальный	Спонтанные информационные связи. Хаотичность, непоследовательность
2. Повторяемый	Базовые процессы. Повторяемые операции
3. Определенный	Стандартизация процессов. Интеграция, наличие процедур
4. Управляемый	Контроль качества. Использование обратной связи
5. Оптимизирующий	Постоянное развитие. Самоадаптация системы

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

Таблица 12.2. Шкала уровней зрелости архитектуры предприятия
	Уровень 1 начальный	Уровень 2 повторяемый	Уровень 3 определенный	Уровень 4 управляемый	Уровень 5 оптимизированный
Связь с миссией организации	Отсутствует или неявная	Явная связь с миссией.	Явная связь с ключевыми параметрами миссии	Периодическая переоценка актуальности связи. Контролируемый интервал времени между изменением требований и изменением архитектуры	Процессы постоянно улучшаются на основании измеряемых требований
Вовлеченность высшего руководства	"Что такое корпоративная архитектура?" "Зачем она нам вообще нужна?" "Нет, это у нас работать не будет"	Руководство что-то слышало о проекте по разработке архитектуры. Усердное кивание головами. Некоторое сопротивление в связи с ожидаемыми результатами	Руководство в курсе проекта и поддерживает его. Руководство поддерживает наличие стандартов	Высшее руководство участвует в обсуждении результатов проекта	Руководство активно участвует в оптимизации бизнес-процессов в рамках архитектурного проекта.
Участие бизнес-подразделений	"Мы поддерживаем данный проект, пока он рекомендует те стандарты, которые мы уже сами раньше выбрали". "Стандарты только помешают нам реализовать миссию предприятия"	Признание факта, что поддержка слишком большого числа разных технологий накладна. Возможно разочарование от внедрения инновационных приложений "в пустоте"	Признание факта, что стандарты архитектуры помогут облегчить интеграцию и повысят шансы компании на реализацию миссии. Большинство бизнес-подразделений активно участвуют в разработке архитектуры	Все бизнес-подразделения активно участвуют в разработке архитектуры	Рекомендации бизнес-подразделений используются для улучшения самого процесса разработки архитектуры
Описание самого процесса разработки архитектуры	Отсутствует или сохраняется в том виде, как осталось к моменту завершения прошлого провального проекта	Активно разрабатывается внутри ИТ-службы. Недостаточно широко известно в организации	Процесс хорошо определен и известен ИТ-специалистам и бизнес-подразделениям	Процесс является частью корпоративной культуры, он сильно связан с другими процессами, такими как финансовое планирование, реинжиниринг, разработка новых продуктов и др.	Спланированные усилия по оптимизации процесса. Моделирование предлагаемых изменений процесса перед реализацией
Разработка профилей стандартов	Нет никакой архитектуры – просто не о чем говорить. Несколько стандартов, выбранных случайным образом	Стандарты существуют, но не объединены в систему	Разработка профилей стандартов связана с бизнес-требованиями посредством концептуальной архитектуры, определенных принципов и лучших практик	Архитектура компонент ИС определена вплоть до уровня стандартов. Эксплуатируемые системы проверяются на соответствие стандартам	То же, что и на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса разработки aрхитектуры
Распространение описания архитектуры в организации	Вроде бы описание находится в папке, которую недавно видели где-то в службе ИТ. Новые сотрудники ИТ-службы, вероятнее всего, даже не знают о существовании этой папки	Папка с описанием архитектуры периодически обновляется, или результаты размещаются на web-сайте. Для документирования используется MS Word и картинки. Совещания и обсуждения архитектуры иногда имеют место	Документы регулярно обновляются и уточняются. Актуальная на каждый момент версия доступна на web-сайте, в БД коллективного доступа и т.п. Для управления документацией используются специализированные средства. Периодические презентации по ходу процесса для ИТ-службы. Вероятно, они входят в курс начального обучения новых сотрудников	Документы регулярно обновляются и уточняются с контролируемыми сроками. Проводится мониторинг обучения и ознакомления	То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса распространения архитектуры
Контроль за применением стандартов	Явные процедуры отсутствуют	Некоторые стандарты контролируются (напр., ПО рабочих станций). Отклонения на стадиях проектирования и внедрения могут остаться незамеченными	Явный контроль основной части стандартов. Формализованный процесс рассмотрения отклонений	Явный контроль всех инвестиций в ИТ. Формализованный процесс использования выявленных отклонений для коррекции архитектуры	То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса контроля
Управление проектом разработки архитектуры	Стандарты и средства отсутствуют или случайные. Формальный механизм определения приоритетов отсутствует	Используются средства планирования и управления. Оценка рисков производится командой проекта	Целевая архитектура определяет требования к квалификации персонала. Процедуры управления изменениями определены и связаны с процессом рецензирования архитектуры	Инициация проекта и определение ключевых требований производится совместно руководителями организации и ИТ-службы. Управление вендорами – одна из ключевых компетенций. Требования непрерывности производства заложены в цикл планирования проекта	Действует программа обеспечения результативности. Контракты с вендорами продлеваются на основе измеряемых показателей производительности и соответствия корпоративным стандартам. Ключевая компетенция – непрерывность бизнеса
Корпоративная архитектура масштаба предприятия	Миссия, требования к данным и приложениям определены только в принципе. Данные о процессах, приложениях, информационных ресурсах, а также их модели неполны или отсутствуют вообще	Большинство приложений перечислены в реестре. Для части бизнес-процессов существуют модели	Все приложения классифицированы в реестре в соответствии с их позиционированием для бизнеса и состоянием. Модели бизнес-процессов существуют и используются для проектирования разработки решений	Моделирование процессов и выбор приложений производится в соответствии с архитектурой. Методы и средства моделирования периодически проверяются. Оцениваются затраты времени на моделирование и фактическое использование моделей	Метрики, определяемые на уровне 4, используются для улучшения процессов. Происходит переход от использования отдельных приложений к использованию решений. Бизнес-моделирование является постоянным и обязательным, актуальные модели сохраняются в общем репозитории
Организация закупок ИТ	Стратегия закупок отсутствует. Персонал, участвующий в закупках, не принимает заметного участия в процессе разработки архитектуры	Декларируется следование процедурам и стандартам. Контроль заявок и фактических закупок на соответствие архитектуре неполный или отсутствует	Стратегия закупок определена и предусматривает соответствие стандартам архитектуры. Требования запросов на закупку формируются с учетом стандартов. Персонал, осуществляющий закупки, участвует в контроле за соблюдением стандартов	Все закупки планируются и управляются в соответствии с определенной архитектурой. Оценка предложений поставщиков интегрирована в процесс планирования архитектуры. Существуют процедуры по учету и утилизации устаревающих компонент ИС	Незапланированные закупки отсутствуют

Аналогичная модель, правда, с разбиением уровня 1 на два – "начальный" и "отсутствующий", предложена Институтом разработок архитектуры предприятия (Institute for Enterprise Architecture Developments).

Интересное распределение организаций из группы Global 2000 по степени зрелости архитектуры приведено, в таблице 12.3.