Методика meta group кратко

Обновлено: 17.06.2024

В 2005 году ее поглотила компания Gartner — исследовательская и консалтинговая компания, специализирующаяся на рынках информационных технологий.

Процесс управления корпоративными ИТ-программами , процесс выработки стратегии и планирования и проекта

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

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

Пример матрицы связей между бизнес- стратегией (потребностями бизнеса) и требованиями к информационным системам

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

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

•Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре.

•Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием.

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

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

•Шаблоны – второй уровень адаптируемости технологий. Позволяют разработчикам использовать одни и те же конфигурации технологий для решения похожих задач.

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

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

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

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

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

6. МЕТОДИКИ ОПИСАНИЯ АРХИТЕКТУР

6.1. Модели жизненного цикла информационной системы

Существующие модели ЖЦ:

Каскадная модель. Весь объем работ разбивается на этапы (рис.18). Переход на следующий этап разработки только после окончания работ на предыдущем этапе. Этап заканчивается формированием полного комплекта документов [28].

Рис. 18. Каскадная модель разработки

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

Спиральнаямодель. Основное внимание направлено на начальные этапы ЖЦ: анализ требований к системе, спецификации, предварительное проектирование (рис.19). Технические решения, создаваемые на этих этапах, проверяются. Уточняются цели и характеристики проекта, уточняются детали. Каждый виток спирали создает свою версию системы. Далее работа уточняется, углубляются и поэтапно конкретизируются детали проекта. В итоге выбирается наиболее приемлемый вариант системы, который доводится до реализации [28].

Рис. 19. Спиральная модель жизненного цикла системы

6.2. Модель Захмана
IT-архитектура компании –единое описание важнейших направлений организации, которые имеют связь с информационной средой, прикладными системами и технологиями, при этом учитывается вoздействие на основные функции и процессы компании [14].
ИсследованиеIT-архитектуры компании несет в себе составляющие, связанные с мнoгoфункциональной архитектурой, IT-технологиями и управлением. IT-структура компании– целостное описание главных стратегий и целей организации, связанных с технологиями, прикладными системами и информацией. И с воздействием их на бизнес-функции и бизнес-процессы организации [6].
Рассмотрение IT-архитектуры компании производится в определенном контексте имеющихся в компании текстур управления и взаимодействия.
Есть разные модели и способы описания IT-архитектуры. Все эти способы задают классификацию главных областей и единичные взгляды для их описания. Существуют различные способы отображения примeняемых стереотипов, действий, моделей для oпределения разных частей IT-архитектуры, например [7]:

методики аналитических компаний: Gartner, Giga, META и др.;
модель Захмана;
методика TOGAF;
методика POSIX 1003.23i и др.

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

высокая степень детализации для практического применения специалистами в сфере IT при исследовании новейших систем;
простоту для осмысления не специализированной целевой группы;
динамику рассмотрения, т.е. переход от "Архитектуры как есть" к "Задачам архитектуры на заданные промежутки времени", к "Стратегическим планам";
адаптация к новым условиям бизнеса и возможность реализации новых планов.

Для правильного описания IT-архитектуры организации могут применять разные форматы. Принципиально, чтоб организация употребляла такой формат описания, который бы давал простой для понимания метод руководства по развитию всех качеств IТ в компании [35].
Почти все термины IT-архитектуры считаются произошедшими от единых понятий, относящихся к архитектуре компании в целом. Поэтому для описания и прогнозирования IT-архитектуры используются инструментальные и методологические средства моделирования, созданные для наиболее обобщенных задач.
Схема Захмана [4, 11] основывается на предмете традиционной архитектуры и формирует единый словарь и набор возможностей или структур для описания основных усложненных корпоративных систем. В собственном труде Дж. Захман обозначил архитектуру компании как "набор описательных моделей, применимых для описания предприятия в соответствии с требованиями управленческого персонала, которые могут развиваться в течение определенного периода". Понятие "архитектура" не случайно, оно выделяет существующую аналогию между внутренней текстурой теоретического объекта – компанией, и сложным искусственным объектом, таким, как башня либо аэродром.
Модель архитектуры, которую предложил Захман, преследует две главные цели [4, 11]:
- с одной стороны, упорядочить описание архитектуры, разбив ее на отдельные сегменты для лучшего восприятия и возможности анализа;
-с другой – иметь возможность рассмотрения всей архитектуры с интересующих точек.
До этого широко употребляемым подходом при описании системы использовалось понятие жизненного цикла системы, которое содержало рассмотрение таких этапов, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов анализируются и основные функции системы, и данные.
Ученый внес предложение вместо стандартного подхода, опирающегося на рассмотрение отдельных аспектов работы системы как бы в разные факторы времени, рассматривать системы с разных точек зрения [4, 11].
Первоначально модель Захмана была оформлена конкретно для IT-систем. Данный подход в следующем труде ученого был обобщен для рассмотрения и для описания компании в целом. Поэтому можно считать рассматриваемую модель пригодной для описания архитектур производственных систем различной сложности, вне зависимости от типа.
Главная мысль заключается в том, чтобы обеспечить возможность поочередного описания каждого отдельного аспекта системы в связи со всеми остальными. Связать характеристики системы с задачами в области бизнеса. В основе лежит то правило, что ни одна система не достигает цели функционирования в области бизнеса без использования какой-либо пригодной для этих целей системы. А информационная система состоит из процессов, которые выполняют люди, и процессов, которые выполняют компьютеры.
Модель предприятия задается в виде матрицы (рис. 20). Фактически модель изображается в виде таблицы, имеющей 5 строчек и 6 столбцов. Именно модель, которая соответствует уровню описания архитектуры, содержит точно 5 строк. Строки отражают категории специалистов, которые участвуют в деятельности предприятия. Столбцы отражают основные аспекты производственной деятельности. Шестая строка в данной модели соответствует уровню работающей системы.
Две верхние строчки отображают наиболее общие представления и довольно обширно поясняют имеющееся окружение, намерения и цели. Если провести аналогию со строительством, то данные значения несут в себе сведения о местоположении и функции возведенного сооружения, а также намерения и изображения, которые конструктор обговаривает с владельцем строящегося здания. Следующий этап "логической модели" считается наиболее определенным, однако всё ещё довольно отвлеченным. Наверное, это схемы, которые архитектор этого здания обязан демонстрировать поставщикам и заказчикам.

