ru_RU

Введение в метод разработки архитектуры TOGAF (ADM)

Table of Contents hide
1 Откуда ТОГАФ?
2 Почему ТОГАФ?
3 Что такое АДМ?
4 Вход и выход ADM
5 Практические результаты
6 Начальная стадия:
7 Фаза A: Архитектурное видение:
8 Фаза B: Бизнес-архитектура:
9 Фаза C: Архитектура информационной системы:
10 Фаза D: Техническая архитектура:
11 Фаза E: Возможности и решения:
12 Фаза F: Планирование миграции:
13 Этап G: Внедрение управления:
14 Фаза H: Управление структурными изменениями:
15 Управление требованиями к архитектуре:
16 Предварительный этап ADM
16.1 Выходные результаты:
17 Фаза ADM A: Архитектурное видение
17.1 Выходные результаты:
18 Фаза B ADM: бизнес-архитектура
18.1 Выходные результаты:
19 ADM Фаза C: Архитектура информационных систем
20 Фаза D ADM: технологическая архитектура
20.1 Выходные результаты:
21 Фаза E ADM: возможности и решения
21.1 Выходные результаты:
22 Фаза F ADM: планирование миграции
23 ADM Фаза G: Управление реализацией
23.1 Выходные результаты:
24 ADM Фаза H: Управление изменениями архитектуры
25 Резюме
25.1 Вводные ссылки TOGAF
25.2 АрхиМейт 3

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

  • TOGAF разрабатывается и поддерживается членами The Open Group и работает в команде под названием Architecture Forum. Первая разработка TOGAF версии 1 была выпущена в 1995 году, а последующие версии TOGAF расширяли и улучшали эту систему знаний.
  • TOGAF был разработан совместными усилиями более 300 участников форума по архитектуре, представляющих некоторые из ведущих мировых компаний и организаций, поэтому он представляет собой хорошее обобщение общих практик архитектуры предприятия.
  • Разработка и поддержка архитектуры предприятия — это сложный процесс, в котором участвуют многие заинтересованные стороны и процессы принятия решений. TOGAF помогает документировать спецификации корпоративной архитектуры, процессы и рабочие продукты.
  • Используя TOGAF, организации могут разработать согласованную архитектуру предприятия, которая отражает потребности заинтересованных сторон, использует передовой опыт и должным образом учитывает текущие потребности и предполагаемые потребности бизнеса в будущем.

Откуда ТОГАФ?

TOGAF произошел от структуры архитектуры технологии управления информацией Министерства обороны США (TAFIM). TOGAF 1.0 был наконец выпущен в 1995 году после нескольких лет исследований с разрешения Министерства обороны США и при помощи крупных инвестиций правительства США. TOGAF выпустила свой девятый выпуск, TOGAF 9 (последний выпуск — TOGAF 9.2).

Почему ТОГАФ?

ИТ-архитектура должна точно отражать бизнес-цели организации. Действительно, следует использовать специальные методы (бизнес-сценарии), чтобы обеспечить правильное понимание бизнес-целей ИТ-архитектором и их отражение в ИТ-архитектуре, разработанной с использованием TOGAF.

Вот причины, по которым мы должны использовать TOGAF ADM для разработки архитектуры:

  • Комплексный общий метод
  • Дополняет другие фреймворки, но не конкурирует с ними.
  • Широкое распространение на рынке
  • Адаптируется для удовлетворения потребностей организации и отрасли
  • Доступно по бесплатной бессрочной лицензии
  • Открытый стандарт, не зависящий от поставщиков, инструментов и технологий
  • Избегает повторного изобретения колеса
  • Согласование бизнес-ИТ
  • На основе лучших практик
  • Возможно участие в развитии фреймворка

Что такое АДМ?

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

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

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

ADM описывает 10 этапов, охватывающих цикл разработки архитектуры.

Эти фазы:

  • Предварительный этап
  • Фаза A : Архитектурное видение
  • Фаза B : Бизнес-архитектура
  • Фаза C : Архитектура информационной системы
  • Этап D : Техническая архитектура
  • Фаза E : Возможности и решения
  • Фаза F : планирование миграции
  • Этап G : Внедрение управления
  • Фаза H : Управление изменениями архитектуры
  • Управление требованиями

Вход и выход ADM

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

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

Практические результаты

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

Начальная стадия:

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

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

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

Фаза A: Архитектурное видение:

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

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

Фаза B: Бизнес-архитектура:

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

ADM с точки зрения бизнеса — на предварительных этапах  запросов на работу с инфраструктурой  для определения сильного бизнес-требования и дальнейшего уточнения для фазы A в  заявлении о работе с инфраструктурой  и  архитектуре  .

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

Все три этапа разработки архитектуры (B, C и D) выполняются аналогично. Важно повторно использовать любую доступную эталонную модель и настраивать все выходные данные в соответствии с точкой зрения заинтересованной стороны. Затем архитектор разрабатывает базовое и целевое описание бизнес-архитектуры и выполняет анализ пробелов, чтобы определить, как перейти от одного к другому.

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

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

Фаза C всегда включает в себя сочетание данных и архитектуры приложения. При условии, что включены оба метода, и не имеет значения, в каком порядке — есть сторонники обоих методов. Шаги для данных и приложений очень похожи: выберите эталонные модели, точки зрения и инструменты; разработать базовые планы, а затем найти описания архитектуры, выполнить анализ пробелов и определить возможные компоненты дорожной карты; и устранять любые воздействия на общую архитектурную среду. После официального рассмотрения заинтересованными сторонами архитектура была окончательно определена, и был создан документ с определением архитектуры.

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

Фаза D: Техническая архитектура:

