TOGAF — различия между версиями

Версия 09:36, 13 мая 2016

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 разработка системной архитектуры состоит из следующих фаз:

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

Ссылки

• https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework