TOGAF

TOGAF (The Open Group Architecture Framework) — это методология разработки архитектуры предприятия (Enterprise Architecture, EA), представляющая собой комплексный подход к проектированию, планированию, внедрению и управлению информационной архитектурой организации. TOGAF разрабатывается и поддерживается консорциумом The Open Group и является одной из наиболее распространённых и признанных в мире методологий в области корпоративной архитектуры.

История

Разработка TOGAF началась в 1995 году на основе методологии Technical Architecture Framework for Information Management (TAFIM), созданной Министерством обороны США. Первая версия (TOGAF 1) была опубликована в 1996 году. Основной целью было создание открытого, не зависящего от конкретных поставщиков стандарта, который мог бы использоваться для построения архитектуры в государственных и коммерческих организациях.

Ключевые версии:

• TOGAF 7 (2001): Введение в качестве ядра методологии Architecture Development Method (ADM).
• TOGAF 8 (2002): Значительное расширение, включая Enterprise Continuum и Architecture Repository.
• TOGAF 9 (2009): Крупное обновление, добавившее модульность, гибкость и детализацию. Эта версия стала стандартом де-факто.
• TOGAF 9.2 (2018): Уточнение и доработка, акцент на гибкие (Agile) и цифровые подходы.
• TOGAF Standard, 10th Edition (2022): Переход к модульной структуре, разделение на базовое руководство (Core) и серию специализированных руководств (Series Guides). Упрощение сертификации и внедрения.

Основные компоненты методологии

TOGAF состоит из нескольких взаимосвязанных частей, которые вместе образуют целостную систему.

Architecture Development Method (ADM)

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

Фазы ADM:

1. Preliminary Phase (Подготовительная фаза): Определение объёма работ, принципов архитектуры, настройка инструментов и методов.
2. Phase A: Architecture Vision (Видение архитектуры): Формулирование стратегического видения, целей, заинтересованных сторон, утверждение Устава архитектуры.
3. Phase B: Business Architecture (Бизнес-архитектура): Описание бизнес-стратегии, процессов, организационной структуры, функций и ролей.
4. Phase C: Information Systems Architectures (Архитектуры информационных систем): Разработка архитектуры данных (Data Architecture) и приложений (Application Architecture).
5. Phase D: Technology Architecture (Технологическая архитектура): Описание технологической инфраструктуры, сетей, серверов, ПО, необходимого для поддержки архитектур предыдущих фаз.
6. Phase E: Opportunities and Solutions (Возможности и решения): Оценка текущего состояния, выявление разрывов (gaps), определение проектов и миграционных планов.
7. Phase F: Migration Planning (Планирование миграции): Детальное планирование перехода от текущей архитектуры (Baseline) к целевой (Target), определение приоритетов, сроков и ресурсов.
8. Phase G: Implementation Governance (Управление внедрением): Контроль за реализацией проектов в соответствии с архитектурой, управление изменениями.
9. Phase H: Architecture Change Management (Управление изменениями архитектуры): Постоянный мониторинг, оценка и управление изменениями в архитектуре после внедрения.
10. Requirements Management (Управление требованиями): Центральный процесс, пронизывающий все фазы ADM, обеспечивающий сбор, анализ, приоритизацию и отслеживание требований.

Enterprise Continuum

Enterprise Continuum — это классификация и репозиторий архитектурных активов, которые могут быть использованы при разработке. Он включает:

• Architecture Repository: Хранилище всех артефактов архитектуры (модели, принципы, стандарты, эталонные архитектуры).
• Foundation Architecture: Базовые, общие архитектурные строительные блоки (например, TOGAF Foundation Architecture — Technical Reference Model, TRM).
• Common Systems Architectures: Типовые архитектуры для распространённых отраслей или функций (например, финансы, производство).
• Industry Architectures: Архитектуры, специфичные для конкретных отраслей (например, здравоохранение, телекоммуникации).
• Organization-Specific Architectures: Архитектуры, разработанные для конкретной организации.

Content Framework

Content Framework определяет, какие артефакты (документы, модели, диаграммы, каталоги, матрицы) должны быть созданы на каждой фазе ADM. Он включает:

• Architecture Deliverables: Результаты работы (например, Архитектурное описание, План миграции).
• Architecture Artifacts: Конкретные элементы (например, диаграмма классов, карта процессов, каталог приложений).
• Building Blocks: Повторно используемые компоненты архитектуры.

Capability Framework

Capability Framework описывает, как организация должна управлять своей архитектурной практикой. Он включает:

• Architecture Governance: Процессы, роли, ответственность и правила управления архитектурой.
• Architecture Maturity Models: Модели оценки зрелости архитектурной практики (например, ACMM, NASCIO).
• Architecture Skills Framework: Набор навыков, знаний и компетенций, необходимых для архитекторов.

Применение и значение

TOGAF применяется в организациях различного масштаба и отраслей для:

• Снижения сложности: Упорядочивание IT-ландшафта, устранение дублирования, повышение эффективности.
• Повышения гибкости: Быстрая адаптация к изменениям бизнеса и рынка.
• Снижения рисков: Чёткое планирование и управление изменениями, минимизация ошибок при внедрении.
• Улучшения взаимодействия: Единый язык и методология для бизнеса и IT.
• Оптимизации затрат: Выявление неэффективных процессов и систем, обоснование инвестиций.

В России TOGAF используется в крупных государственных и коммерческих структурах, особенно в банковском секторе, телекоммуникациях, энергетике и промышленности. Однако его применение может быть ограничено в организациях, работающих с государственной тайной или в условиях строгих регуляторных требований, где предпочтение отдаётся отечественным стандартам и методологиям (например, ГОСТ Р 57100-2016, ГОСТ Р 57101-2016, ГОСТ Р 57102-2016).

Критика

Несмотря на широкое распространение, TOGAF подвергается критике по нескольким направлениям:

• Сложность и бюрократичность: Методология может быть излишне детализированной и формальной, что требует значительных ресурсов на внедрение и поддержание.
• Недостаточная гибкость: Критики утверждают, что ADM слишком жёсткий и не подходит для Agile-сред и стартапов.
• Слабая ориентация на бизнес-результаты: Некоторые считают, что TOGAF фокусируется на процессе, а не на достижении измеримых бизнес-ценностей.
• Отсутствие конкретных инструментов: TOGAF предоставляет методологию, но не даёт готовых инструментов или шаблонов, что требует дополнительной адаптации.
• Устаревание: В условиях быстрого развития облачных технологий, микросервисов и DevOps некоторые элементы TOGAF считаются устаревшими.

Тем не менее, TOGAF остаётся одним из наиболее зрелых и документированных подходов к архитектуре предприятия, и его использование часто является обязательным требованием для архитекторов в крупных проектах.

Источники

• The Open Group. TOGAF Standard, 10th Edition. 2022.
• The Open Group. TOGAF Version 9.2. 2018.
• The Open Group. TOGAF Version 9.1. 2011.
• The Open Group. TOGAF Version 8.1. 2003.
• The Open Group. TOGAF Version 7. 2001.
• The Open Group. TOGAF Version 1. 1996.
• The Open Group. Technical Architecture Framework for Information Management (TAFIM). 1993.
• The Open Group. Architecture Maturity Models. 2018.
• The Open Group. Architecture Skills Framework. 2018.