10.: Процесс разработки архитектур: цели и задачи, общая схема
Не надо питать иллюзий насчет того, что работа архитектора заканчивается строительством видения великолепной архитектуры предприятия. Архитектура информационных технологий – это только на 10% видение, а на 90% – кропотливая работа по реализации.
Реализация архитектуры предприятия не является проектом в строгом смысле этого слова. Дело в том, что за фазой разработки неизбежно должна последовать деятельность по поддержанию и постоянному развитию архитектуры предприятия, а это более удобно описывать в рамках процессной модели. Однако на практике часто встречаются следующие два случая, когда целесообразно организовать выполнение специального архитектурного проекта.
Мы уже отмечали, что с учетом существующего реального состояния дел большинство организаций либо не имеют формализованной определенной архитектуры, либо эти определения неполны и недостаточно четко связаны с требованиями бизнеса. В таких случаях имеет смысл организовать работу в рамках специального проекта с определенными сроками и результатами, основной целью которого будет являться создание первоначального описания архитектуры организации и создание механизмов для ее последующего поддержания и развития.
Первоочередными задачами такого проекта являются:
организация необходимых структур с привлечением руководства предприятия, бизнес-подразделений и планирование работ;
понимание стратегии развития бизнеса организации;
формирование общих для бизнеса и ИТ требований к целевой архитектуре;
разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разработка архитектуры отдельных доменов (предметных областей или частных архитектур).
Для многих организаций отправной точкой в создании общей архитектуры предприятия может стать существующая ИТ-архитектура.
Другим возможным вариантом выделения такой деятельности в отдельный проект может явиться потребность в проведении эволюционного скачка в архитектуре. Например, открытие нового бизнес-направления или внедрение новой ERP-системы потребует значительных изменений в вычислительной и сетевой инфраструктуре, реорганизации ИТ-службы и т.п. Возможностей существующей группы поддержки архитектурного процесса окажется недостаточно для решения таких задач, и потребуется привлечение дополнительных внутренних и внешних ресурсов, что опять-таки удобнее выполнять в рамках четко определенного проекта.
Какую бы архитектурную методику вы ни выбрали, при всех расхождениях в деталях проект работы над созданием архитектуры обычно включает решение следующих задач[6.2], [6.3]:
Определение и обоснование цели – ответы на вопросы Почему? и Что?
Выполнение ряда шагов, связанных с инициацией процесса разработки архитектуры (см. ниже).
Определение существующего состояния архитектуры ( "as is") для каждой выбранной области (домена) – отправная точка ответа на вопрос Где?
Определение целевой архитектуры – конечная точка ответа на вопрос Где?
Анализ расхождений между текущим и желаемым состоянием.
Разработка плана перехода – ответы на вопросы Когда? и Как?
Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений?
Выполнение намеченного плана.
Здесь стоит особенно отметить важность усилий для решения третьей задачи. С одной стороны, формирование целостного описания существующей архитектуры может потребовать проведения настоящих "археологических раскопок" в ранее существовавшей документации, изучения существующих преданий и посвящения в "тайные знания" о годами работающих системах. С другой стороны, здесь важно определить набор целевых метрик (надежность, стоимость эксплуатации и т.п.) и их начальных значений – иначе потом будет очень трудно объективно оценить, достигнуты ли цели проекта.
Начальные действия по инициации самого проекта разработки архитектуры включают следующие шаги:
определение "устава" (основных правил) и границ проекта;
бизнес-обоснование реализации проекта разработки архитектуры предприятия;
получение поддержки высшего руководства;
определение состава рабочей группы (организационная структура и участники);
проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры;
создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитектура, архитектура информации, прикладных систем, инфраструктуры).
Высокоуровневые документы, которые должны быть результатом первоочередных шагов, являются ключевыми для дальнейшей, более детальной проработки архитектуры. Они создают некоторый культурный контекст всех усилий и обеспечивают связь работы по созданию архитектуры с бизнес-стратегиями и приоритетами предприятия. Список этих высокоуровневых документов может включать:
бизнес-факторы, влияющие на деятельность предприятия;
внутренние и внешние технологические факторы;
формулировку общего видения архитектуры предприятия;
высокоуровневые принципы.
Важной составляющей всего проекта является создание структур управления и контроля архитектурного процесса (governance), который должен обеспечить то, что сообщество специалистов на практике использует результаты этих работ; вторая серьезная задача – обеспечение связей процесса разработки архитектуры с процессами бизнес-планирования и выработки ИТ-стратегии.
Общая блок-схема процесса в итоге выглядит, как показано на рис. 10.1.
В принципе, существуют три возможных подхода к организации процесса разработки архитектуры:
Традиционный обычный подход. Он требует существенных начальных затрат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архитектура. Лишь когда все эти действия закончены, начинается детальное проектирование и разработка необходимой архитектуры предприятия.
Сегментный подход. Суть этого подхода состоит в постепенной поступательной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами общих выполняемых функций, а также сфер специфической деятельности предприятия.
Подход статус-кво или "оставить все как есть". Но, как мы уже говорили, результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнес-функций, снижение производительности, потерянные или упущенные возможности.
Рис. 10.1. Основные элементы архитектурного процесса
Традиционный, обычный подход при всей кажущейся его правильности связан с риском "паралича анализа", который особенно неконструктивен в российских условиях переходной экономики и процессов реформирования государства. Чтобы сократить возможные риски неудач, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта разработки архитектуры ИТ, рекомендуется второй, т.е. сегментный подход.