Методика META GroupПодробное описание методики разработки архитектуры предприятия META Group содержится в документе Enterprise Architecture Desk Reference объемом около 380 страниц, который предоставлялся клиентам компании. Остановимся на самых главных моментах этой безусловно интересной методики, доступных в открытых материалах. По мнению META Group, " архитектура является одновременно некоторым структурированным описанием информационных технологий предприятия и его информационных технологий (т.е. конечным результатом, включающим определенные артефакты- стандарты, утверждения, касающиеся общего видения, архитектурные документы), процессом создания и обновления артефактов архитектуры и группами людей, вовлеченных в этот процесс". Соответственно этим представлениям методика компании уделяет достаточно подробное внимание всем трем составляющим архитектуры. При этом отличительной особенностью методики META является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих. Исторически архитектурная методика META Group оперировала таким понятием, как Технологическая архитектура масштаба предприятия (EWTA – Enterprisewide Technical Architecture). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) архитектуры предприятия META Group были добавлены такие домены, как Бизнес-архитектура (EBA – Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и Портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio). Это соответствует эволюции понятия " Архитектура предприятия", которая происходила на рынке в целом (см. лекцию 3), и принятой сегодня практике выделения доменов архитектуры. Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами. Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Commonrequirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).
Рис. 8.5. Аналитическая работа и компоненты Архитектуры предприятия Организация рабочего процесса разработки архитектуры и быстрое создание начальной версии архитектуры предприятия, согласно META Group, состоит в прохождении следующих этапов. На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя: · анализ тенденций развития внешней для предприятия среды, включая технологические тенденции; · бизнес-стратегии и основные движущие силы с точки зрения бизнеса; · требования к информационным системам со стороны бизнеса; · требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса. Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состоянием архитектуры. Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры. При этом данная методика предлагает формализованные шаблоны, обеспечивающие разработку Видения общих требований и Концептуальной архитектуры. Рекомендация относительно Видения общих требований состоит в том, что этот документ не должен обязательно быть исключительно точным и всеобъемлющим с точки зрения анализа бизнес-стратегии. Главное – это совместное участие представителей бизнес-подразделений и ИТ в выработке общего понимания набора требований, согласованных со стратегическим направлением развития компании. Размер этого документа может быть 10-15 страниц. Основное содержание документа может состоять из четких утверждений, которые тематически связаны между собой, например, так, как показано в таблице 8.2.
Важный аспект заключается в документировании явных связей между бизнес-стратегией (потребностями бизнеса) и требованиями к информационным системам и, в конечном итоге, установления логических связей с требованиями к технологической архитектуре. Для этого рекомендуется использовать простые матрицы так, как это показано на рис. 8.6. Документированные связи послужат основой для будущих решений об инвестициях.
Рис. 8.6. Матрица связей между бизнес-стратегиями, требованиями к информационным системам и технологической архитектуре Таким образом, результатом первого этапа работ могут быть четыре документа: · список ключевых технологических тенденций; · список бизнес-стратегий; · список требований к информационным системам; · список требований к технологической архитектуре. Видение общих требований агрегирует все требования к технологической архитектуре, и это служит основой для формулировки принципов Концептуальной архитектуры. В свою очередь, эти принципы обеспечивают общие руководства в использовании, разработке различных информационных систем и инфраструктуры в различных технологических областях. Концептуальная архитектура разрабатывается еще до создания других архитектурных доменов и основана на принципах, которые имеют несколько общих характеристик: · принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры; · принципы являются ограниченным числом точек стабильности, на которых строится архитектура; · принципы должны быть утверждениями, чья справедливость для организации носит " вечный" характер, поскольку они задают систему ценностей для архитектуры в целом. Мы уже отмечали, что в соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, как отмечалось в лекции 7, можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированноеаппаратное обеспечение). Каждый домен технологической архитектуры включает описание принципов, технологий, стандартов, продуктов, конфигураций, лучших практик, которые являются многократно используемыми строительными блоками при построении ИТ-систем. На рисунке 8.7 приведена структура описания каждого домена технологической архитектуры предприятия, согласно META Group.
Рис. 8.7. Структура описания доменов технологической архитектуры Таким образом, документ, описывающий каждый домен технологической архитектуры, включает следующие компоненты: · Формулировка миссии домена: стратегические цели домена. · Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий. · Принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений в отношении технологий домена, а также обоснования и последствия принятия этих принципов. Здесь могут быть построены матрицы соответствия между требованиями к технологической архитектуре (RTA), сформулированные в процессе создания Видения общих требований, и принципов проектирования, принятых для конкретного домена. · Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре. Выделяют стратегические (предпочтительные) стандарты, переходные (которые используются временно), устаревшие (которые, возможно, еще используются, но от которых организация отказывается) и исследовательские или новые (которые находятся только на этапе рассмотрения и апробации). · Лучшие практики. · Конфигурации. Они формулируются в тех случаях, когда нужно уменьшить сложность принятия решений или когда можно уменьшить общую стоимость владения за счет стандартных конфигураций. · Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры. В ряде публикаций представления о технологической архитектуре META Group получили дальнейшее развитие и дополнены такими аспектами, как инфраструктурные шаблоны и инфраструктурные сервисы. Это связано с общей для индустрии ИТ тенденцией уделять большое внимание шаблонам проектирования, а также с развитием принципов сервис-ориентированной архитектуры (см. лекцию 7). Отмечается, что инфраструктурные шаблоны должны обеспечивать взаимодействие и интеграцию различных технологий, указывать область применимости шаблона для конкретного типа прикладной системы (транзакционные, публикация информации, совместная работа). Примерами таких инфраструктурных шаблонов являются шаблоны выполнения транзакций (одноуровневые, двухуровневые транзакции, трех- и n-уровневые транзакции), шаблоны публикации информации (публикация клиент/сервер, web-публикация, видео- и аудио-поток), шаблоны взаимодействия (взаимодействие в реальном времени, взаимодействие по схеме " запомнил–переслал", структурированное взаимодействие). Взгляд на технологическую архитектуру с точки зрения предоставляемых ею инфраструктурных сервисов обусловлен распространением принципов сервис-ориентированной архитектуры. Это связано с описанием, например, сервисов презентации информации (порталы, настольные системы и пр.), сетевыми сервисами (LAN, WAN, удаленный доступ), сервисами безопасности (управление пользователями, доступ), сервисами хранения данных (SAN – Storage Area Network, файловые системы), сервисами баз данных (OLTP), интеграционными сервисами, платформенными сервисами, которые используются прикладными системами. При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия: · Домены архитектуры – первый уровень адаптируемости технологий. Категоризация помогает предприятиям обнаруживать излишние технологии, продукты и конфигурации, а также позволяет идентифицировать возможности многократного использования элементов технологической архитектуры. · Шаблоны – второй уровень адаптируемости технологий. Позволяют разработчикам использовать одни и те же конфигурации технологий для решения похожих задач. · Сервисы – третий уровень адаптируемости технологий. Они обеспечивают общие интерфейсы для разработчиков прикладных систем и интеграторов приложений в рамках всей инфраструктуры предприятия. При этом выделяется четыре группы сервисов по мере повышения уровня абстракции: · Базовые инфраструктурные сервисы: общие, стандартные технологии, широко используемые в рамках всех ИТ-систем предприятия. Они ориентированы не на разработчиков прикладных систем, а на специалистов по инфраструктуре. Примерами являются ПО пересылки сообщений промежуточного слоя, мониторы транзакций, сервисы каталогов. · Общие (framework) инфраструктурные сервисы: общие, совместно используемые технологии, которые не содержат готовой бизнес-логики (хотя она и может быть запрограммирована), ориентированы на разработчиков и могут быть не полностью стандартизированы. Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил. · Общие (framework) бизнес-сервисы: могут быть использованы в рамках различных бизнес-процессов, поскольку они содержат готовую, предопределенную бизнес-логику. Примерами таких сервисов являются модули определения цены товара, модули персонализации информации, модули оценки кредитного рейтинга. · Прикладные бизнес-сервисы: специфические для отдельных бизнес-процессов, содержат высокоуровневую бизнес-логику. Например, сервисы CRM-систем или систем управления поставками. В результате получается технологическая модель предприятия, представленная на рис. 8.8.
Рис. 8.8. Технологическая модель предприятия В полном описании методики META Group приводятся также следующие аспекты: · практическая реализация архитектуры через процесс управления корпоративными ИТ-программами и проектами; · вопросы управления и контроля архитектурного процесса (governance); · оценка зрелости архитектуры; · анализ технологических тенденций и планирование; · управление портфелем ИТ-активов и проектов.
|
