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

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

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

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

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

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

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

Этап 3 включает в себя следующие два шага:

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

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

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

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

1. обоснование необходимости проекта и факторов, влияющих на разработку архитектуры: Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение проектов, снижения стоимости технической поддержки, приобретения новых активов или экономии за счет более простой адаптируемости системы, построенной на базе единой архитектуры, к изменению требований бизнеса. ROI как показатель возврата от инвестиций не всегда выступает в пользу разработки архитектуры. Возможной стратегической альтернативой является величина "Возврата на основные фонды" (ROA – Return on Assets), которая будет стимулировать компанию оценивать архитектуру ИТ с точки зрения повышения эффективности своих основных фондов.

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

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

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

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

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

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

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

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

Вообще говоря, наиболее общими подходами обеспечения управления и контроля архитектуры являются следующие:

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

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

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

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