Этап D — это этап TOGAF, на котором разрабатывается техническая архитектура для архитектурного проекта. Архитектура технологии описывает структуру и взаимодействие сервисов платформы и логических и физических компонентов технологии. На этапе D разрабатывается целевая технологическая архитектура, которая поддерживает компоненты данных и приложений (разработанные на этапе C) для реализации бизнес-компонентов.

Архитектуры, разработанные на этапах B, C и D, объединяются для реализации архитектурного видения, разрешающего проблемы заинтересованных сторон и запросы строительных работ. Как и на других этапах разработки архитектуры, на этапе D определяются компоненты дорожной карты архитектуры-кандидата для достижения перехода от базового уровня к целевому. Шаги фазы D почти такие же, как и фазы B и фазы C, но главное отличие состоит в том, что теперь основное внимание уделяется технологии. Таким образом, это включает в себя технические эталонные модели и технические стандарты или измерения, такие как производительность, ремонтопригодность, местоположение и задержка или доступность.

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

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

Фаза E получила свое название — она заключается в поиске возможностей для обеспечения целевой архитектуры путем реализации конкретных решений. На этапе E создается первая полная версия дорожной карты архитектуры путем объединения рекомендаций анализа и разработки этапов B, C и D.

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

Фаза F: Планирование миграции:

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

Это также гарантирует, что план скоординирован с методами управления изменениями, используемыми в компании, и другими планами в общем портфеле изменений. Наконец, фаза F гарантирует, что ключевые заинтересованные стороны полностью понимают ценность бизнеса, стоимость рабочего пакета, а также переходную и будущую архитектуру. Хотя на ранних стадиях ADM сильно зависит от команды разработчиков архитектуры предприятия, этапы от E до H требуют сотрудничества с другими агентами изменений.

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

Четыре области:

  1. бизнес-план
  2. Архитектура предприятия
  3. Управление портфелем
  4. управление проектом

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

Этап G: Внедрение управления:

Фактическая разработка и внедрение происходят параллельно с фазой G. Фаза G обеспечивает соответствие проекта внедрения и других текущих проектов определенной архитектуре.

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

К моменту, когда мы достигаем этапа G, архитектура уже разработана (на этапах от A до D), определены возможности и решения для обеспечения архитектуры (на этапе E), а подробные планы внедрения и миграции завершены (на этапе F). ). Таким образом, роль группы архитекторов фазы G заключается в обеспечении надзора за реализацией архитектуры. Это делается путем проверки объема и приоритетов развертывания, руководства разработкой и развертыванием решения, а также проведения проверок соответствия.

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

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

Ничего не пошло по плану — всегда будут новые требования и изменения в архитектуре. Фаза H описывает процесс управления изменениями для согласованного и структурированного управления изменениями в архитектуре. Обычно для этого требуется постоянный мониторинг запросов на управление, новых технологий или изменений в бизнес-среде.

Процесс должен поддерживать реализованную архитектуру предприятия как динамическую среду, способную гибко реагировать на эти изменения и быстро развиваться. На этапе H важно, чтобы руководящий орган установил стандарты, чтобы определить, требует ли запрос на изменение простого обновления архитектуры или необходимо инициировать новый цикл метода разработки архитектуры (ADM). Изменения должны быть непосредственно связаны с ценностью бизнеса. Как использовать корпоративную архитектуру — самая важная часть цикла разработки архитектуры, поэтому крайне важно отслеживать рост и спад бизнеса на этапе H.

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

Управление требованиями к архитектуре:

На каждом этапе ADM требуются требования к генерации, анализу и обзору. Этап управления требованиями описывает процесс управления этими архитектурными требованиями в рамках ADM. Этап управления требованиями является ядром ADM, поэтому он показан в центре кругов на полях ADM. На этом этапе описывается процесс управления требованиями и то, как этот процесс связан с другими этапами ADM. Требования не статичны — они динамически развиваются между каждым этапом нашего завершения ADM и циклом ADM.

Требования архитектуры предприятия и последующие изменения этих требований будут идентифицированы, сохранены, а ввод и вывод связан с фазами ADM и между циклами ADM. Работа с изменениями спроса имеет решающее значение. Архитектура имеет дело с неопределенностью и изменениями — «серой зоной» между ожиданиями и возможностями заинтересованных сторон! Поэтому архитектурные требования всегда будут меняться.

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

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

Предварительный этап ADM

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

Выходные результаты:

Фаза ADM A: Архитектурное видение

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

Выходные результаты:

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

Бизнес-архитектура: разработка бизнес-архитектуры для поддержки согласованного видения архитектуры.

Выходные результаты:

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

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

Фаза D ADM: технологическая архитектура

Технологическая архитектура: разработка технологической архитектуры для поддержки согласованного Архитектурного видения.

Выходные результаты:

Фаза E ADM: возможности и решения

Opportunities & Solutions проводит начальное планирование внедрения и идентификацию средств доставки для архитектуры, определенной на предыдущих этапах.

Выходные результаты:

Фаза F ADM: планирование миграции

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

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

Управление реализацией обеспечивает архитектурный надзор за реализацией

Выходные результаты:

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

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

Резюме

ADM представляет собой всеобъемлющий общий метод

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

Вот обзор TOGAF ADM для каждого этапа разработки, как показано на следующем рисунке:

  1. Подробнее о TOGAF ADM Guide-through
  2. Подробнее о шаблонах TOGAF «точно в срок»
  3. Подробнее об инструментах ArchiMate
  4. Попробуйте Visual Paradigm БЕСПЛАТНО

Вводные ссылки TOGAF

АрхиМейт 3

3 комментария

Leave a Reply

Ваш адрес email не будет опубликован.