Опубликован: 07.05.2007 | Уровень: специалист | Доступ: платный
Лекция 10:

Процесс разработки архитектур: цели и задачи, общая схема

Аннотация: Рассмотрены задачи проектирования архитектуры, этапы, основные элементы, общая схема процесса разработки архитектуры

Цели и задачи

Разница между видением и галлюцинацией состоит в том, что видение предполагает наличие надежного плана миграции, за которым следует отличное исполнение.

Клайтон Спранг [6.1]

Не надо питать иллюзий насчет того, что работа архитектора заканчивается строительством видения великолепной архитектуры предприятия. Архитектура информационных технологий – это только на 10% видение, а на 90% – кропотливая работа по реализации.

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

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

Первоочередными задачами такого проекта являются:

  • организация необходимых структур с привлечением руководства предприятия, бизнес-подразделений и планирование работ;
  • понимание стратегии развития бизнеса организации;
  • формирование общих для бизнеса и ИТ требований к целевой архитектуре;
  • разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разработка архитектуры отдельных доменов (предметных областей или частных архитектур).

Для многих организаций отправной точкой в создании общей архитектуры предприятия может стать существующая ИТ-архитектура.

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

Какую бы архитектурную методику вы ни выбрали, при всех расхождениях в деталях проект работы над созданием архитектуры обычно включает решение следующих задач [6.2], [6.3]:

  1. Определение и обоснование цели – ответы на вопросы Почему? и Что?
  2. Выполнение ряда шагов, связанных с инициацией процесса разработки архитектуры (см. ниже).
  3. Определение существующего состояния архитектуры ( "as is") для каждой выбранной области (домена) – отправная точка ответа на вопрос Где?
  4. Определение целевой архитектуры – конечная точка ответа на вопрос Где?
  5. Анализ расхождений между текущим и желаемым состоянием.
  6. Разработка плана перехода – ответы на вопросы Когда? и Как?
  7. Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений?
  8. Выполнение намеченного плана.

Здесь стоит особенно отметить важность усилий для решения третьей задачи. С одной стороны, формирование целостного описания существующей архитектуры может потребовать проведения настоящих "археологических раскопок" в ранее существовавшей документации, изучения существующих преданий и посвящения в "тайные знания" о годами работающих системах. С другой стороны, здесь важно определить набор целевых метрик (надежность, стоимость эксплуатации и т.п.) и их начальных значений – иначе потом будет очень трудно объективно оценить, достигнуты ли цели проекта.

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

  • определение "устава" (основных правил) и границ проекта;
  • бизнес-обоснование реализации проекта разработки архитектуры предприятия;
  • получение поддержки высшего руководства;
  • определение состава рабочей группы (организационная структура и участники);
  • проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры;
  • создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитектура, архитектура информации, прикладных систем, инфраструктуры).

Высокоуровневые документы, которые должны быть результатом первоочередных шагов, являются ключевыми для дальнейшей, более детальной проработки архитектуры. Они создают некоторый культурный контекст всех усилий и обеспечивают связь работы по созданию архитектуры с бизнес-стратегиями и приоритетами предприятия. Список этих высокоуровневых документов может включать:

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

Важной составляющей всего проекта является создание структур управления и контроля архитектурного процесса (governance), который должен обеспечить то, что сообщество специалистов на практике использует результаты этих работ; вторая серьезная задача – обеспечение связей процесса разработки архитектуры с процессами бизнес-планирования и выработки ИТ-стратегии.

Общая блок-схема процесса в итоге выглядит, как показано на рис. 10.1.

В принципе, существуют три возможных подхода к организации процесса разработки архитектуры:

  • Традиционный обычный подход. Он требует существенных начальных затрат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архитектура. Лишь когда все эти действия закончены, начинается детальное проектирование и разработка необходимой архитектуры предприятия.
  • Сегментный подход. Суть этого подхода состоит в постепенной поступательной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами общих выполняемых функций, а также сфер специфической деятельности предприятия.
  • Подход статус-кво или "оставить все как есть". Но, как мы уже говорили, результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнес-функций, снижение производительности, потерянные или упущенные возможности.
Основные элементы архитектурного процесса

Рис. 10.1. Основные элементы архитектурного процесса

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

Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Алексей Коврижкин
Алексей Коврижкин
Россия, Челябинск, ОУП ВПО Академия труда и социальных отношений