TOGAF

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 распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов. Лицензируется только коммерческое использование.

Основные принципы

  • модульность
  • стандартизованность
  • повторное использование зарекомендовавших себя существующих продуктов и технологий

Задачи системного архитектора

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

Терминология

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

Основные термины в стандарте TOGAF взяты из стандарта ISO 42010.

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

Состав

В состав модели TOGAF входят две основные компоненты:

  • Метод разработки архитектуры (ADM, Architecture Development Method), определяющий процесс разработки архитектуры;
  • Базовая Архитектура (Foundation Architecture)

Метод разработки архитектуры

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

ADM.png

  • Предварительная фаза предусматривает подготовку условий для разработки архитектуры, включая адаптацию 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).

Ссылки

Источник — «http://sewiki.ru/index.php?title=TOGAF&oldid=4479»