Просмотр исходного текста страницы 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-система|ERP-системы]]. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!

=== Базовая архитектура ===
Базовая Архитектура включает в себя:
* набор наиболее общих служб и функций, объединенных в '''Техническую Эталонную Модель''' (Technical reference model – TRM);
* набор элементарных архитектурных элементов, которые используются как "'''строительные блоки'''" (Building blocks) при построении конкретных решений:
** '''Архитектурные блоки''' (Architecture Building Blocks) — определяют требования и создают каркас, необходимый для их реализации. Например, на уровне предприятия архитектурным блоком может стать необходимость предоставления клиентского сервиса, что, в конечном счёте, приведёт к разработке различных решений как на уровне бизнеса, так и на уровне ИТ.
** '''Блоки реализации''' (Solution Building Blocks) — определяют компоненты готового решения. Например, корпоративная сеть, как готовый продукт, может быть строительным блоком при разработке распределённой информационной системы.
* '''база данных стандартов''' (Standards Information Base).

== Ссылки ==
* https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework

[[Категория:Архитектурные подходы]]