The Open Group Architecture Framework (TOGAF) — методология/библиотечный метод описания/подход (framework) для описания архитектуры предприятия, который предлагает подход для проектирования, планирования, внедрения IT-архитектуры предприятия и управления ей. TOGAF разрабатывается с 1995 группой The Open Group на основе фреймворка Министерства обороны США TAFIM.
TOGAF — высокоуровневый подход к проектированию. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:
- Бизнес архитектура (Business) — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
- Архитектура данных (Data) — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
- Архитектура приложений (Application) — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:
- участие каждого из приложений в бизнес процессах компании;
- взаимодействие приложений друг с другом и внешними сервисами.
- Технологическая архитектура (Technology) — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т.п.
По состоянию на 2016, TOGAF используют 40 из 50 крупнейших транснациональных компаний и 300 из 500 самых крупных компаний США.
TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов. Лицензируется только коммерческое использование.
Содержание
- 1 Основные принципы
- 2 Задачи системного архитектора
- 3 Терминология
- 4 Состав
- 4.1 Метод разработки архитектуры
- 4.2 Базовая архитектура
- 5 Использование TOGAF с другими фреймворками
- 6 Ссылки
Основные принципы
- модульность
- стандартизованность
- повторное использование зарекомендовавших себя существующих продуктов и технологий
Задачи системного архитектора
- Формализация выявленных проблем и заявленных требований к ИТ со стороны бизнеса. Выявлением проблем и установкой требований должен заниматься менеджмент.
- Разработка архитектурных представлений (уровней), которые бы показывали, как решаются конкретные задачи и как обеспечивается реализация требований.
- Определение точек разногласия различных заинтересованных сторон и разработка компромиссных предложений.
Терминология
В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.
Основные термины в стандарте TOGAF взяты из стандарта ISO 42010.
Архитектура — фундаментальная организация системы, состоящая из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы. TOGAF рассматривает предприятие как систему.
Состав
В состав модели TOGAF входят две основные компоненты:
- Метод разработки архитектуры (ADM, Architecture Development Method), определяющий процесс разработки архитектуры;
- Базовая Архитектура (Foundation Architecture)
Метод разработки архитектуры
TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:
- Предварительная фаза предусматривает подготовку условий для разработки архитектуры, включая адаптацию TOGAF к реальной среде, и определение основных принципов, на которых будет строиться разработка архитектуры.
- Фаза A: Видение архитектуры представляет собой начальную фазу цикла разработки архитектуры. Фаза включает планирование основных мероприятий, определение заинтересованных сторон, создание «Архитектурного видения» и утверждение это видения у руководства.
- Фаза B: Бизнес архитектура предусматривает разработку архитектуры деятельности предприятия в соответствии с ранее утвержденным видением.
- Фаза C: Архитектура информационных систем
- Фаза D: Технологическая архитектура
- Фаза E: Возможности и решения. Фаза определяет разрыв между текущей архитектурой и целевой, а также устанавливает набор возможных средств для достижения целевой архитектуры. В основе данной фазы лежит SWOT-анализ. В качестве средств достижения целей могут инициироваться различные проекты и программы.
- Фаза F: Планирование перехода определяет мероприятия для перехода из текущего состояния архитектуры в целевое. Фаза предусматривает разработку «Плана реализации и перехода», детализированного до уровня пакетов работ, которым можно дать стоимостную оценку и, в конечном счёте, оценить проектные параметры (объём, сроки, стоимость) всего перехода в целом.
- Фаза G: Управление реализацией обеспечивает архитектурный надзор в процесс перехода от текущего состояния к целевому.
- Фаза H: Управление изменениями в архитектуре. Для того чтобы обеспечить достижение изначальных целей в меняющихся условиях, необходимо управлять всеми изменениями, которые вносятся в целевую архитектуру.
- Управление требованиями — это процесс, который охватывает все этапы разработки архитектуры и обеспечивает целостность всего проекта.
Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!
Базовая архитектура
Базовая Архитектура включает в себя:
- набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
- набор элементарных архитектурных элементов, которые используются как «строительные блоки» (Building blocks) при построении конкретных решений:
- Архитектурные блоки (Architecture Building Blocks) — определяют требования и создают каркас, необходимый для их реализации. Например, на уровне предприятия архитектурным блоком может стать необходимость предоставления клиентского сервиса, что, в конечном счёте, приведёт к разработке различных решений как на уровне бизнеса, так и на уровне ИТ.
- Блоки реализации (Solution Building Blocks) — определяют компоненты готового решения. Например, корпоративная сеть, как готовый продукт, может быть строительным блоком при разработке распределённой информационной системы.
- база данных стандартов (Standards Information Base).
Использование TOGAF с другими фреймворками
Поскольку TOGAF является общим фреймворком и предназначен для использования в самых разных средах, он обеспечивает гибкую и расширяемую структуру содержания, которая поддерживает набор архитектурных результатов. TOGAF может быть использован либо самостоятельно вместе со своими архитектурными результатами, либо эти результаты могут быть заменены или расширены за счет более конкретного набора, определенного в других фреймворках, которые архитектор считает актуальными.
Во всех случаях предполагается, что архитектор будет адаптировать и развивать TOGAF для того, чтобы определить индивидуальный метод, который интегрирован в процессы и организационные структуры предприятия. Эта адаптация может включать в себя принятие элементов из других архитектурных фреймворков или интеграцию методов TOGAF с другими стандартными фрейворками (ITIL, CMMI, COBIT, PRINCE2, PMBOK).
Ссылки
- https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework
В TOGAF процессы создания и развития, управления изменениями, контроля реализации архитектурных решений интегрированы в единый архитектурный цикл Метод Развития Архитектуры (Architecture Development Method ADM). Данный метод можно и нужно адаптировать под задачи вашей компании на всех уровнях разработки архитектуры. При этом, нет необходимости делать все возможные документы. Не нужно погружаться во все детали. На каждом этапе ADM предлагает готовый набор техник, инструментов, шаблонов и чек листов. Метод Развития Архитектуры (ADM) содержит десять фаз. Каждая фаза, в свою очередь разбивается на под-процессы (этапы), отдельные работы и так далее.
Например, фаза D включает следующие основные под-процессы:
Описание существующей технологической архитектуры.
•Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
•Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
•Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
•Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
•Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
Формирование целевой технологической архитектуры.
•Описание существующей системы в терминах TOGAF.
•Определение перспектив (представлений) архитектуры.
•Формирование модели целевой архитектуры.
•Определение ИТ-служб (сервисов).
•Подтверждение учета бизнес-требований.
•Определение архитектуры и используемых блоков (шаблонов).
•Проведение анализа расхождений (gap analysis).
Фазы и задачи Метода Развития Архитектуры
Предварительная фаза. Основные задачи:
•Создать архитектурную практику,
•подготовить компанию к запуску архитектурных проектов,
•заручиться поддержкой руководства,
•сформулировать архитектурные принципы,
•адаптировать методологию под цели и задачи компании
Фаза А – Видение архитектуры. Основные задачи:
•Запустить архитектурный проект, определить цели и задачи, определить рамки, предположения и ограничения проекта, разработать видение архитектуры, определить всех заинтересованных лиц,
•разработать «Устав проекта» и получить формальное подтверждение старта проекта.
Фаза B – Бизнес Архитектура. Основные задачи:
•Разработать архитектуру с описанием текущей и целевой архитектуры,
•Анализ расхождений
Фаза C – Архитектура Информационных Систем. Задачи:
•Разработать архитектуру с описанием текущей и целевой архитектуры,
•Анализ расхождений
Фаза D – Техническая Архитектура. Основные задачи:
•Разработать архитектуру с описанием текущей и целевой архитектуры,
•Анализ расхождений
Фаза Е – Возможности и решения. Основные задачи:
•Выполнить начальное планирование реализации задач проекта.
•Идентифицировать основные проекты внедрения и сгруппировать их в переходные архитектуры.
Фаза F – Планирование миграции. Основные задачи:
•Анализ затрат и рисков.
•Разработка детального плана внедрения и миграции.
Фаза G – Управление реализацией. Основные задачи:
•Архитектурный надзор за проектами внедрения.
•Подготовить архитектурные контракты.
•Обеспечить соответствие архитектуре результатов проектов внедрения.
Фаза H – Управление изменениями архитектуры. Задачи:
•Подготовится к следующему витку жизненного цикла архитектуры.
•Процесс управления изменениями должен обеспечить соответствие архитектуры актуальным потребностям бизнеса и дать максимальную ценность бизнесу.
Управление требованиями. Основные задачи:
•На каждой фазе архитектурного проекта собираете и согласуете бизнес требования.
•Требования должны быть идентифицированы, сохранены, определены приоритеты и использованы на соответствующих фазах архитектурного проекта.
Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:
•Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия.
•Модель TOGAF позволяет выполнять этапы частично, пропускать их, объединять, изменять порядок и вносить изменения в соответствии с конкретными требованиями. Неудивительно, что два сертифицированных консультанта по TOGAF могут разработать два совершенно различных процесса – даже при работе с одной и той же организацией.
•Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии).
Базовая Архитектура (Foundation Architecture).
Базовая Архитектура, включает в себя:
•набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
•набор элементарных архитектурных элементов, которые используются как «строительные блоки» при построении конкретных решений;
•база данных стандартов (Standards Information Base).
Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур, входящих в общий континуум определений. В TOGAF техническая эталонная модель рекомендуется к использованию, но не являются обязательной. В общем техническая эталонная модель, не лишена недостатков по следующей причине: она направлены на обеспечение переносимости приложений в ущерб их способности к взаимодействию и автономности. Для организаций модель TOGAF в значительной степени сводится к методике разработки архитектуры. В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т. п.
Следующая степень детализации реализуется на уровне Отраслевой Архитектуры, которая добавляет специфичные для каждой индустрии модели данных, приложения, стандарты, бизнес-правила, а также, при необходимости, процедуры взаимодействия различных отраслевых систем между собой. Наконец, на последнем уровне Архитектуры Организации формируется архитектура ИТ-систем конкретного предприятия, учитывающая все его особенности, в том числе наличие унаследованных систем, планы и возможности реализации, организацию данных на физическом уровне и т. п.
В состав Эталонной Модели, в свою очередь, входит система (таксономия) общих служб, включающая такие службы, как Обмен и преобразование данных, Управление данными, Поддержка интернационализации, Службы Каталогов и т. п.
Для всех используемых в архитектуре служб, наряду с функциональным назначением, необходимо определить и уровень качества реализации, то есть такие характеристики как управляемость, гибкость, гарантированность, удобство использования и т. п. При этом следует учитывать, что некоторые службы являются в этом плане взаимозависимыми. Например, для обеспечения заданного качества службы интернационализации могут потребоваться специализированные компоненты службы разработки программного обеспечения для создания и тестирования соответствующих программных продуктов.
Архитектурные принципы представляют собой как бы фундаментальные «аксиомы», которые используются в качестве «отправных точек» как для оценки существующей системы, так и для разработки отдельных архитектурных решений. Вообще говоря, архитектурные принципы являются подмножеством более общего понятия ИТ-принципов, которые определяют основные
аспекты всей деятельности, связанной с применением информационных технологий. ИТ-принципы, в свою очередь, являются детализацией еще «более общих» принципов, определяющих деятельность предприятия в целом.
В состав набора принципов могут входить обоснования для формирования системы требований или критериев оценки тех или иных решений. Например, такой принцип, как «минимизация числа поставщиков программного обеспечения», может быть в дальнейшем конкретизирован в зависимости от особенностей предприятия, как требование «единой СУБД для всех критичных для бизнеса приложений» или же как «использование той же СУБД, что и уже применяемая». Архитектурные принципы могут также использоваться для обоснования значимости самого понятия Архитектуры и необходимости ее разработки для бизнеса предприятия, а также для выбора вариантов реализации этого процесса.
Принципы являются взаимозависимыми и должны применяться в целостном наборе. «Хороший» набор принципов должен удовлетворять таким естественным критериям, как доступность для понимания, точность формулировок, полнота, последовательность и стабильность (не нужно путать с неизменяемостью!) Обычно число принципов не превышает 20, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые неработоспособны на практике.
Рисунок: Архитектуры Предприятия «TOGAF»
Примеры принципов, используемых при создании архитектуры TOGAF (Название и содержание):
Пример использования – Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации.
Максимальная польза – Решения в области ИТ принимаются исходя из максимума пользы для организации в целом.
Привлечение всех – Управление информацией есть дело каждого.
Непрерывность бизнеса – Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ.
Общее использование – Предпочтение должно отдаваться разработке или внедрению приложений, применимых в масштабах всего предприятия, а не отдельных его подразделений.
Соответствие законодательству – Управление ИТ не должно противоречить применяемому законодательству и принятым регламентам, однако это не есть препятствие к улучшению бизнес-процессов, влекущему за собой изменение этих регламентов.
Ответственность ИТ-службы – ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса.
Защита интеллектуальной собственности – Обеспечение защиты интеллектуальной собственности организации должно быть реализовано на уровне архитектуры, процессов эксплуатации и управления ИТ.
Данные являются активом – Данные в ИТ-системе предприятия имеют определенную ценность и должны соответственно управляться, быть общими и доступными для пользователей с учетом их прав доступа.
Обеспечение качества – Каждый элемент данных должен иметь ответственного за качество.
Общие метаданные – Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей.
Безопасность данных – Данные должны быть защищены от неавторизованного использования и распространения.
Технологическая независимость – Прикладное ПО не должно зависеть от специфичных моделей оборудования и системного ПО.
Простота использования – Приложения позволяют сконцентрироваться на выполнении бизнес-задач за счет единого интерфейса, минимизации специфики работы, интеграции систем, снижения вероятности неправильного использования.
Обоснованность и своевременность изменений – Изменения в информационной системе и приложениях производятся только в соответствии с запросами бизнеса, но в случае появления такой необходимости – в нужное время.
Взаимодействие – Взаимодействие Компоненты программного и аппаратного обеспечения должны обеспечивать интеграцию между собой в соответствии с общими стандартами.
Минимизация разнообразия – Уменьшение числа различных вариантов применяемых платформ, продуктов и версий.
Данный текст является ознакомительным фрагментом.
|
Вопрос |
Артефакт |
|
Что |
Диаграмма классов. |
|
Набор таблиц в БД и связей между ними. |
|
|
Как |
Спецификация бизнес-процессов на низкоуровневом языке. |
|
Контракт классов |
|
|
Где |
Демилитаризованные зоны |
|
Технологии общения между ними. |
|
|
Кто |
Спецификация ролей и их результатов работы в терминах выб |
|
технологии |
|
|
Когда |
Спецификация механизмов работы с событиями времени |
|
Зачем |
Technician perspective / Tool components (Техник перспективные компоненты / Инструментальные)
•Роль – разработчик ПО
•Решаемая задача – написание программного кода
•Основной результат – работающая система
•Разрабатывают программу на языке программирования
|
• |
|
|
Вопрос |
Артефакт |
|
Что |
Код создания таблиц в БД |
|
Как |
Код реализации методов в классе |
|
Где |
Протоколы и спецификации каналов связи |
|
Кто |
Реализация прав и ограничений пользователей |
|
Когда |
Реализация обработки таймеров, событий и т.п. |
|
Зачем |
Enterprise retrospective/Operations Instances (Предприятие ретроспективные / Операции Экземпляры)
•Роль – пользователи КИС
•Решаемая задача – достижение бизнес-целей с помощью КИС
•Основной результат – артефакты, соответствующие прописанным результатам работы роли
•Работают с системой
|
Вопрос |
Артефакт |
|
Что |
Данные, как полученные в результате работы, так и справочни |
|
системы |
|
Как |
Выполняемый модуль (сама программа) |
|
Где |
Функционирование реализованной сети |
|
Кто |
Обученные пользователи системы |
|
Когда |
История функционирования системы |
|
Зачем |
TOGAF. Обзор фреймворка, его назначение. Краткое описание основных частей и связь между ними. Значимать управления изменениями
Данный фреймворк ориентирован на решения задач, связанных с проектированием, планированием, реализацией и управлением корпоративной архитектурой и представляет собой набор инструментов, использование которых позволяет разрабатывать широкий спектр архитектур различного назначения. Он позволяет описывать ИС как совокупность строительных блоков (модулей), определять способы их соединения с помощью прилагаемого инструментария, включает список рекомендованных к применению стандартов и платформ, которые могут быть использованы при реализации.
В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.
TAGAF дает собственное определение архитектуры, в соответствии с которым архитектура ИС— это формальное описание системы или детальные план системы на уровне компонент, на основании которого осуществляется реализация системы».
Обще принятое определение архитектуры – это описание организации системы в терминах компонентов их взаимосвязей между собой и с окружающей средой и принципы управлением их разработкой и развитием.
Домены архитектуры
TOGAF является руководящей основой (framework) для разработки и поддержания архитектуры. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:
Бизнес архитектура — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
Архитектура данных — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
Архитектура приложений — определяет интерфейсы отдельных приложений и способы их использования в процессе реализации бизнес-процессов в терминах бизнес-сервисов
Технологическая архитектура — описывает аппаратную, программную и сетевую инфраструктуру.
Архитектор уровня предприятия должен успешно работать в каждом из этих доменов.
Основные компоненты TOGAF:
•ADM – метод разработки архитектуры
•ADM Guidelines and Techniques – руководство и методика проектирования
•Architecture Content Framework – фреймворк содержания архитектуры. Представляет собой отдельную модель результатов разработки архитектуры, в терминах артефактов и архитектурные блоки.
•Enterprise Continuum And Tools – континуум предприятия, представляющий собой репозиторий архитектурных артефактов и артефактов реализации.
•TOGAF Reference Model – эталонная модель TOGAF. Включает в себя техническую эталонную модель и интегрированную модель информационной инфраструктуры.
•Architecture Capability Framework – фреймворк возможностей архитектуры.
Описывает структуру организации, персонал, роли и ответственности.
TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. TOGAF включает методологию разработки архитектуры под названием Architecture Development Method (ADM).
В процессе работы над корпоративной архитектурой возникают различного вида результаты: диаграммы процессов, требования к архитектуре, планы проектов по переходу из одного состояние в другое, результаты проведения авторского надзора и т. п. Благодаря Architecture Content Framework (ACF), который является частью TOGAF, все эти объекты–результаты чётко определены и представляют собой целостную систему для архитектурного описания.
Назначение: Типизация артефактов, Описание артефактов, Связь артефактов с ADM
Понятие Enterprise Continuum (совокупность на уровне предприятия) с одной стороны определяет подход к адаптации общих архитектурных принципов для решения конкретных задач предприятия, с другой стороны предусматривает обобщение зарекомендовавших себя решений в форме универсальных практических руководств и стандартов.
Назначение: Управление архитектурными артефактами, Архитектурный репозиторий – что это, как с этим работать; Инструменты для разработки архитектуры
Architecture Capability Framework(Фреймворк архитектурных возможностей). Показывает, с чего надо начинать работу по созданию архитектуры. Какие ключевые действия нужно сделать при создании архитектуры.
Основными сферами применения TOGAF являются крупные организации, которые ориентированы на конкретные предметные области (оборона, финансы, здравоохранение).
Если сравнить TOGAF с Захманом, о просматривается различие в подходах. Захман ориентирован на описание некоторой конкретной архитектуры и в его основе лежит таксономия, то в основе TOGAFлежит понятие архитектурного континиума, т.е.
архитектура постоянно находится в процессе изменения, отслеживая изменения бизнестребований, поэтому на первый план выходит ADM.
Значимость управления требованиями(изменениями):
Цели:
Убедитесь, что процесс управления требованиями поддерживается и работает для всех соответствующих этапов ADM
Архитектура управления требованиями, определена при выполнении в любого цикла ADM или фазы
Убедитесь, чтобы соответствующая архитектура требований была доступна для использования каждой фазой, которая выполняется
При определении требований архитектор должен учитывать:
Предположения для требований
Ограничения для требований
Предметно-ориентированные принципы, которыми управляют требования
Политика влияния на требования
Стандарты, которые должны отвечать требованиям
Организация руководящих принципов для требований
Технические характеристики требований
Шаги:
Определение исходных требований и приоритетов.
Слежение за основными требованиями
Определение изменений требований и приоритетов записей
Обновление информации в хранилище требований
Артефакты:
•Требования по оценке воздействия
•Обновленная архитектура спецификаций требований
Управление требованиями (изменениями) – это центральный прямоугольник в диаграмме. Показывает нам то, что весь процесс TOGAF интерактивен и мы на любом этапе можем вернуться к любому другому этапу и внеси изменения.
TOGAF. ADM. Фазы подготовки (Предварительная фаза и А. Разработка общего представления). Используемые в работе артефакты, ключевые шаги и ключевые артефакты результата.
В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:
Предварительная фаза предусматривает подготовку условий для разработки архитектуры, включая адаптацию TOGAF к реальной среде, и определение основных принципов, на которых будет строиться разработка архитектуры.
Фаза A: Видение архитектуры представляет собой начальную фазу цикла разработки архитектуры. Фаза включает планирование основных мероприятий, определение заинтересованных сторон, создание «Архитектурного видения» и утверждение этого видения у руководства.
Предварительная фаза.
Цель:
•Выявить запросы на архитектурные возможности
•Установить архитектурные возможности
|
Не архитектурные требования |
Архитектурные требования |
|
|
бизнес-модель компании, ее цели |
Организационная модель корп. |
|
|
архитектуры: |
||
|
Главные операционные подходы ведения |
||
|
бизнеса(проектная/продуктовая) |
• |
Граница задействованных |
|
организаций |
||
|
Правовое поле функционирования |
• |
Роли и ответственность |
|
архитектурной команды |
|
компании |
• Бюджетные ограничения |
|
• Стратегия управления и поддержки |
|
|
Архитектурные возможности |
|
|
Существующее фреймворки. |
|
|
Партнерские отношения, заключенные |
|
|
контакты. |
Шаги:
•Ограничение задействованных организаций, их классификация
•Утверждение фреймворков управления и поддержки
•Определение и учреждение команды корпоративной архитектуры, ее организация.
•Идентификация и установка архитектурных принципов
•«Сшивание» TOGAF и других арх. фреймоврков
•Выбор инструментов для разработки архитектуры
Артефакты:
•Организационная модель корпоративной архитектуры:
•Задействованные организации
•Роли и обязанности архитектурной команды
•Ограничение, накладываемые на разработку архитектуры
•Бюджетные ограничения
•Стратегия управления и поддержки
•Адаптированный архитектурный фреймворк
•Подготовленный архитектурный репозиторий
•Связь с бизнес-принципами, бизнес-целями, бизнес-драйверами
•Фреймворк управления архитектурой.
Фаза А. Архитектурное видение.
Цели:
•Высокоуровневое виденье возможностей и бизнес ценности, которые будут получены в результате внедрения архитектуры.
•Получить подтверждение по плану разработки, описанной в архитектурном виденью.
|
Не архитектурные требования |
Архитектурные требования |
|
|
Принципы компании, бизнес-цели и |
Артефакты, разработанные на |
|
|
бизнес-драйверы |
предыдущем шаге. |
|
|
Запрос на разработку архитектуры (из |
||
|
предыдущего шага) |
||
|
Шаги: |
•Учредить архитектурный проект
•Выявить стейкхолдеров, их пожелания и бизнес требования
•Утвердить и тщательно проработать бизнес-цели, бизнес-драйверы и ограничения.
•Оценить возможности бизнеса
•Оценить готовность бизнеса к изменениям
•Установить границы
•Утвердить и тщательно проработать Архитектурные принципы, включая бизнеспринципы
•Разработать архитектурное видение
•Определить ценностные предложения целевой архитектуры
•Выявить бизнес-риски и преобразования и способы их уменьшения
•Описать разработку архитектуры и защитить оценку.
Артефакты:
•Утверждение описание разработки архитектуры
•Уточнение описание бизнес-принципов, бизнес-целей и бизнес-драйверов.
•Оценка возможностей
•Адаптированный архитектурный фреймворк
•Видение архитектуры
•Черновой вариант документов определения архитектуры
•План коммуникации
TOGAF. ADM. Фазы разработки архитектур (Фазы B – D). Используемые в работе артефакты, ключевые шаги и ключевые артефакты результата.
Фаза B: Бизнес архитектура предусматривает разработку архитектуры деятельности предприятия в соответствии с ранее утвержденным видением. Определение общих принципов функционированияия организации в терминах бизнес-процессов, принципов управления проектов и анализ того, в какой степени результаты деятельности организации соответствуют бизнес-целям. Основные артефакты: структура организации, бизнес-цели, бизнес-функции, бизнес-сервисы, бизнес процессы, основные роли, взаимосвязи между организационной структурой организации и реализуемой функциями.
Фаза C: Архитектура информационных систем. С точки зрения теории, сначала следует разрабатывать архитектуру данных, а затем архитектуру приложений, однако на практике не всегда удается реализовать такой подход, и обычно на данной фазе требуется выполнить несколько итераций.
Фаза D: Технологическая архитектура. Выбор аппаратных средств и сетевой инфраструктуры и механизмов их взаимодействия.
Фаза B:
Цель:
Разработать целевую бизнес-архитектуру
Выявить возможные компоненты «дорожной карты»
|
Не архитектурные требования |
Архитектурные требования |
|
Запрос на разработку архитектуры |
Организационная модель корп. арх-ры |
|
Бизнес-принципы, бизнес-цели, бизнес- |
Адаптированный архитектурный |
|
драйверы |
фреймворк |
|
Утвержденный план разработки |
|
Оценка возможностей |
архитектуры |
|
План взаимодействия |
Архитектурные принципы |
|
Корпоративный континуум |
|
|
Репозиторий архитектуры |
|
|
Видение архитектуры |
|
|
Черновики документов |
|
Шаги:
Выбрать модели для примера, точки зрения и инструменты
Разработать архитектурное описание текущей архитектуры
Разработать архитектурное описание целевой архитектуры
Выполнить анализ расхождений
Определить кандидатов в «дорожную карту(roadmap)»
Организовать формальное ревью стейкхолдеров
Закончить бизнес-архитектуру
Создать документ с архитектурным описанием Артефакты:
Уточненная и обновленная версия видения архитектуры
Черновая, но значительно более проработанная, версия документов, определяющих архитектуру.
Черновик спецификации требований к архитектуре, включая:
Анализ расхождений
Технические требования
Обновленные бизнес-требования
Фаза С
Цель:
Разработать и обосновать целевую архитектуру данных
С помощью GAPанализа выявить кандидатов на включение в план работ.
|
Не архитектурные требования |
Архитектурные требования |
|
Запрос на архитектурную работу |
Организационная модель корп. арх-ры |
|
Оценка возможностей |
Адаптированный архитектурный |
|
фреймворк |
|
|
План коммуникаций |
Принципы данных
Описание архитектурной работы
Видение архитектуры
Черновики определения архитектуры
Черновик спецификации требований к арх:
Результат gap-анализа
Технические требования, относящиеся к этой фазе
Шаги:
Выбрать рефересную модель, точки зрения и инструменты
Разработать описание текущей архитектуры
Разработать описание целевой архитектуры данных
Осуществить gap – анализ
Определить кандидатов в план работ
Разрешить влияние на архитектурный ландшафт
Осуществить формальное ревью стейкхолдеров
Закончить архитектуры данных
Создать документ определения архитектуры данных.
Артефакты:
Уточненная и обновленная версия видения архитектуры
Черновой документ определить архитектуры
Черновой вариант спецификации требований к архитектуре
Компоненты архитектуры данных в плане работ
Фаза D
Цель:
Разработать целевую технологическую архитектуру
С помощью GAPанализа выявить кандидатов на включение в план работ.
|
Не архитектурные требования |
Архитектурные требования |
|
Запрос на архитектурную работу |
Организационная модель корп. арх-ры |
|
Оценка возможностей |
Адаптированный архитектурный |
|
фреймворк |
|
|
План коммуникаций |
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #