Архитектурный фреймворк TOGAF

Разработчик: The Open Group (открытый консорциум).

Год формирования первых версий: 1991.

Форма: стандарт в рамках консорциума «The Open Group», развит институт сертификации специалистов.

Тип: комплексный фреймворк.

Ключевые особенности: TOGAF содержит в своем ядре метод разработки архитектуры — ADM. Метод детально описан, что является отличительной особенностью TOGAF.

Краткое описание. The Open Group Architecture Framework (TOGAF) разработан и развивается за счет коллективной работы членов консорциума «The Open Group». Первая версия возникла в 1991 г. С тех пор TOGAF прошел путь от ориентации на технологии и ИТ до полноценного архитектурного стандарта, ориентированного на целостный взгляд на организацию (от бизнес-стратегии до технологий). В настоящее время актуальной версией является TOGAF 9.1. TOGAF — наиболее широко распространенный и узнаваемый в мировой практике фреймворк.

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

Является на сегодняшний день наиболее распространенной методологией. С 2008 г. поддерживается ArchiMate для сквозного моделирования архитектуры. Поддерживается большинством вендоров в их методах и программных продуктах класса ЕА modeling tools.

Основное отличие от других методов построения архитектуры — наличие метода разработки архитектуры (Architecture Development Method —ADM), отвечающего на вопрос «КАК?». Материалы TOGAF содержат обширное количество примеров и шаблонов архитектурных артефактов, создаваемых на разных этапах ADM.

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

• • бизнес-архитектура (Business Architecture);
• • архитектура приложений (Application Architecture);
• • архитектура данных (Data Architecture);
• • технологическая архитектура (Technical Architecture).

TOGAF содержит (рис. 1.10):

• — метод разработки архитектуры (Architecture Development Method —ADM);
• — рекомендации к методу разработки архитектуры (ADM Guidelines and Techniques);
• — структуру/метамодель архитектурного контента (Architecture Content Framework);
• — континуум предприятия (The Enterprise Continuum);
• — референтные (справочные) модели (TOGAF Reference Models);
• — схему описания способностей (The Architecture Capability Framework).

Во время работы над архитектурой предприятия архитекторы создают документы, схемы, презентации, планы и т. д. Весь этот объем информации образует информационный контент архитектуры предприятия. Метамодель контента (рис. 1.11) — это инструмент организации архитектурной информации таким образом, чтобы она была сконцентрирована вокруг потребностей заинтересованных сторон (stakeholders-, см. подробнее п. 3.3).

В состав методологии входит понятие «континуум предприятия» (Enterprise Continuum) — «виртуальный репозиторий» всех архитектурных активов, существующих как внутри предприятия, так и в отрасли в целом (рис. 1.12, 1.13). Континуум предприятия — это накопитель таких ресурсов, как модели, шаблоны решений, каталоги и архитектурные продукты, которые могут использоваться как «строительные блоки» во всем процессе адаптации и реализации архитектуры предприятия.

В классе архитектурных продуктов появился «Строительный блок» (Building Block), он представляет собой компонент бизнеса, ИТ или архитектурную сущность (потенциально многократного использования), который может быть скомбинирован с другими строительными блоками для построения архитектур и решений. Относится к одному из двух типов —АВВ и SBB:

• — архитектурные строительные блоки (Architecture Building Blocks — ABB) обычно описывают необходимую результативность и формируют спецификации для строительных блоков решений (например, требуемая результативность клиентского сервиса может поддерживаться несколькими SBB, такими как процессы, данные и ПО);
• — строительные блоки решений (Solution Building Blocks — SBB) представляют собой компоненты, которые будут использоваться для обеспечения необходимой результативности (например, компьютерная сеть — строительный блок, который может быть описан через соответствующий артефакт и использоваться в конкретном решении для архитектуры предприятия).

TOGAF обладает таким важным свойством развития, как возможность расширения исходной метамодели путем добавления новых сущностей и архитектурных продуктов. Таким образом, сама методология является адаптируемой под конкретные нужды предприятия. Это свойство — одно из коренных свойств методологии TOGAF, которая сама по себе (т. е. в состоянии «как есть») не является абсолютно завершенной и одинаково подходящей для всех предприятий методологией,.

Рис. 1.10. Компоненты методологии TOGAF

Рис. 1.11. Метамодель контента методологии TOGAF.

Рис. 1.12. Континуум предприятия

¹ Configuration management database (CMDB) — база данных управления конфигурациями.

Рис. 1.13. Уровни континуума предприятия

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

Методология не регламентирует использование определенного инструмента моделирования или поддержки. На практике TOGAF поддерживается рядом компьютерных инструментов.

К основным преимуществам можно отнести:

• — универсальность, независимость от средств и поставщиков услуг;
• — наличие метода разработки (Architecture Development Method — ADM);
• — большое количество материалов и обсуждений в открытом доступе или за незначительную оплату;
• — масштабируемость метода (возможность применять как для организации в целом, так для конкретного ИТ-проекта).

Среди недостатков:

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

TOGAF ADM. Метод разработки архитектуры (Architecture Development Method — ADM) методологии TOGAF предоставляет законченный набор инструкций для реализации и выполнения АП в организации. Этот процесс состоит из нескольких последовательных фаз, замкнутых в цикл (рис. 1.14).

Рис. 1.14. Метод разработки архитектуры (ADM) TOGAF¹

Задача подготовительной фазы (Preliminary Phase) — выявление заинтересованных в процессе реализации лиц и обсуждение с ними задач АП. На этой фазе вырабатываются руководящие принципы архитектуры (Architecture Guiding Principles'), которые основываются на бизнес-принципах организации и описывают процессы и критерии для наблюдения за процессом реализации АП.

Фаза А этого процесса предназначена для выражения видения АП. Концепция архитектуры (Architecture Vision) использует движущие силы бизнеса, чтобы обозначить цель действий по созданию АП и создать описания первого реза для базовой и целевой среды. Если задачи бизнеса не ясны, то часть задания этой фазы — помочь бизнесу идентифицировать свои главные задачи и соответствующие процессы, которые должна поддерживать АП. На этой фазе создается специальный доку-^[1]

мент под названием «Задание на разработку архитектуры» (Statement of Architectural Work), очерчивающий область действия и условия АП.

Фаза В предназначена для детальной разработки архитектуры предметной области бизнеса. И базовая, и целевая архитектура, которые очерчены в документе «Концепция архитектуры», детализируются, чтобы получить полезные входные данные для технического анализа. На этой фазе используются различные методики и нотации бизнес-моделирования.

Фаза С связана с созданием архитектуры предметных областей «Приложение» и «Данные (Информация)». На этой фазе производится описание текущей и разработка целевой архитектуры информационных систем. Для этого также используются специальные методики, подходы и нотации, связанные с данными и приложениями.

Фаза D фокусируется на описании и разработке технологической архитектуры (сети, вычислительные устройства, узлы, технологические интерфейсы и т. п.).

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

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

После утверждения спецификации проекта фокус перемещается на формулирование более конкретных условий и рекомендаций для каждого из проектов реализации. На протяжении фазы G устанавливается связь между управляющей архитектурой (TOGAF) и разрабатывающей организацией (которая может быть настроена при помощи RUP и Project Management Body of Knowledge (PMBOK), например, или каких-либо еще методологий управления проектом), а выбранные проекты реализуются под управлением формальной архитектуры. На выходе этой фазы мы имеем «Архитектурные контракты», утверждаемые организацией-разработчиком. Конечным выходом фазы G являются решения, совместимые с архитектурой.

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

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

• [1] Источник: The Open Group.