Архитектура ландшафт: Ландшафтная архитектура. Большая российская энциклопедия

37.1 Обзор

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

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

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

• Метамодель архитектуры описывает организационно адаптированное приложение архитектурной структуры, включая метод разработки архитектуры и метамодель содержания архитектуры
• Возможности архитектуры определяют параметры, структуры и процессы, поддерживающие управление Репозиторий архитектуры
• Архитектурный ландшафт представляет собой архитектурное представление активов, используемых или планируемых предприятием в определенные моменты времени
• Информационная база стандартов фиксирует стандарты, которым должны соответствовать новые архитектуры, которые могут включать отраслевые стандарты, отдельные продукты и услуги от поставщиков или общие услуги, уже развернутые в организации
• Справочная библиотека содержит рекомендации, шаблоны, шаблоны и другие формы справочных материалов, которые можно используется для ускорения создания новых архитектур для предприятия
• Журнал управления содержит записи о деятельности по управлению на предприятии
• Репозиторий требований к архитектуре предоставляет обзор всех авторизованных требований к архитектуре, которые были согласовано с Архитектурным советом
• Ландшафт решений представляет собой архитектурное представление строительных блоков решений (SBB), поддерживающих Архитектура Ландшафт, который был запланирован или развернут предприятием

Отношения между этими областями репозитория архитектуры показаны на рис. 37-1.

В следующих разделах описывается структура и содержимое областей репозитория.

37.2 Архитектура Пейзаж

Архитектурный ландшафт содержит архитектурные представления о состоянии предприятия в определенные моменты времени. Из-за Благодаря объему и разнообразным потребностям заинтересованных сторон на всем предприятии архитектурный ландшафт разделен на три уровни детализации:

1. Стратегические архитектуры (см. Часть I, 3.74 Стратегические Архитектура ) показывают долгосрочное сводное представление всего предприятия. Стратегические архитектуры обеспечивают организацию основу для операционной деятельности и деятельности по внесению изменений, а также позволяют задавать направления на исполнительном уровне.
2. Сегментные архитектуры (см. Часть I, 3.64 Сегмент Архитектура ) предоставляют более подробные операционные модели для областей внутри предприятия. Сегментные архитектуры могут использоваться в на уровне программы или портфеля для организации и оперативного согласования более детальной деятельности по внесению изменений.
3. Архитектуры возможностей (см. Часть I, 3.31 Возможности Архитектура ) более подробно показать, как предприятие может поддерживать конкретную единицу возможностей. Возможности Архитектуры используются для предоставления обзора текущих возможностей, целевых возможностей и приращений возможностей и позволяют отдельные рабочие пакеты и проекты должны быть сгруппированы в рамках управляемых портфелей и программ.

37.3 Справочная библиотека

37.3.1 Обзор

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

• Корпуса стандартов
• Поставщики товаров и услуг
• Отраслевые сообщества или форумы
• Стандартные шаблоны
• Передовая практика предприятия

Справочная библиотека должна содержать:

• Эталонные архитектуры
• Эталонные модели
• Библиотека точек обзора
• Шаблоны

Примечание:

Термины эталонная архитектура и эталонная модель не используются в большей части литературы. Ссылка архитектура и эталонная модель имеют такие же отношения, как архитектура и модель. Любой из них может существовать либо как общий, либо как специфическое для организации состояние. Как правило, общая эталонная архитектура предоставляет архитектурной группе краткое описание их эталонная архитектура для конкретной организации, которая будет настроена для конкретной организации. Например, общая ссылка архитектура может определить, что есть потребность в моделях данных. Примером эталонной архитектуры является справочник IT4IT. Архитектура, которая также определяет общую информационную модель для управления ИТ. Другим примером является TM Forum eTOM и SID в качестве специфическая для организации эталонная архитектура.

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

Континуум архитектуры, показанный на рис. 37-2, можно рассматривать как справочную библиотеку. классификационная схема. Таким образом, он иллюстрирует, как эталонные архитектуры могут быть организованы в различных диапазонах — от Foundation Архитектуры и отраслевые архитектуры к архитектуре, специфичной для организации.

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

В этом упражнении важно помнить об уровнях и разделах. На разных уровнях детализации могут существовать справочные материалы, соответствующие уровню, и можно ожидать, что разделы в архитектурном ландшафте будут использовать другой справочный материал (см. 36. Разделение архитектуры и часть III, 19. Применение ADM в архитектурном ландшафте ).

37.4 Информационная база стандартов

37.

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

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

37.4.2 Типы стандарта

обычно делятся на три класса:

• Юридические и нормативные обязательства : эти стандарты предусмотрены законом, и поэтому предприятие должно соблюдать их или столкнуться с серьезные последствия
• Отраслевые стандарты : эти стандарты устанавливаются отраслевыми организациями, такими как The Open Group, а затем выбираются предприятие по усыновлению

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

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

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

37.4.3 Жизненный цикл стандартов

Стандарты обычно не существуют на все времена. Новые стандарты определяются и управляются в процессе жизненного цикла.

Обычно стандарты проходят следующие этапы:

• Предлагаемый стандарт : потенциальный стандарт был определен для организации, но еще не был оценен для принятие
• Предварительный стандарт (также известный как Пробный стандарт ): Предварительный стандарт был определен как потенциальный является стандартом для организации, но не был опробован и протестирован до уровня, при котором его ценность полностью понятна.

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

