Работая с различными компаниями невозможно не обратить внимание, что процессы построены по разному в разных компаниях. В одной компании процессы идеальные или близки к идеальным, в другой же компании приходится ожидать достаточно продолжительное время реакции на запрос. В этой ситуации очень легко разделить компании на плохие и хорошие, но это очень просто, а что просто не всегда правильно. Уже обучаясь на архитектора решений и проводя исследование по метрики качества Maturity — Зрелость, я нашла описание очень простого и понятного подхода к классификации компаний в зависимости от процессов. Этим подходом я делюсь с вами в моем переводе статьи «What is Enterprise Architecture Maturity Model?» или «Что такое архитектурная модель зрелости компании?»

Характеристики уровней зрелости:

Уровень 5: Оптимизированный — фокус на улучшении процессов
Уровень 4: Управляемый — процессы измеряются и контролируются
Уровень 3: Установленный — процессы уровня организации, достаточно проактивные (проекты адаптируют свои процессы согласно стандартам организации)
Уровень 2: Повторяемый — процессы уровня проектов и реагирующие на изменения более гибко
Уровень 1: Начальный — процессы не предсказуемы, слабо контролируемы и инертны к изменениям

Организации, которые могут эффективно управлять своими изменениями, обычно более успешные, чем те, которые не могут. Многие организации знают, что им необходимо улучшить их процессы разработки, связанные с IT, чтобы успешно управлять изменениями, но не знают как. Такие организации либо тратят очень мало на улучшение процессов, потому что не уверены, как лучше всего действовать, или тратят много на ряд параллельных и несфокусированных усилий, без особого успеха или безрезультатно.

Оригинальная Модель Зрелости (Capability Maturity Model — CMMs)

В Software Engineering Institute (SEI) — – www.sei.cmu.edu operated by Carnegie Mellon University – была разработана первоначальная CMM модель в 1986 г., которой с тех пор широко пользуются и сегодня. Эта CMM предоставляет каркас для разработки моделей зрелости в широком диапазоне дисциплин.
Модели зрелости возможностей (CMM) решают подобную проблему, предоставляя эффективный и проверенный метод для организации для постепенно обретения контроля и улучшения процессов разработки, связанные с IT.

• Они описывают практики, которые любые организация может применить для улучшения своих процессов
• Они обеспечивают критерии, с помощью которых улучшения периодически измеряются
• Они представляют собой проверенную схему, в рамках которой осуществляются меры по улучшениям

Уровни Модели Зрелости

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

Уровень 0: архитектуры нету

Нет IT-архитектуры вообще и не о чем говорить.

Уровень 1: Начальная

Неформальная IT-архитектура, которая создается на ходу.

1. Процессы являются не системными и локализованными. Какие-то архитектурные процессы были сформулированы, но единого архитектурного подхода для технологий или бизнес-процессов не существует. Успех зависит от индивидуальных усилий.
2. Архитектурные подходы, документация и стандарты локальные или неформальные, созданные на основе различных без системных подходов.
3. Связь с бизнес-стратегиями или бизнес-драйверами минимальная или неявная
4. Руководство слабо осведомлено или вовлечено в архитектурные процессы
5. Согласование архитектурных процессов с функционирующей командой незначительно
6. Последняя версия документации функционирующих команд по IT-архитектуре находится в Интернете. Архитектурные процессы и возможные улучшения процессов слабо связаны друг с другом.
7. Вопросы информационной безопасности являются не системными и локализованными
8. Нет четкого управления архитектурными стандартами
9. Архитектурные процессы предприятия мало или совсем не коррелируются со стратегическим планированием и наймом персонала. Существующие стандарты соблюдаются слабо или не соблюдаются вообще.

Уровень 2: Повторяемый

Архитектурные процессы уже существуют, но слабо управляемые.

