On_load_lecture(); 9.7. Оценка зрелости архитектуры
Как и для всякого проекта, при разработке и внедрении архитектуры предприятия нужно уметь оценивать уровень полученного результата. Для этого META Group рекомендовала использовать шкалу зрелости, аналогичную той, которая применяется в методике Capability Maturity Model (CMM), предложенной Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона CMM. Аналогичный подход был предложен для оценки архитектур ИС федеральных органов в США.
Мы неоднократно будем сталкиваться с аналогичными моделями оценки зрелости тех или иных процессов, например, процесса организации инвестиций в ИТ. В основе всех таких моделей, по большому счету, лежит новаторская работа Филиппа Кросби (Philip Crosby) "Quality is Free" (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством TQM (Total Quality Management), созданной В. Деммингом, Дж. Мураном и Ф. Кросби.
Кросби разработал методику, которая включает в себя пять стадий или уровней развития процессов, связанных с качеством. Он назвал эти стадии следующим образом:
- неопределенность;
- пробуждение;
- осведомленность или обучение;
- мудрость;
- определенность.
В отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней:
Уровень 1. Начальный.
Уровень 2. Повторяемый.
Уровень 3. Определенный или регламентируемый.
Уровень 4. Управляемый.
Уровень 5. Оптимизирующий.
В табл. 12.1 приведены общие характеристики уровней организационной зрелости.
| Таблица 9.6. Характеристики уровней организационной зрелости | |
| Уровень | Основные характеристики |
| 1. Начальный | Спонтанные информационные связи. Хаотичность, непоследовательность |
| 2. Повторяемый | Базовые процессы. Повторяемые операции |
| 3. Определенный | Стандартизация процессов. Интеграция, наличие процедур |
| 4. Управляемый | Контроль качества. Использование обратной связи |
| 5. Оптимизирующий | Постоянное развитие. Самоадаптация системы |
Таблица 9.7 подробнее расшифровывает критерии, которым архитектура должна удовлетворять на различных уровнях своего развития.
| Таблица 9.7. Шкала уровней зрелости архитектуры предприятия | |||||
| Уровень 1 начальный | Уровень 2 повторяемый | Уровень 3 определенный | Уровень 4 управляемый | Уровень 5 оптимизированный | |
| Связь с миссией организации | Отсутствует или неявная | Явная связь с миссией. | Явная связь с ключевыми параметрами миссии | Периодическая переоценка актуальности связи. Контролируемый интервал времени между изменением требований и изменением архитектуры | Процессы постоянно улучшаются на основании измеряемых требований |
| Вовлеченность высшего руководства | "Что такое корпоративная архитектура?" "Зачем она нам вообще нужна?" "Нет, это у нас работать не будет" | Руководство что-то слышало о проекте по разработке архитектуры. Усердное кивание головами. Некоторое сопротивление в связи с ожидаемыми результатами | Руководство в курсе проекта и поддерживает его. Руководство поддерживает наличие стандартов | Высшее руководство участвует в обсуждении результатов проекта | Руководство активно участвует в оптимизации бизнес-процессов в рамках архитектурного проекта. |
| Участие бизнес-подразделений | "Мы поддерживаем данный проект, пока он рекомендует те стандарты, которые мы уже сами раньше выбрали". "Стандарты только помешают нам реализовать миссию предприятия" | Признание факта, что поддержка слишком большого числа разных технологий накладна. Возможно разочарование от внедрения инновационных приложений "в пустоте" | Признание факта, что стандарты архитектуры помогут облегчить интеграцию и повысят шансы компании на реализацию миссии. Большинство бизнес-подразделений активно участвуют в разработке архитектуры | Все бизнес-подразделения активно участвуют в разработке архитектуры | Рекомендации бизнес-подразделений используются для улучшения самого процесса разработки архитектуры |
| Описание самого процесса разработки архитектуры | Отсутствует или сохраняется в том виде, как осталось к моменту завершения прошлого провального проекта | Активно разрабатывается внутри ИТ-службы. Недостаточно широко известно в организации | Процесс хорошо определен и известен ИТ-специалистам и бизнес-подразделениям | Процесс является частью корпоративной культуры, он сильно связан с другими процессами, такими как финансовое планирование, реинжиниринг, разработка новых продуктов и др. | Спланированные усилия по оптимизации процесса. Моделирование предлагаемых изменений процесса перед реализацией |
| Разработка профилей стандартов | Нет никакой архитектуры – просто не о чем говорить. Несколько стандартов, выбранных случайным образом | Стандарты существуют, но не объединены в систему | Разработка профилей стандартов связана с бизнес-требованиями посредством концептуальной архитектуры, определенных принципов и лучших практик | Архитектура компонент ИС определена вплоть до уровня стандартов. Эксплуатируемые системы проверяются на соответствие стандартам | То же, что и на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса разработки aрхитектуры |
| Распространение описания архитектуры в организации | Вроде бы описание находится в папке, которую недавно видели где-то в службе ИТ. Новые сотрудники ИТ-службы, вероятнее всего, даже не знают о существовании этой папки | Папка с описанием архитектуры периодически обновляется, или результаты размещаются на web-сайте. Для документирования используется MS Word и картинки. Совещания и обсуждения архитектуры иногда имеют место | Документы регулярно обновляются и уточняются. Актуальная на каждый момент версия доступна на web-сайте, в БД коллективного доступа и т.п. Для управления документацией используются специализированные средства. Периодические презентации по ходу процесса для ИТ-службы. Вероятно, они входят в курс начального обучения новых сотрудников | Документы регулярно обновляются и уточняются с контролируемыми сроками. Проводится мониторинг обучения и ознакомления | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса распространения архитектуры |
| Контроль за применением стандартов | Явные процедуры отсутствуют | Некоторые стандарты контролируются (напр., ПО рабочих станций). Отклонения на стадиях проектирования и внедрения могут остаться незамеченными | Явный контроль основной части стандартов. Формализованный процесс рассмотрения отклонений | Явный контроль всех инвестиций в ИТ. Формализованный процесс использования выявленных отклонений для коррекции архитектуры | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса контроля |
| Управление проектом разработки архитектуры | Стандарты и средства отсутствуют или случайные. Формальный механизм определения приоритетов отсутствует | Используются средства планирования и управления. Оценка рисков производится командой проекта | Целевая архитектура определяет требования к квалификации персонала. Процедуры управления изменениями определены и связаны с процессом рецензирования архитектуры | Инициация проекта и определение ключевых требований производится совместно руководителями организации и ИТ-службы. Управление вендорами – одна из ключевых компетенций. Требования непрерывности производства заложены в цикл планирования проекта | Действует программа обеспечения результативности. Контракты с вендорами продлеваются на основе измеряемых показателей производительности и соответствия корпоративным стандартам. Ключевая компетенция – непрерывность бизнеса |
| Корпоративная архитектура масштаба предприятия | Миссия, требования к данным и приложениям определены только в принципе. Данные о процессах, приложениях, информационных ресурсах, а также их модели неполны или отсутствуют вообще | Большинство приложений перечислены в реестре. Для части бизнес-процессов существуют модели | Все приложения классифицированы в реестре в соответствии с их позиционированием для бизнеса и состоянием. Модели бизнес-процессов существуют и используются для проектирования разработки решений | Моделирование процессов и выбор приложений производится в соответствии с архитектурой. Методы и средства моделирования периодически проверяются. Оцениваются затраты времени на моделирование и фактическое использование моделей | Метрики, определяемые на уровне 4, используются для улучшения процессов. Происходит переход от использования отдельных приложений к использованию решений. Бизнес-моделирование является постоянным и обязательным, актуальные модели сохраняются в общем репозитории |
| Организация закупок ИТ | Стратегия закупок отсутствует. Персонал, участвующий в закупках, не принимает заметного участия в процессе разработки архитектуры | Декларируется следование процедурам и стандартам. Контроль заявок и фактических закупок на соответствие архитектуре неполный или отсутствует | Стратегия закупок определена и предусматривает соответствие стандартам архитектуры. Требования запросов на закупку формируются с учетом стандартов. Персонал, осуществляющий закупки, участвует в контроле за соблюдением стандартов | Все закупки планируются и управляются в соответствии с определенной архитектурой. Оценка предложений поставщиков интегрирована в процесс планирования архитектуры. Существуют процедуры по учету и утилизации устаревающих компонент ИС | Незапланированные закупки отсутствуют |
Аналогичная модель, правда, с разбиением уровня 1 на два – "начальный" и "отсутствующий", предложена Институтом разработок архитектуры предприятия (Institute for Enterprise Architecture Developments).
Интересное распределение организаций из группы Global 2000 по степени зрелости архитектуры приведено, по данным, в таблице 9.8.
| Таблица 9.8. Распределение организаций из списка Global 2000 по степени зрелости архитектуры | ||
| Уровень | 2007 (прогноз) | |
| 30% | 15% | |
| 45% | 40% | |
| 20% | 35% | |
| <5% | 10% | |
| нет | <1% |