Методика META Group

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

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

Исторически архитектурная методика META Group оперировала таким понятием, как Технологическая архитектура масштаба предприятия (EWTA – Enterprisewide Technical Architecture).

Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) архитектуры предприятия META Group были добавлены следующие домены:

- Бизнес-архитектура (EBA – Enterprise Business Architecture),

- Архитектура информации (EAI – Enterprise Information Architecture),

- Портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio).

Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.

Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).

Рис. 4. Аналитическая работа и компоненты Архитектуры предприятия META Group

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

На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:

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

· бизнес-стратегии и основные движущие силы с точки зрения бизнеса;

· требования к информационным системам со стороны бизнеса;

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

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

Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры.

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

Рекомендация относительно Видения общих требований состоит в том, что этот документ не должен обязательно быть исключительно точным и всеобъемлющим с точки зрения анализа бизнес-стратегии. Главное – это совместное участие представителей бизнес-подразделений и ИТ в выработке общего понимания набора требований, согласованных со стратегическим направлением развития компании. Размер этого документа может быть 10-15 страниц. Основное содержание документа может состоять из четких утверждений, которые тематически связаны между собой, например, так, как показано в таблице 1.

Таблица 1. Пример компоненты Видения общих требований

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

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

Таким образом, результатом первого этапа работ могут быть четыре документа:

· список ключевых технологических тенденций;

· список бизнес-стратегий;

· список требований к информационным системам;

· список требований к технологической архитектуре.

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

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

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

· принципы являются ограниченным числом точек стабильности, на которых строится архитектура;

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

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

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

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

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

· Формулировка миссии домена: стратегические цели домена.

· Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.

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

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

· Лучшие практики.

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

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