1. Базовый архитектурный процесс описан на основе OMB Circular A-130 и Руководства по архитектуре IT Министерства торговли (Department of Commerce IT Architecture Guidance). Этот архитектурный процесс распределяет четкие роли и обязанности.
2. Определены IT-видение, принципы, деловые связи, базовый уровень и целевая архитектура. Архитектурные стандарты используются, но нет обязательно связи с целевой архитектурой. Созданы техническая эталонная модель (TRM) и профиль стандартов.
3. Есть явная связь с бизнес-стратегиями
4. Менеджмент ознакомлен с архитектурными действиями
5. Обязанности распределены, и используются как основа ежедневных процессов
6. DoC и документация функционирующих команд периодически обновляются и используются для создания архитектурной документации
7. Архитектурный подход к безопасности распределяет четкие роли и обязанности
8. Управление несколькими архитектурными стандартами и следование существующим стандартам.
9. Мало или нет формального управления IT инвестициями и стратегией приобретений. Функционирующие команды показывают соблюдение существующих стандартов.

Уровень 3: Установленный

Определенная IT-архитектура, включая подробные письменные процедуры и TRM.

1. Архитектура четко определена и доведена до сведения IT-персонала и руководства предприятия с обязанностями IT-подразделения операционной системы. Процесс в значительной степени поддерживается и сопровождается
2. Анализ пробелов и планы миграции завершены. Полностью разработанный профиль TRM и стандартов. ИТ цели и методы определены
3. ИТ-архитектура интегрирована с планированием капитала и инвестиционным контролем
4. Команда высшего руководства знает и поддерживает процесс архитектуры предприятия. Управление активно поддерживает архитектурные стандарты
5. Большинство элементов операционных блоков демонстрируют принятие или активное участие в процессе ИТ-архитектуры
6. Документы по архитектуре регулярно обновляются на веб-странице DoC IT-архитектуры
7. Архитектура ИТ-безопасности Профиль стандартов полностью разработан и интегрирован с ИТ-архитектурой
8. Явное документированное управление большинством инвестиций в ИТ
9. Стратегия приобретения ИТ существует и включает меры по обеспечению соответствия ИТ-архитектуре предприятия. Экономические выгоды учитываются при определении проектов

Уровень 4: Управляемый

Управляемые и измеряемые архитектурные процесс.

1. Архитектурный процесс является частью культуры. Фиксируются показатели качества, связанные с архитектурными процессами.
2. Документация по архитектуре регулярно обновляется, для отражения обновленной архитектуры. Бизнес, Данные, Приложения и Технологии Архитектуры определенны соответствующими де-юре и де-факто
3. Планирование капитала и контроль инвестиций регулируются на основе полученных отзывов и уроков, извлеченных из обновленной архитектуры. Периодическая повторная проверка бизнес-драйверов
4. Команда высшего руководства непосредственно вовлечена в процесс анализа архитектуры
5. Вся функционирующая команда активно принимает участие и оценивает архитектурные процессы
6. Архитектурная документация регулярно обновляются и часто проверяется на соответствие последним разработкам/стандартам в архитектуре
7. Фиксируются показатели производительности, связанные с архитектурой безопасности.
8. Прозрачное управление всеми инвестициями в ИТ. Сформированы процессы для управления обратной связью
9. Все запланированные приобретения и покупки ИТ-систем регулируются и управляются утановленными архитектурными стандартами

Уровень 5: Оптимизированный

Постоянное совершенствование архитектурного процесса.

1. Согласованные усилия по оптимизации и постоянному улучшению архитектурного процесса
2. Стандарты и процессы обработки отклонений от принятых подходов используются для улучшения и переработки архитектуры
3. Метрики архитектурных процессов используются для оптимизации и развития деловых связей. Бизнес вовлечен в непрерывный процесс совершенствования архитектуры
4. Высшее руководство вовлечено в оптимизацию процессов улучшения архитектуры и управления архитектурой
5. Обратная связь по архитектурным процессам от всех функционирующих команд используется для управления улучшениями архитектурных процессов
6. Архитектурная документация используются каждым человеком, принимающим решения в организации, для каждого IT бизнес-решения
7. Обратная связь от метрик архитектуры безопасности используется для улучшения процессов архитектуры
8. Прозрачное управление всеми инвестициями в ИТ. Постоянное улучшение процесса управления
9. Отсутствие незапланированных инвестиций или приобретение активов

Заключение

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

PS. От меня

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