Рис. 20. Модель Захмана

На любом из уровней участники разработки архитектуры рассматривают одни и те же вопросы, соответствующие столбцам таблицы. Ответы на эти вопросы будут соответствовать их компетенциям и отличаться уровнем абстракции и детализации. Колонки озаглавлены так [4, 11]:

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

Основные правила при заполнении таблицы:

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

Участники могут фокусировать свое внимание на различных деталях, рассматривать разные вопросы, но в итоге должно сформироваться общее видение архитектуры, отражающее реальную картину. Проектировщик должен понимать точку зрения заказчика и наоборот. Строки представляют разные точки зрения.
Предложенная модель архитектуры является простым, однако очень значимым инструментом для организации и планирования работ по созданию и применению информационных систем, основанным на системном подходе. Модель архитектуры дает концентрацию на частных аспектах системы и в то же время не утрачивает чувство всеобщего контекста, т.е. взгляда на компанию в целом.
Диаграмма на рис. 21 иллюстрирует несколько методов моделирования [31]. Пересечение методов используется для формирования матрицы Захмана.
В табл. 6 приведено, какие модели на каких стадиях описания систем рекомендуется использовать.

Рис. 21. Методы моделирования
Таблица 6
Модели развития систем

Одна из наиболее интересных методик описания архитектуры предприятия была представлена компанией META Group в документе Enterprise Architecture Desk Reference в 2002 году. В силу своей простоты данная методика послужила основой различным аналитическим компаниям для разработки собственных уникальных архитектурных концепций.

В настоящий момент компания META Group куплена компанией Gartner, а названная методика описания архитектуры предприятия, в свою очередь, была заложена в основу Gartner Enterprise Architecture Framework.

Под архитектурой предприятия в методике META Group понимается структурированное описание информационных технологий предприятия и поддерживаемые ими бизнес-процессы.

Аналитики META Group традиционно рассматривают архитектуру информационных технологий, как элемент ключевых процессов управления всего предприятия (Рисунок 2.8).

Рисунок 2.8. Ключевые процессы управления
Первый уровень в иерархии ключевых процессов управления занимает процесс выработки стратегии и планирования (Strategy and Planning), обеспечивающий выработку стратегических целей и задач в рамках всего предприятия. Разработка ИТ стратегии является частным случаем данного процесса.

Второй уровень занимают процессы управления корпоративными проектами и архитектура предприятия. Считается, что архитектура предприятия реализуется на практике через процесс управления корпоративными проектами.

Enterprise Business Architecture (EBA) – бизнес-архитектура, описывающая бизнес - цели и бизнес - драйверы предприятия, бизнес-процессы и организационную структуру, каналы взаимодействия и продаж.
Enterprise Information Architecture (EIA) – информационная архитектура, описывает информационные потоки данных и сервисы.
Enterprise Solution Architecture (ESA) – архитектура приложений, описывает приложения, имеющиеся в компании, их компоненты и интерфейсы.
Enterprise Technical Architecture (ETA) – техническая архитектура, описывает компоненты инфраструктуры, технологические системы. Данный слой также включает в себя ИТ стандарты.

Рисунок 3.9. META Group Framework
Видение общих требований (CRV - Common requirements Vision) и принципы концептуальной архитектуры (CA – Conceptual Architecture) являются объединяющим элементом для всех четырех слоев архитектуры предприятия.

Разработка общих требований (CRV) и концептуальной архитектуры (CA) является первым шагом в процессе построения архитектуры предприятия. Жизненный цикл архитектурного процесса развивается по спирали, а эти два документа являются стержнем, вокруг которого строится архитектура предприятия (Рисунок 2.10).

Рисунок 2.10. Жизненный цикл архитектуры предприятия
Аналитики META Group используя классический подход к жизненному циклу, выделяют текущее состояние архитектуры (as-is) и будущее состояние архитектуры (future state). Переход из текущего состояния в будущее осуществляется за счет реализации проектов (Рисунок). Каждый новый проект вносит изменения в один или несколько слоев архитектуры (EBA, EIA, ESA, ETA), и, таким образом, жизненный цикл архитектуры предприятия переходит на свой очередной, новый, виток развития.

Особое внимание в методике Meta Group уделяется процессу разработки архитектуры предприятия и его интеграции с другими ключевыми процессами управления предприятием (Рисунок 2.11).

Фаза 1. Инициирование процесса разработки архитектуры (Organize Architecture Effort) включает в себя оценку заинтересованных в данном процессе лиц, подготовку и обучение команды проекта.

Фаза 2. Разработка целевой архитектуры (Target Architecture) описывает желаемое будущее состояние предприятия или "что должно быть сформировано" на основе требований бизнеса и тенденций (как технологических, так и экономических) в отрасли.

Отличительной особенностью методики МЕТА является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих.

Архитектура реализуется на практике через процесс управления ИТ-программами и проектами.

Предусматривает совместное участие представителей безнес-подразделений и ИТ в выработке общего понимания набора требований.

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

1. Видение общих требований в архитектуре.

2. Разработка концепции архитектуры.

3. Архитектурное моделирование.

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

Методика togaf.

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

В модели TOGAF архитектура предприятия подразделяется на четыре категории.

1. Архитектура бизнеса – описывает процессы, используемые для достижения бизнес-целей.

2. Архитектура приложений – описывает структуру конкретных приложений и их взаимодействие друг с другом.

3. Архитектура данных – описывает структуру корпоративных хранилищ данных

и процедуры доступа к ним.

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

Анализ и выбор инструментальных средств моделирования архитектуры предприятия.

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

Enterprise Architecture Tools должны включать в себя следующие компоненты: репозиторий (repository), обеспечивающий структурированное хранение всех данных, описывающих состояние компании; метамодель (metamodel), которая поддерживает возможность описания всех слоев архитектуры предприятия (бизнес, информация, приложения, технологии) и обеспечивает связи между всеми объектами; возможность создавать и импортировать модели; возможность извлекать информацию из репозитория и предоставлять ее пользователям, как в текстовом, так и в графическом виде.

BPA (Business Process Analyze)- это набор инструментов, ориентированный на моделирование и управление бизнес-процессами. При описании приложений этой группы часто используют термин BPMS (Business Process Management System) или BPM-система. BPA Tools (BPMS) позволяют не только моделировать бизнес-процессы, но и проводить мониторинг их количественных параметров, что позволяет выявлять узкие места и оптимизировать бизнес-процессы. BPA Tools ориентированы на анализ, моделирование, оптимизацию конкретных бизнес-процессов.

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

Metadata Repositories– это хранилище информации о текущей структуре предприятия. Подобные хранилища данных включают в себя информацию о бизнес- процессах, приложениях, интерфейсах, программно-аппаратных средствах. Информация, хранящаяся в такой базе данных, собирается из различного количества источников и, как правило, частично совпадает с информацией, находящейся в CMDB (configuration management databases).

Хранилище информации, как правило, не существует само по себе и является элементом инструментов, ориентированных на использование Business Process Analyze или Enterprise Architecture tools.

Database and Data Design Tools- набор инструментов, ориентированный на разработку моделей, описывающих информационную архитектуру предприятия. Инструменты этой группы включают в себя возможность визуального представления информации и редакторы для физического и логического описания модели данных.

OOA&D(Object-Oriented Analysis and Design) - это набор инструментов для объектно-ориентированного анализа и проектирования. Используются для анализа предметной области и проектирования информационных систем с использованием объектно-ориентированного подхода.

Современные приложения, использующиеся для объектно-ориентированного анализа, должны интегрироваться с инструментами моделирования бизнес-процессов (BPA Tools) и системами проектирования баз данных.

Наиболее интересный вариант классификации программных продуктов, использующихся для разработки моделей, предложен аналитиками IFEAD, которые выделяют следующие направления: Software Engineering (Разработка программного обеспечения), Service Oriented Architecture (Сервис ориентированная архитектура), Enterprise Architecture (Архитектура предприятия), Business / IT strategy (Бизнес / ИТ стратегия), Enterprise / IT portfolio (Предприятие / ИТ портфель), Program Management (Управление программами), Governance, Risk, Compliancy (Управление, риски, соответствие условиям).

В качестве лидеров аналитиками выделяются следующие компании: IBM (купившая в апреле 2008 года компанию Telelogic), Troux Technologies (с их малоизвестным в России программным продуктом Metis), IDS Scheer (с их линейкой ARIS Solution для управления архитектурой предприятия).

Читайте также: