TOGAF

Общее #

TOGAF (The Open Group Architecture Framework) — стандарт для архитектуры предприятия, разрабатываемый и поддерживаемый консорциумом The Open Group в рамках Architecture Forum. Стандарт определяет общий язык, метод (ADM) и набор инструментов для планирования, проектирования, реализации и управления архитектурой предприятия.

Согласно TOGAF, предприятие (enterprise) — это любая совокупность организаций, у которых есть общие цели: корпорация целиком или её подразделение, государственное ведомство, цепочка географически распределённых организаций, консорциум или цепочка поставок. «Архитектура предприятия» при этом может охватывать как предприятие целиком, так и одну или несколько предметных областей внутри него.

Первая версия TOGAF (v1, 1995) создана на базе документа TAFIM (Technical Architecture Framework for Information Management), разработанного Министерством обороны США (US DoD), которое передало The Open Group права на дальнейшее развитие. Дальнейшие версии выпускались последовательно; ключевые редакции — TOGAF 9 (2009), 9.1 (2011), 9.2 (2018). Актуальная — The TOGAF Standard, 10th Edition (апрель 2022). Стандарт опубликован The Open Group и доступен для бесплатного просмотра и внутреннего использования организациями (с ограничениями на коммерческое использование).

TOGAF уделяет основное внимание не конкретным технологиям, а методу и принципам: стандарту описания предприятия, управлению изменениями и согласованности бизнес-стратегии с ИТ-ландшафтом. Поэтому фреймворк рассчитан на адаптацию (tailoring) под нужды конкретной организации.

Четыре архитектурных домена #

TOGAF делит архитектуру предприятия на четыре домена (по первым буквам — BDAT):

• Business Architecture (бизнес-архитектура) — стратегия, цели, бизнес-процессы, роли, организационная структура.
• Data Architecture (архитектура данных) — структура данных предприятия, их хранение, управление, распространение.
• Application Architecture (архитектура приложений) — приложения и их взаимодействие, поддерживающие бизнес-процессы и работу с данными.
• Technology Architecture (технологическая архитектура) — ИТ-инфраструктура: вычислительные и сетевые ресурсы, системное ПО.

Архитектуры данных и приложений вместе образуют Information Systems Architectures (архитектуры информационных систем) — именно так в ADM называется фаза C.

Состав стандарта #

The TOGAF Standard, 10th Edition состоит из двух частей: TOGAF Fundamental Content (ядро стандарта, шесть документов) и Extended Guidance (расширенное руководство, известное как TOGAF Library — руководства, white papers).

Документы Fundamental Content:

1. Introduction and Core Concepts (введение и базовые понятия) — определения, цели архитектуры предприятия, условия использования.
2. Architecture Development Method (метод разработки архитектуры, ADM) — ядро стандарта, итеративный цикл фаз от Preliminary до H.
3. ADM Techniques (техники ADM) — gap-анализ, бизнес-сценарии (Business Scenarios), планирование на основе возможностей (Capability-Based Planning), управление рисками и др.
4. Applying the ADM (применение ADM) — итерации, разбиение (Partitioning), архитектура безопасности (Security Architecture), SOA.
5. Architecture Content (архитектурный контент) — контент-фреймворк, Enterprise Metamodel, артефакты, строительные блоки, Enterprise Continuum, Architecture Repository.
6. Enterprise Architecture Capability and Governance (способность и руководство архитектурой предприятия) — Architecture Board, Architecture Governance, Architecture Compliance, Architecture Contract, Skills Framework, Maturity Models.

TOGAF Library (Extended Guidance) структурирован по направлениям: общие методики (Agile-спринты, Digital Enterprise), создание EA-команды, доменные руководства (бизнес-архитектура, данные, безопасность, устойчивость), эталонные модели (DBRM, GRM, MSA) и метод (Architecture Maturity Models, Architecture Project Management, Architecture Skills Framework).

ADM — метод разработки архитектуры #

ADM (Architecture Development Method) — ядро TOGAF: итеративный метод разработки и управления архитектурой предприятия. Цикл состоит из предварительной фазы (Preliminary Phase), восьми фаз с буквенными обозначениями A–H и управления требованиями (Requirements Management) как центрального непрерывного процесса, связывающего все фазы.

Цикл ADM выглядит так:

Предварительная фаза (Preliminary Phase)
   │  подготовка организации, принципы, tailoring
   ▼
┌──────────────────────────────────────────────────────────┐
│  A → B → C → D → E → F → G → H                          │
│                                                          │
│  A  Видение архитектуры        (Architecture Vision)     │
│  B  Бизнес-архитектура         (Business Architecture)   │
│  C  Архитектуры ИС             (Information Systems      │
│     (данные + приложения)        Architectures)          │
│  D  Технологическая             (Technology Architecture)│
│     архитектура                                          │
│  E  Возможности и решения      (Opportunities & Solutions)│
│  F  Планирование миграции      (Migration Planning)      │
│  G  Управление реализацией     (Implementation Governance)│
│  H  Управление изменениями     (Architecture Change      │
│     архитектуры                  Management)             │
└──────────────────────────────────────────────────────────┘
   ↕  Requirements Management — в центре, непрерывно     ↕
        ◀────────────  новая итерация цикла  ────────────▶

Важные свойства ADM:

• Итеративность. По итогам фазы H цикл может запускаться заново — для всего предприятия или для его части. Фазы тоже могут повторяться внутри одного цикла (например, возврат из C в B при уточнении требований).
• Адаптивность (Adapting the ADM). Стандарт явно требует подстраивать ADM под ситуацию: определять широту (breadth), глубину (depth), временной горизонт (time period) и охват доменов (architecture domains) — а также порядок разработки baseline/target (сначала текущее, потом целевое, или наоборот).
• Связь с репозиторием. На каждом шаге используются и пополняются ресурсы Architecture Repository (референсные модели, строительные блоки, стандарты).

Предварительная фаза (Preliminary Phase) #

Предварительная фаза готовит организацию к архитектурной работе — она выполняется до начала цикла и при необходимости повторяется. Шаги:

• Scope the Enterprise Organizations Impacted — определить охватываемые организации.
• Confirm Governance and Support Frameworks — подтвердить рамки управления и поддержки.
• Define and Establish Enterprise Architecture Team and Organization — сформировать команду и организационную модель архитектуры.
• Identify and Establish Architecture Principles — определить и утвердить архитектурные принципы (Architecture Principles).
• Tailor the TOGAF Framework — адаптировать TOGAF и при необходимости другие фреймворки под нужды организации (tailoring).
• Develop a Strategy and Implementation Plan for Tools and Techniques — стратегия по инструментам и техникам.

Ключевые выходы: Architecture Principles, Tailored Architecture Framework, Organizational Model for Enterprise Architecture, Request for Architecture Work (запрос на архитектурную работу), который запускает фазу A.

Фаза A: Видение архитектуры (Architecture Vision) #

Фаза A инициирует конкретный цикл архитектурной работы и формирует видение, которое получит поддержку руководства. Вход — Request for Architecture Work. Основные шаги:

• Establish the Architecture Project — сформировать проект архитектуры.
• Identify Stakeholders, Concerns, and Business Requirements — выявить стейкхолдеров, их опасения и бизнес-требования.
• Confirm and Elaborate Business Goals, Business Drivers, and Constraints — уточнить цели, драйверы и ограничения.
• Evaluate Capabilities — оценить бизнес- и архитектурные возможности (capabilities).
• Assess Readiness for Business Transformation — оценить готовность к трансформации.
• Define Scope — определить границы (широта, глубина, период, домены).
• Confirm and Elaborate Architecture Principles — подтвердить и детализировать принципы.
• Develop Architecture Vision — разработать видение архитектуры.
• Define the Target Architecture Value Propositions and KPIs — ценностные предложения и метрики.
• Identify the Business Transformation Risks and Mitigation Activities — риски и меры реагирования.
• Develop Statement of Architecture Work; Secure Approval — подготовить и утвердить Statement of Architecture Work (главный управленческий артефакт фазы).

Ключевые выходы: Architecture Vision, утверждённый Statement of Architecture Work, Communications Plan, Capability Assessment. Здесь же применяется техника Business Scenarios для выявления требований.

Фазы B/C/D: доменные архитектуры #

Бизнес-архитектура (B), архитектуры информационных систем (C: данные и приложения) и технологическая архитектура (D) разрабатываются по единому девятишаговому скелету — одинаковому для всех трёх доменов:

1. Select Reference Models, Viewpoints, and Tools — выбрать референсные модели, точки зрения, инструменты.
2. Develop Baseline Architecture Description — описать текущее состояние (baseline).
3. Develop Target Architecture Description — описать целевое состояние (target).
4. Perform Gap Analysis — провести gap-анализ между baseline и target.
5. Define Candidate Roadmap Components — выделить кандидаты в дорожную карту.
6. Resolve Impacts Across the Architecture Landscape — разрешить влияния на остальной архитектурный ландшафт.
7. Conduct Formal Stakeholder Review — провести формальное ревью со стейкхолдерами.
8. Finalize the Architecture — финализировать архитектуру домена.
9. Create/Update the Architecture Definition Document — создать/обновить Architecture Definition Document.

Общие выходы этих фаз — Architecture Definition Document (описание архитектуры) и Architecture Requirements Specification (спецификация требований к архитектуре), а также компоненты Architecture Roadmap.

Фаза B: Бизнес-архитектура (Business Architecture) #

Помимо общего скелета, фаза B в TOGAF 10 опирается на набор связанных методов моделирования:

• Business Capability Mapping — карта бизнес-возможностей (независимо от оргструктуры и процессов).
• Value Streams — потоки ценности (как возможности создают ценность для конкретных стейкхолдеров).
• Organization Mapping — карта организации (бизнес-единицы и их связи, в т. ч. с третьими сторонами).
• Information Mapping — информационные карты (концепты и домены информации, значимые для бизнеса).

Бизнес-архитектура — фундамент остальных доменов: без понимания бизнеса данные, приложения и инфраструктура проектируются «вслепую».

Фаза C: Архитектуры информационных систем (Information Systems Architectures) #

Фаза C объединяет две связанные архитектуры, каждую — по тому же девятишаговому скелету:

• Data Architecture (архитектура данных) — логические и физические структуры данных, управление данными, миграция и governance данных.
• Application Architecture (архитектура приложений) — портфель приложений, их интерфейсы и взаимодействие, поддержка бизнес-процессов.

Артефакты фазы C включают каталоги сущностей данных и приложений, матрицы «приложение/данные», диаграммы рассылки данных, диаграммы коммуникации приложений и др.

Фаза D: Технологическая архитектура (Technology Architecture) #

Фаза D описывает ИТ-инфраструктуру, поддерживающую архитектуры данных и приложений: вычислительные платформы, сети, системное и промежуточное ПО, среды развёртывания. Шаги те же, плюс шаг Select Services (выбор технологических сервисов). Выходы — компоненты Technology Architecture для Architecture Definition Document и Roadmap.

Фаза E: Возможности и решения (Opportunities and Solutions) #

Фаза E превращает архитектуры B–D в план реализации. Это не «план реализации» в проектном смысле — это фаза выявления возможностей и формирования стратегии миграции. Основные шаги:

• Review and Consolidate Gap Analysis Results from Phases B to D — собрать результаты gap-анализа.
• Review Consolidated Requirements Across Related Business Functions — сверить требования по смежным функциям.
• Consolidate and Reconcile Interoperability Requirements — согласовать требования к интероперабельности.
• Refine and Validate Dependencies — уточнить и проверить зависимости.
• Confirm Readiness and Risk for Business Transformation — подтвердить готовность и риски.
• Formulate Implementation and Migration Strategy — сформировать стратегию реализации и миграции.
• Identify and Group Major Work Packages — выделить и сгруппировать рабочие пакеты (work packages).
• Identify Transition Architectures — определить промежуточные архитектуры (Transition Architectures).
• Create the Architecture Roadmap & Implementation and Migration Plan — сформировать дорожную карту и план.

Ключевая концепция фазы E — Transition Architectures: промежуточные состояния между baseline и target, которые позволяют двигаться к целевой архитектуре поэтапно.

Фаза F: Планирование миграции (Migration Planning) #

Фаза F превращает стратегию из E в конкретный план миграции с приоритизацией. Основные шаги:

• Confirm Management Framework Interactions — согласовать взаимодействие с управленческими рамками (проектное управление, управление портфелем и т. п.).
• Assign a Business Value to Each Work Package — оценить бизнес-ценность каждого рабочего пакета.
• Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle — оценить ресурсы, сроки, способ доставки.
• Prioritize the Migration Projects through Cost/Benefit Assessment and Risk Validation — приоритизировать проекты через cost/benefit и валидацию рисков.
• Confirm Architecture Roadmap and Update ADD — подтвердить дорожную карту и обновить Architecture Definition Document.
• Complete the Implementation and Migration Plan — финализировать план реализации и миграции.
• Complete the Architecture Development Cycle and Document Lessons Learned — закрыть цикл разработки архитектуры и зафиксировать извлечённые уроки.

Главный выход фазы F — Implementation and Migration Plan (план реализации и миграции).

Фаза G: Управление реализацией (Implementation Governance) #

Фаза G — это управление соответствием (governance) в ходе реализации конкретных проектов, а не операционная эксплуатация (SLA, инциденты, поддержка пользователей — это сфера ITIL/ITSM, а не TOGAF). Основные шаги:

• Confirm Scope and Priorities for Deployment — подтвердить границы и приоритеты развёртывания.
• Identify Deployment Resources and Skills — выявить ресурсы и компетенции для развёртывания.
• Guide Development of Solutions Deployment — сопровождать разработку и развёртывание решений.
• Perform Enterprise Architecture Compliance Reviews — провести проверки соответствия архитектуре (compliance reviews).
• Implement Business and IT Operations — внедрить бизнес- и ИТ-операции.
• Perform Post-Implementation Review and Close the Implementation — провести post-implementation review и закрыть реализацию.

Ключевые инструменты фазы G — Architecture Contract (контракт между архитектурной функцией и исполнителями) и Compliance Assessment (оценка соответствия). Архитектор здесь выступает гарантом того, что реализованное решение соответствует утверждённой архитектуре, а при отклонениях выдаёт диспенсацию (dispensation) с обоснованием.

Фаза H: Управление изменениями архитектуры (Architecture Change Management) #

Фаза H обеспечивает, что развёрнутая архитектура продолжает приносить ценность и контролируемо эволюционирует. Основные шаги:

• Establish Value Realization Process — наладить процесс реализации ценности.
• Deploy Monitoring Tools — развернуть инструменты мониторинга (технологии, бизнес, качество сервиса, зрелость).
• Manage Risks — управлять рисками архитектуры предприятия.
• Provide Analysis for Architecture Change Management — анализ производительности и Change Requests.
• Develop Change Requirements to Meet Performance Targets — требования к изменениям для достижения целевых показателей.
• Manage Governance Process — управлять процессом через Architecture Board.
• Activate the Process to Implement Change — запустить процесс реализации изменений.

Изменения классифицируются на три категории (12.5.2 Enterprise Architecture Change Management Process):

• Simplification change (упрощение) — обычно решается средствами управления изменениями; часто вызвано потребностью сократить инвестиции.
• Incremental change (инкрементальное) — может решаться управлением изменений либо требовать частичного перепроектирования; связано с получением дополнительной ценности от существующих инвестиций.
• Re-architecting change (перепроектирование) — требует повторного прохождения цикла ADM; связано с новыми инвестициями ради новой ценности.

Практическое правило (maintenance vs redesign): если изменение затрагивает двух и более стейкхолдеров — скорее всего нужен архитектурный редизайн и повторный вход в ADM; если одного — кандидат на управление изменениями. Выход фазы H при крупных изменениях — новый Request for Architecture Work, запускающий следующую итерацию цикла.

Управление требованиями (Requirements Management) #

Requirements Management — это не «девятая фаза», а центральный непрерывный процесс, изображаемый в середине диаграммы ADM. Он связывает все фазы: требования собираются, документируются, оцениваются и передаются между фазами. Применяется техника Business Scenarios. Требования хранятся в Architecture Requirements Repository части Architecture Repository; для оценки влияния изменений требований используется Requirements Impact Assessment.

Архитектурный контент (Architecture Content) #

Документ Architecture Content определяет, что именно производится в ходе ADM. Контент-фреймворк (TOGAF Content Framework) классифицирует выходы на три категории и опирается на Enterprise Metamodel.

Артефакты, деливераблы и строительные блоки #

• Артефакты (Artifacts) — элементы описания архитектуры; бывают ровно трёх типов: каталоги (catalogs, иерархические перечни строительных блоков), матрицы (matrices, отношения между сущностями) и диаграммы (diagrams, представления). Примеры по фазам: для B — Organization/Actor Catalog, Business Capability Map, Value Stream Map; для C (данные) — Data Entity/Data Component Catalog, Logical Data Diagram; для C (приложения) — Application Portfolio Catalog, Application Communication Diagram; для D — Technology Standards Catalog, Network and Communications Diagram.
• Поставляемые результаты (Deliverables) — формально утверждаемые работы, контрактно передаваемые стейкхолдерам. Их перечень фиксирован стандартом: Architecture Vision, Statement of Architecture Work, Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap, Architecture Contract, Compliance Assessment, Implementation and Migration Plan, Implementation Governance Model, Capability Assessment, Communications Plan и др.
• Строительные блоки (Building Blocks) — переиспользуемые компоненты архитектуры; делятся на Architecture Building Blocks (ABB) — описывают «что» нужно и «как» это сочетается с другими блоками (спецификация), и Solution Building Blocks (SBB) — описывают «как» это реализуется (продукт/сервис). Соответствие ABB→SBB — основа перехода от архитектуры к реализации.

TOGAF Enterprise Metamodel #

Enterprise Metamodel (в TOGAF 10 переименован из «Content Metamodel») — формальная модель, задающая сущности, атрибуты и отношения архитектурного контента, обеспечивая связность артефактов из разных доменов и фаз. Модель структурирована по слоям (от принципов и стратегии до технологий) и сопровождается расширениями: Governance (управление), Services (сервисы), Process Modeling (моделирование процессов), Data (данные), Infrastructure Consolidation (консолидация инфраструктуры), Motivation (мотивация/стратегия). Метамодель — то, что превращает набор разрозненных диаграмм в целостное, связанное описание предприятия.

Enterprise Continuum #

Enterprise Continuum (континуум предприятия) — это схема классификации архитектурных активов (как Architecture Building Blocks, так и Solution Building Blocks), а не само хранилище: физически активы хранятся в Architecture Repository, а Enterprise Continuum задаёт способ их упорядочивания от общих к специфичным. Континуум предприятия состоит из двух взаимодополняющих частей.

Континуум архитектур (Architecture Continuum) классифицирует Architecture Building Blocks и проходит четыре уровня слева направо:

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

Континуум решений (Solutions Continuum) параллельно классифицирует Solution Building Blocks:

• Foundation Solutions — фундаментальные решения (продукты/сервисы, реализующие фундаментальные архитектуры).
• Common Systems Solutions — решения общих систем.
• Industry Solutions — отраслевые решения.
• Organization-Specific Solutions — решения конкретной организации.

Связь между двумя континуумами: Architecture Continuum задаёт нормативные модели (что и зачем), а Solutions Continuum — их конкретные реализации (как). По мере накопления опыта собственные решения организации могут обобщаться и «подниматься» влево по континууму, становясь переиспользуемыми активами.

Architecture Repository #

Architecture Repository (архитектурный репозиторий) — физическое хранилище всех выходов архитектурной работы, классифицированных через Enterprise Continuum. Состоит из разделов:

• Architecture Landscape — ландшафт архитектур предприятия (текущие и целевые архитектуры разных уровней: стратегический, сегментный, capability).
• Reference Library — библиотека референсных моделей (стандарты, шаблоны, отраслевые модели).
• Standards Library — библиотека стандартов (стандарты, обязательные к применению, с их жизненным циклом).
• Governance Repository — репозиторий управления (Architecture Board approvals, Architecture Contracts, Compliance Assessments, dispensations).
• Architecture Requirements Repository — репозиторий требований (требования, gap-анализ, требования к интероперабельности).
• Solutions Landscape — ландшафт решений (реализованные и планируемые решения, SBB).
• Enterprise Repository — общеорганизационной контекст, связывающий архитектуру с другими корпоративными данными.

Архитектурный репозиторий — рабочий инструмент ADM: на каждой фазе из него берут референсные модели и строительные блоки (вход) и пополняют его новыми артефактами (выход).

Способность и руководство архитектурой (EA Capability and Governance) #

Помимо метода (ADM) и контента, TOGAF описывает организационную способность предприятия вести архитектурную работу. Документ Enterprise Architecture Capability and Governance (в TOGAF 10) и связанные руководства покрывают:

• Architecture Board — коллегиальный орган, принимающий архитектурные решения, утверждающий контракты и Change Requests.
• Architecture Governance — рамка управления архитектурой: процессы, принципы, критерии соответствия.
• Architecture Compliance — процесс проверки соответствия решений утверждённой архитектуре (compliance reviews, диспенсации).
• Architecture Contract — формальное соглашение между архитектурной функцией и исполнителями/бизнесом.
• Architecture Capability — организационная способность вести EA-работу (команда, процессы, инструменты, зрелость).
• Architecture Skills Framework — справочник ролей и требуемых компетенций архитекторов.
• Architecture Maturity Models — модели оценки зрелости архитектурной функции (на базе CMMI).

Здесь же — Architecture Principles (архитектурные принципы), формируемые ещё на предварительной фазе и управляющие всеми решениями на протяжении цикла.

Когда используется TOGAF #

TOGAF уместен там, где нужен системный подход к архитектуре крупного предприятия:

• Масштабные трансформации и цифровизация — согласование бизнес-стратегии с ИТ-ландшафтом при множестве систем и зависимостей.
• Слияния, поглощения, консолидация ИТ — приведение разрозненных ландшафтов к единой архитектуре.
• Длинноживущие предприятия с накопленным техническим долгом — управляемая миграция через Transition Architectures.
• Регулируемые отрасли — необходимость формальной документации архитектуры и прослеживаемости требований (в т. ч. для требований приватности данных).

TOGAF плохо подходит малым проектам и коротким горизонтам — накладные расходы на фазы и артефакты не окупаются. В таких случаях берут отдельные элементы (например, принципы или gap-анализ), а не цикл ADM целиком.

Критика и ограничения #

• Тяжеловесность. Полный цикл ADM с формальной структурой артефактов избыточен для небольших организаций и agile-команд.
• Слабая связь с Agile/DevOps в базовом стандарте. Agile-поддержка вынесена в отдельные руководства TOGAF Library (Enabling Enterprise Agility, Applying the TOGAF ADM using Agile Sprints) — в ядре метода она не встроена.
• Абстрактность. Стандарт описывает «что» и «в каком порядке», но оставляет выбор конкретных техник моделирования и инструментов на усмотрение организации.
• Сам по себе не даёт бизнес-ценности. TOGAF — каркас метода; результат зависит от того, как организация его наполнит и свяжет с реальными проектами.

См. также #

• Введение в архитектуру — базовый контекст понятия «архитектура».
• High-Level Design и Low-Level Design — переход от архитектуры предприятия к проектному проектированию.
• Architecture Decision Records — фиксация архитектурных решений (в TOGAF коррелирует с Architecture Principles).
• Эволюционная архитектура — управляемые изменения как дополнение к формальному циклу ADM.
• Роль: Архитектор ПО — кто применяет TOGAF на практике.

Источники и материалы #

Первоисточники #

• The Open Group. The TOGAF® Standard, 10th Edition. — pubs.opengroup.org/togaf-standard/ (Architecture Development Method: chap02–chap13; Architecture Content: chap01–chap07; Introduction and Core Concepts). Опубликован в 2022 г., доступен для просмотра онлайн.
• The Open Group. TOGAF Library — pubs.opengroup.org/togaf-library (Series Guides: Business Capabilities, Value Streams, Organization Mapping, Information Mapping, Business Scenarios и др.).
• The Open Group. TOGAF® Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM.

Связанные материалы базы знаний #

• Architecture Decision Records — связь Architecture Principles с фиксацией решений.
• Эволюционная архитектура — итеративность ADM и фитнес-функции как дополнения.
• Введение в архитектуру — терминологическая база.