Ведущие методологии построения архитектуры предприятия

 

Рис. 3. Иерархия описаний архитектур

 

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

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

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

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

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

 

Архитектура предприятия с точки зрения FEA

С точки зрения FEA, архитектура предприятия состоит из отдельных сегментов. Эта идея была впервые изложена в FEAF. Сегмент представляет собой один из основных аспектов бизнеса, например трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные.

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

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

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

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

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

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

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

Последнее примечание относительно сегментов. Хотя сегменты функционируют на политическом уровне (то есть на уровне агентств), они определяются на уровне предприятия (то есть на уровне правительства). Службы предприятия, естественно, функционируют и определяются на уровне предприятия.

Тот факт, что сегменты определяются глобально, упрощает их повторное использование в границах политико-административного деления. Можно спланировать использование сегментов в границах политико-административного деления предприятия, а затем воспользоваться этим планом для поиска возможностей повторного использования разработанной архитектуры. Например, на рис. 4 приведена схема сегментов федерального правительства из «Практического руководства по FEA». Из рисунка видно, что многие сегменты (вертикальные столбцы) используются во многих агентствах и все или почти все эти сегменты можно использовать повторно.

Рис. 4. Схема сегментов федерального правительства

 

Эталонные модели FEA

Все пять эталонных моделей FEA предназначены для формирования единого языка. Цель - упростить взаимодействие, сотрудничество и совместную работу, минуя границы политико-административного деления. Согласно заявлению управления по реализации программы FEA (FEAPMO):

«Методология FEA включает в себя набор взаимосвязанных "эталонных моделей", предназначенных для упрощения анализа деятельности агентств и выявления дублирующих инвестиций, несоответствий и возможностей для совместной работы внутри агентств и между ними. Совместно эталонные модели [образуют] структуру для единообразного описания важных элементов методологии FEA».

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

Эталонная модель компонентов (CRM) дает ИТ-представление систем, поддерживающих бизнес. Например, в эталонной модели компонентов определяется аналитическая система, упомянутая выше в гипотетическом описании взаимодействия между Налоговым управлением и Управлением правительственной печати.

В Технической эталонной модели (TRM) определяются различные технологии и стандарты, используемые при построении ИТ-систем. Например, в этой модели HTTP определяется как протокол, который является подмножеством служебного транспорта, который, в свою очередь, является подмножеством служебного доступа и доставки.

В эталонной модели данных (DRM) определяются стандартные способы описания данных. Например, сущность в этой модели определяется как нечто, обладающее атрибутами и участвующее в отношениях.

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

 

Процесс FEA

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

• Этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации.

• Этап 2. Архитектурное определение: задание желаемого состояния сегмента, документация целевых показателей производительности, рассмотрение альтернатив и разработка архитектуры предприятия для сегмента, в том числе архитектуры бизнеса, архитектуры данных, архитектуры служб и технологической архитектуры.

• Этап 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта.

• Этап 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контрольные точки и показатели производительности для оценки успешности проекта.

Оценка успешности в методологии FEA

Структура FEA для оценки успеха в использовании архитектуры предприятия описана в документе «Структура оценки архитектуры предприятия по программе FEA 2.1». Уровень готовности федеральных агентств оценивается по трем категориям:

1. Завершенность архитектуры - уровень готовности собственно архитектуры
2. Использование архитектуры - эффективность использования агентством архитектуры при принятии решений
3. Результаты использования архитектуры - преимущества, достигнутые благодаря использованию архитектуры

 

Структура и модель описания ИТ-архитектуры Gartner

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

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

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

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

Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями.

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

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

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