• Standard (также известный как Active Standard ): Стандарт определяет основное решение, которое обычно должно используется как метод выбора
• Стандарт поэтапного отказа (также известный как Устаревший стандарт ): срок действия стандарта поэтапного отказа приближается к концу. полезный жизненный цикл

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

• Устаревший стандарт (также известный как Устаревший стандарт ): Устаревший стандарт больше не принимается как действительный в течение пейзаж

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

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

37.4.4 Классификация стандартов в Информационной базе стандартов

Стандарты в Информационной базе стандартов классифицируются в соответствии со строительными блоками в рамках содержимого TOGAF. метамодель. С каждым объектом метамодели потенциально могут быть связаны стандарты (например, Business Service, Technology Компонент).

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

На верхнем уровне стандарты классифицируются в соответствии с доменами архитектуры TOGAF, включая следующие области:

• Бизнес-стандарты :
  • Стандартные общие бизнес-функции
  • Стандартные определения ролей и актеров
  • Стандарты безопасности и управления для коммерческой деятельности
• Стандарты данных :
  • Стандартное кодирование и значения для данных
  • Стандартные структуры и форматы данных
  • Стандарты происхождения и владения данными
  • Ограничения на репликацию и доступ
• Применение Стандарты :
  • Стандартные/совместно используемые приложения, поддерживающие определенные бизнес-функции
  • Стандарты связи и взаимодействия приложений
  • Стандарты доступа, представления и стиля
• Технологические стандарты ;
  • Стандартные аппаратные средства
  • Стандартные программные продукты
  • Стандарты разработки программного обеспечения

37.

37.5.1 Обзор

Журнал управления представляет собой хранилище для хранения общей информации, касающейся текущего управления проектами. Поддержание общего репозитория управляющей информации важно, потому что:

• Решения, принятые во время проектов (такие как отклонения от стандартов или обоснование конкретного архитектурного подхода), важно сохранять и получать доступ на постоянной основе

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

• Многие заинтересованные стороны заинтересованы в результатах управления проектом (например, другие проекты, заказчики проекта, Совет по архитектуре и др.)

37.5.2 Содержание журнала управления

Журнал управления должен содержать следующие элементы:

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

  Обычно это включает:

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

  Эта проверка позволит оценить соответствие проекта установленным стандартам архитектуры. Для каждого проекта этот журнал должен включают:

  • Обзор проекта
  • Обзор прогресса (хронология, статус, проблемы, риски, зависимости и т. д.)
  • Завершенные контрольные списки архитектуры
  • Оценка соответствия стандартам
  • Рекомендуемые действия
• Оценка возможностей : в зависимости от целей некоторые проекты будут проводить оценку бизнеса, ИТ или Возможности архитектуры

  Эти оценки следует периодически проводить и отслеживать, чтобы обеспечить достижение надлежащего прогресса. Этот журнал должно включать:

  • Шаблоны и эталонные модели для проведения оценок возможностей
  • Оценка возможностей бизнеса
  • Оценка возможностей, зрелости и воздействия ИТ
  • Оценка зрелости архитектуры
• Календарь : Календарь должен отображать расписание текущих проектов и формальных обзорных сессий, которые будут проводиться в отношении этих проектов. проекты
• Портфель проектов : портфель проектов должен содержать сводную информацию обо всех находящихся в стадии реализации проектах, подпадающих под Управление архитектурой, в том числе:
  • Название и описание проекта
  • Архитектурный объем проекта
  • Архитектурные роли и обязанности, связанные с проектом
• Измерение производительности : на основе устава архитектурной функции будет определен ряд критериев производительности. обычно определяется

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

37.6 Репозиторий требований к архитектуре

37.6.1 Обзор

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

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

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

37.6.2 Содержимое репозитория требований к архитектуре

Репозиторий архитектурных требований содержит архитектурные требования требуемого состояния предприятия в конкретный момент времени. моменты времени. Из-за огромного объема и разнообразных потребностей заинтересованных сторон на протяжении всего жизненного цикла архитектуры предприятия Требования к архитектуре разделены на три уровня детализации:

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

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

2. Требования к архитектуре сегмента содержат более подробные требования к операционной модели для областей внутри предприятия.

   Требования к архитектуре сегмента могут определять требования на уровне программы или портфеля для выявления и согласования большего количества подробная деятельность по изменению.

3. Требования к архитектуре возможностей определяют подробные требования к конкретной единице возможностей.

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

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

37.7 Ландшафт решений

Ландшафт решений содержит строительные блоки решений (SBB), которые поддерживают строительные блоки архитектуры (ABB). определены, разработаны и внедрены. Строительными блоками могут быть продукты или услуги, которые могут быть классифицированы в соответствии с Категоризация Enterprise Continuum и/или спецификации ABB как SBB стратегического, сегментного или функционального.

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

Однако Ландшафт решений не будет включать информацию и данные, созданные выбранными решениями; то есть ответственность самих решений.

37.8 Корпоративный репозиторий

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

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

37.9 Внешние хранилища

37.9.1 Внешние эталонные модели

Существует множество отраслевых эталонных моделей, которые могут помочь в понимании роли и разработке эталонных Архитектуры.

37.9.2 Внешние стандарты

Они относятся к отраслевым, передовым методам или официально определенным стандартам, используемым ведущими организациями. Примеры включают ISO, IEEE, и государственные стандарты.

37.9.3 Утверждения Совета по архитектуре

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