Этап 3: Разработка Плана реализации

Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей

Этап 1: Разработка Общего видения архитектуры

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

Основными элементами Общего видения являются:

· описание технологических тенденций, важных для предприятия;

· идентификация бизнес-требований и стратегий;

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

· идентификация требований к архитектуре предприятия в целом.

На этом этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей.

Мы уже отмечали, что описание архитектуры как минимум включает модели таких областей, как Бизнес-архитектура, Архитектура информации, Архитектура прикладных систем и Технологическая архитектура. Необходимо определить те предметные области, архитектура которых предполагает первоочередную разработку на первой итерации процесса.

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

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

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

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

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

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

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

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

В общем виде можно сказать, что существуют два принципиально различных подхода в разработке архитектуры предприятия [6.6]:

· Подход "сверху-вниз" предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры "как есть". Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF).

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

Таблица 10.1. Положительные и отрицательные аспекты различных подходов к разработке Архитектуры предприятия
	Положительные аспекты	Отрицательные аспекты
Сверху-вниз	· С самого начала создается ясное видение существующей ситуации в целом · С самого начала сформулированы бизнес-потребности и проблемы · С самого начала задаются широкие рамки процесса с необходимой поддержкой высшего руководства	· Процесс может носить весьма абстрактный характер (выбор методик, типов моделей и пр.) · Маловероятно, что будут получены явные, видимые результаты в течение первого года работ · Может сложиться впечатление, что результатом проекта являются никому не нужные документы · Процесс сбора информации приводит к задержкам в построении структур управления архитектурным процессом · Использование формальных методологий требует обучения · Использование многих формальных методик требует наличия навыков и опыта в реинжиниринге бизнес-процессов
Снизу-вверх	· Программа разработки архитектуры быстро начинает давать видимые результаты · Быстрый успех повышает авторитет и доверие к процессу · Самые "горячие", приоритетные проблемы решаются в первую очередь · Масштаб и сложность проекта растет постепенно · Отсутствует необходимость иметь сразу большую команду, участвующую в процессе разработки архитектуры · Ориентация на решение в первую очередь технологических задач соответствует ключевой области экспертизы ИТ-службы · Результирующая экономия затрат позволяет обосновать необходимость новых организационных структур и процессов, связанных с архитектурой	· Первоначальная техническая направленность проекта затрудняет его распространение на более широкие области, связанные с бизнесом · Основанный на внедрении технических стандартов подход создает структуры управления архитектурным процессом, нацеленные на контрольные, "полицейские" функции · Первоначальный технологический фокус воспринимается как игнорирование бизнес-аспектов · Некоторые области, требующие улучшений, должны "ждать" своей очереди (например, архитектура данных)

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

Как всегда, в каждом варианте есть свои плюсы и минусы, которые кратко просуммированы в табл. 10.1.

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