de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Полное руководство по архитектурным результатам в TOGAF

Введение

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

Понимание архитектурных результатов

Определение

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

Ключевые характеристики

  1. Формальное определение: Архитектурные результаты формально определены на договорной основе и проходят формальную проверку и процесс утверждения. Это гарантирует, что они соответствуют установленным стандартам и соответствуют ожиданиям заинтересованных сторон.
  2. Результат проекта: Это осязаемые результаты архитектурных проектов, которые служат записью архитектурных решений, проектов и реализаций.
  3. Архивирование или передача: После завершения результаты могут быть архивированы или переданы в Архитектурное хранилище, где они служат справочным материалом для будущих проектов.
  4. Множественные артефакты: Один результат может содержать несколько артефактов, таких как каталоги, матрицы и диаграммы, которые описывают различные аспекты архитектуры.

Типы артефактов

Артефакты — это архитектурные рабочие продукты, описывающие конкретные аспекты архитектуры. Обычно они классифицируются на три категории:

  1. Каталоги: Списки вещей, например, каталог приложений, услуг или сущностей данных.
  2. Матрицы: Таблицы, показывающие взаимосвязи между объектами, например, матрица возможностей или матрица зависимостей.
  3. Диаграммы: Визуальные представления объектов, например, диаграммы потока процессов, диаграммы потока данных или диаграммы случаев использования.

Блоки построения

Блоки построения — это повторно используемые компоненты корпоративной способности, которые могут быть объединены с другими блоками построения для создания архитектур и решений. Они могут быть определены на различных уровнях детализации и относятся либо к «архитектурам», либо к «решениям».

  1. Блоки построения архитектуры (ABBs): Описывают необходимую способность и формируют спецификацию блоков построения решений (SBBs). Например, в рамках предприятия может потребоваться способность по обслуживанию клиентов, поддерживаемая несколькими SBBs, такими как процессы, данные и программное обеспечение приложений.
  2. Блоки построения решений (SBBs): Представляют компоненты, которые будут использоваться для реализации необходимой способности. Например, сеть — это блок построения, который может быть описан с помощью дополнительных артефактов и затем применён для реализации решений для предприятия.

Роль архитектурных результатов в TOGAF

Структурная модель

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

Связь с архивом архитектуры

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

 

Пример: документ определения архитектуры

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

Практический пример

Сценарий: внедрение системы управления взаимоотношениями с клиентами (CRM)

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

Результаты архитектуры:

  1. Документ определения архитектуры: Этот результат документирует общую архитектуру системы CRM. Он включает несколько артефактов, описывающих различные аспекты архитектуры.
    • Диаграмма потока процессов: Диаграмма, иллюстрирующая целевой процесс обработки вызовов, включая этапы и участников (например, представитель службы поддержки клиентов).
    • Диаграмма случаев использования: Диаграмма, описывающая взаимодействие между системой CRM и её пользователями, выделяя ключевые случаи использования и участников.
    • Диаграмма потока данных: Диаграмма, показывающая поток данных внутри системы CRM, включая сущности данных и их взаимосвязи.
  2. Каталоги:
    • Каталог приложений: Список приложений, входящих в состав системы CRM, с их описаниями и функциональными возможностями.
    • Каталог данных: Список сущностей данных, управляемых системой CRM, включая их атрибуты и взаимосвязи.
  3. Матрицы:
    • Матрица возможностей: Таблица, показывающая возможности системы CRM и их взаимосвязи с бизнес-целями.
    • Матрица зависимостей: таблица, иллюстрирующая зависимости между различными компонентами системы CRM.
  4. Блоки построения:
    • Способность к обслуживанию клиентов: архитектурный блок построения (ABB), описывающий необходимую способность для обслуживания клиентов.
    • Приложение CRM: блок решения (SBB), представляющий программное обеспечение приложения, используемое для реализации способности к обслуживанию клиентов.

Переход в архитектурный репозиторий

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

План перехода к результатам TOGAF ADM

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

Предварительная фаза

