ПОЗНАВАТЕЛЬНОЕ

Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.

Отёска стен и прирубка косяков - Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Семь шагов архитектурного процесса в соответствии с методикой Спивака

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

1. Цели и задачи

2. Семь шагов архитектурного процесса в соответствии с методикой Спивака

· Общая схема архитектурного процесса

· Модель процесса разработки и использования архитектуры

· Направления разработки архитектуры: "сверху-вниз" или "снизу-вверх"

· Архитектура предприятия как планирование города

3. С чего начать?

· Обоснование необходимости проекта разработки архитектуры и факторы влияния

· Формирование команды проекта

· Определение границ архитектуры и используемых методик

Цели и задачи

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

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

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

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

организация необходимых структур с привлечением руководства предприятия, бизнес-подразделений и планирование работ;

понимание стратегии развития бизнеса организации;

формирование общих для бизнеса и ИТ требований к целевой архитектуре;

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

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

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

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

Определение и обоснование цели – ответы на вопросы Почему? и Что?

Выполнение ряда шагов, связанных с инициацией процесса разработки архитектуры (см. ниже).

Определение существующего состояния архитектуры ( "as is") для каждой выбранной области (домена) – отправная точка ответа на вопрос Где?

Определение целевой архитектуры – конечная точка ответа на вопрос Где?

Анализ расхождений между текущим и желаемым состоянием.

Разработка плана перехода – ответы на вопросы Когда? и Как?

Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений?

Выполнение намеченного плана.

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

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

определение "устава" (основных правил) и границ проекта;

бизнес-обоснование реализации проекта разработки архитектуры предприятия;

получение поддержки высшего руководства;

определение состава рабочей группы (организационная структура и участники);

проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры;

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

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

бизнес-факторы, влияющие на деятельность предприятия;

внутренние и внешние технологические факторы;

формулировку общего видения архитектуры предприятия;

высокоуровневые принципы.

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

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

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

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

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

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

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

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

Семь шагов архитектурного процесса в соответствии с методикой Спивака

Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования архитектуры предприятия, которая называется EAP (Entrerprise Architecture Planning – Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архитектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции) [6.4]. Эти 7 компонент, условно изображенных на рис. 2 в виде "свадебного торта", обозначают смещение фокуса приложения сил на каждом из шагов.

Рис. 2. Методика EAP планирования Архитектуры предприятия

Подход Спивака уже помог очень многим компаниям и государственным ведомствам в организации процесса моделирования, стратегического бизнес-планирования, реорганизации деловых процессов, проектировании различных систем, выработки стандартов на данные, управления проектами. В частности, этой методикой пользовались такие организации, как Federal Express, Министерство энергетики США, Штаб Военно-воздушных сил США и другие. Например, в Министерстве энергетики США основная фаза процесса разработки архитектуры ("проект") заняла примерно 6 месяцев.

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

в основе – потребности бизнеса, а не технологические факторы;

основное внимание сосредоточено более на данных и потребностях в информации, чем на процессах;

ответственность за процесс в большей степени несут представители бизнес-подразделений, чем специалисты по ИТ.

Если "наложить" методику EAP Спивака на модель архитектуры Захмана, то можно сказать, что методика EAP является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. это перспективы, соответствующие представлениям об архитектуре бизнес-руководителей: "планировщика" и "владельца". Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками методики Спивака.

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