Результаты:

  1. Настроенная архитектурная основа: настраиваемая версия основы TOGAF, адаптированная под конкретные потребности организации.
  2. Организационная модель корпоративной архитектуры: модель, определяющая роли, обязанности и структуру функции корпоративной архитектуры в организации.
  3. Принципы архитектуры: набор принципов, направляющих процесс разработки архитектуры, обеспечивая соответствие бизнес-целям и стратегическим задачам.
  4. Бизнес-принципы, цели и факторы: основополагающие бизнес-принципы, цели и факторы, влияющие на процесс разработки архитектуры.
  5. Запрос на работу по архитектуре: официальный запрос на начало проекта по архитектуре, в котором определяется объем, цели и ожидаемые результаты.

Фаза A: Видение архитектуры

Результаты:

  1. Заявление о работе по архитектуре: подробное описание работы по архитектуре, включая объем, цели и результаты.
  2. Видение архитектуры: высокий уровень описания целевой архитектуры, в котором определяется бизнес-ценность и ключевые возможности, которые будут реализованы.
  3. План коммуникаций: План по информированию заинтересованных сторон о видении архитектуры и ходе ее реализации.
  4. Оценка возможностей: Оценка текущих возможностей организации и пробелов, которые необходимо устранить.
  5. Документ определения архитектуры: Документ, описывающий видение архитектуры, включая бизнес-сценарий, заинтересованные стороны и принципы архитектуры.

Фаза B: Архитектура бизнеса

Результаты:

  1. Документ определения архитектуры: Обновленный документ, включающий архитектуру бизнеса, описывающий бизнес-стратегию, управление, организацию и ключевые бизнес-процессы.
  2. Спецификация требований к архитектуре: Подробная спецификация бизнес-требований, которые должна решить архитектура.
  3. Карта архитектуры: План высокого уровня, описывающий шаги и ключевые этапы разработки архитектуры бизнеса.
  4. Блоки построения архитектуры: Повторно используемые компоненты бизнес-возможностей, которые могут быть объединены для реализации архитектуры бизнеса.

Фаза C: Архитектуры информационных систем

Результаты:

  1. Документ определения архитектуры: Обновленный документ, включающий архитектуры информационных систем, описывающий архитектуры данных и приложений.
  2. Спецификация требований к архитектуре: Подробная спецификация требований к информационным системам, которые должна решить архитектура.
  3. Карта архитектуры: План высокого уровня, описывающий шаги и ключевые этапы разработки архитектур информационных систем.
  4. Блоки построения архитектуры: Повторно используемые компоненты возможностей информационных систем, которые могут быть объединены для реализации архитектур информационных систем.

Фаза D: Архитектура технологий

Результаты:

  1. Документ определения архитектуры: Обновленный документ, включающий архитектуру технологий, описывающий аппаратное обеспечение, программное обеспечение и сетевую инфраструктуру.
  2. Спецификация требований к архитектуре: Подробная спецификация технологических требований, которые должна решить архитектура.
  3. Карта архитектуры: План высокого уровня, описывающий шаги и ключевые этапы разработки технологической архитектуры.
  4. Блоки построения архитектуры: Повторно используемые компоненты технологических возможностей, которые могут быть объединены для реализации технологической архитектуры.

Этап E: Возможности и решения

Результаты:

  1. Документ определения архитектуры: Обновленный документ, содержащий возможности и решения, выявленные в процессе разработки архитектуры.
  2. Блоки построения архитектуры: Повторно используемые компоненты возможностей, которые могут быть объединены для реализации выявленных возможностей и решений.
  3. Карта архитектуры: План высокого уровня, описывающий шаги и ключевые этапы реализации выявленных возможностей и решений.
  4. Блоки построения решений: Компоненты, которые будут использоваться для реализации необходимой функциональности.
  5. План реализации и миграции: Подробный план по реализации и миграции на новую архитектуру.
  6. Переходная архитектура: Описание архитектуры, которая будет поддерживать переход от базовой архитектуры к целевой архитектуре.
  7. Модель управления реализацией: Модель, определяющая структуру управления и процессы реализации архитектуры.

Этап F: Планирование миграции

Результаты:

  1. Карта архитектуры: Обновленная карта, включающая подробный план миграции.
  2. План реализации и миграции: Подробный план по реализации и миграции на новую архитектуру.
  3. Переходная архитектура: Обновленное описание архитектуры, которая будет поддерживать переход от базовой архитектуры к целевой архитектуре.
  4. Модель управления реализацией: Обновленная модель, определяющая структуру управления и процессы реализации архитектуры.

Фаза G: Управление реализацией

Результаты:

  1. Модель управления реализацией: Модель, определяющая структуру управления и процессы реализации архитектуры.
  2. Договоры архитектуры: Соглашения между функцией архитектуры и другими частями организации, определяющие объем и результаты разработки архитектуры.
  3. Запрос на изменение: Формальный запрос на изменения в архитектуре, содержащий описание объема, целей и ожидаемых результатов.
  4. Оценка соответствия: Оценка соответствия архитектуры стандартам, нормативным требованиям и бизнес-целям.

Фаза H: Управление изменениями архитектуры

Результаты:

  1. Модель управления реализацией: Обновленная модель, определяющая структуру управления и процессы управления изменениями в архитектуре.
  2. Договоры архитектуры: Обновленные соглашения между функцией архитектуры и другими частями организации, определяющие объем и результаты разработки архитектуры.
  3. Запрос на изменение: Обновленные формальные запросы на изменения в архитектуре, содержащие описание объема, целей и ожидаемых результатов.
  4. Оценка соответствия: Обновленные оценки соответствия архитектуры стандартам, нормативным требованиям и бизнес-целям.
  5. Запрос на работу по архитектуре: Обновленные формальные запросы на начало проектов по архитектуре, содержащие описание объема, целей и ожидаемых результатов.
  6. Оценка воздействия требований: Оценка воздействия изменений в требованиях к архитектуре.
  7. Управление требованиями к архитектуре в рамках ADM: Процесс управления требованиями к архитектуре на протяжении всего жизненного цикла ADM.
  8. Спецификация требований к архитектуре: Обновленная спецификация требований к архитектуре, которые должна решать архитектура.

Заключение

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

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

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

Список ссылок по ArchiMate и TOGAF

  1. Инструмент TOGAF для корпоративной архитектуры – ArchiMetric
  2. Навигация по эволюции: всестороннее руководство по переходу от ArchiMate 2.1 к 3.2 – ArchiMetric
  3. Овладение корпоративной архитектурой с помощью инструмента TOGAF Visual Paradigm – ArchiMetric
  4. Что такое ArchiMate? – Visual Paradigm
    • Описание: Пошаговое руководство по изучению ArchiMate, его интеграции с TOGAF и тому, как он дополняет существующие методы, такие как UML и BPMN.
    • URL: Что такое ArchiMate?
  5. Использование BPMN для дополнения разработки корпоративной архитектуры TOGAF ADM совместно с ArchiMate – ArchiMetric
  6. Понимание абстракции в языке ArchiMate – ArchiMetric
    • Описание: В этой статье объясняются концепции абстракции в ArchiMate и то, как Visual Paradigm способствует эффективному моделированию и проектированию.
    • URL: Понимание абстракции в языке ArchiMate
  7. Обзор ArchiMate – языка моделирования корпоративной архитектуры – Cybermedian
    • Описание: В этом обзоре рассматриваются интеграция ArchiMate с TOGAF и другими фреймворками, а также преимущества использования Visual Paradigm для моделирования ArchiMate.
    • URL: Обзор ArchiMate
  8. Справьтесь со сложностью корпоративной архитектуры с помощью процесса Just-in-Time от Visual Paradigm – ArchiMetric
  9. Visual Paradigm TOGAF – Всё о TOGAF, корпоративной архитектуре, ArchiMate и многом другом
    • Описание: Этот гид предлагает подробный обзор ArchiMate 3, TOGAF и корпоративной архитектуры, а также того, как Visual Paradigm поддерживает эти фреймворки.
    • URL: Visual Paradigm TOGAF
  10. Бесплатный онлайн-инструмент ArchiMate + примеры – Cybermedian

Эти ссылки предоставляют всесторонний обзор ArchiMate и TOGAF, их интеграции и инструментов, доступных в Visual Paradigm для поддержки моделирования архитектуры предприятия.

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文

Оставить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *