TOGAF — что это, из чего состоит и чем десятая редакция отличается от 9.2

Зачем вам TOGAF

Знакомая картина: в компании десятки программ, каждый отдел завёл свою, и между собой они не дружат. Склад считает остатки в одной системе, бухгалтерия — в другой, сайт показывает третье. Отделы говорят на разных языках, а общей картины нет ни у кого.

Архитектура предприятия отвечает на пять вопросов. Как у нас устроено сейчас? Как должно быть? Чем одно отличается от другого? Как перейти от первого ко второму? И не уходят ли деньги на ИТ мимо целей компании? TOGAF — способ отвечать на эти вопросы одинаково каждый раз.

Коротко, для тех, кто решает:

• Кому. Тем, кто отвечает за ИТ целиком: ИТ-директору, руководителю развития, архитектору. Руководителю проекта — чтобы понимать, откуда берутся требования.
• В какой ситуации. Систем больше десятка, никто не может показать общую картину, каждый проект начинает описание с чистого листа.
• Когда. Перед крупной перестройкой: заменой учётной системы, слиянием компаний, переездом в облако.
• Что нужно, чтобы сработало. Человек с полномочиями решать, какие системы подключаем, и договорённость, что такие решения проходят через него.

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

Что такое TOGAF

TOGAF — свод правил и шагов о том, как строить архитектуру предприятия. Выпускает его The Open Group, международное объединение ИТ-компаний1.

Слово «архитектура» здесь значит то же, что у здания: описание того, из чего состоит компания и как части связаны между собой. Только вместо стен и перекрытий — бизнес-процессы, данные, программы и серверы. Архитектор проектирует и следит за стройкой, а строит прораб.

Слово «предприятие» у TOGAF шире привычного. Это не только вся корпорация: метод одинаково применим к одному подразделению, к ведомству и к цепочке из компании, её поставщиков и клиентов6. Поэтому начать можно с одного департамента.

Архитектуру предприятия — её ещё называют корпоративной архитектурой — TOGAF рассматривает с четырёх сторон — как этажи одного здания6:

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

Сразу о версии: текущая редакция — десятая, вышла в апреле 2022 года12. Ссылки на редакцию 9.2 до сих пор встречаются в требованиях вакансий и в резюме, хотя она уже не актуальная.

Свод бесплатен для некоммерческого использования и скачивается со страницы загрузки The Open Group после регистрации5; самого текста стандарта здесь нет. Дальше — что вы найдёте в своде, откуда он взялся и как его применяют.

Откуда он взялся

TOGAF вырос из TAFIM — методики Министерства обороны США по технической архитектуре информационных систем; первая версия вышла в 1995 году4. Отсюда обстоятельность и внимание к процедуре: одни считают это силой свода, другие — избыточной тяжестью.

За развитие и сопровождение стандарта отвечает архитектурный форум внутри The Open Group3. Свод живой: в мае 2025 года к десятой редакции вышла техническая поправка, с ней стандарт сейчас и публикуется3.

В России

Прямого ГОСТ-аналога нет: поиск по базе Росстандарта не находит ни одного документа7. Смежный стандарт есть — ГОСТ Р ИСО 15704-2022 «Моделирование и архитектура предприятия»: он задаёт требования к таким методикам, но ни одной из них не описывает7. Это не русская версия TOGAF.

В вузах метод при этом преподают. Учебное пособие «Архитектура предприятия» Томского университета систем управления и радиоэлектроники разбирает TOGAF отдельным разделом. Фазы там обозначены теми же буквами, что и в оригинале, — правда, по редакции 9 2009 года9.

Как устроен метод: цикл ADM

Сердце TOGAF — цикл разработки архитектуры, по-английски Architecture Development Method, коротко ADMЦикл разработки архитектурыПоследовательность фаз, которой архитектуру предприятия доводят от бизнес-цели до принятых решений и плана перехода.The TOGAF Standard, часть о методе разработки архитектуры6. Если убрать буквы, в цикле три человеческих этапа: договориться, зачем и кто; описать, как есть и как должно быть; перейти и удержать.

Дальше те же этапы буквами — так фазы называют на курсах и в вакансиях. У каждой фазы есть результат: то, что остаётся в руках, когда она закончена6.

Договориться. Предварительная фаза — настроить метод под организацию и решить, кто за архитектуру отвечает. Фаза A, видение архитектуры, — зачем всё затеяли и чего ждём; на выходе утверждённое задание на архитектурную работу6.

Описать, как есть и как должно быть. Фазы B, C и D названы по трём сторонам архитектуры: бизнес, данные и приложения, технологии. На каждой описывают два состояния — «как есть» и «как должно быть», — а разницу между ними TOGAF называет разрывом. Из разрывов складывается дорожная карта: что менять и в каком порядке6.

Перейти и удержать. Фаза E, возможности и решения, собирает первую версию дорожной карты и решает, идти сразу или через промежуточные, переходные состояния. Фаза F, планирование перехода, превращает карту в план с пакетами работ и сроками. Фаза G, надзор за внедрением, проверяет, что проекты строят то, что решили6. Здесь граница с ITIL: надзор за стройкой — не эксплуатация. Инциденты, уровни услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation и поддержка живут в другом своде.

Фаза H, управление изменениями архитектуры, — что делать с новым запросом. TOGAF делит изменения на три вида: упрощение и небольшое добавление проводят обычной процедурой, а перепроектирование отправляет весь цикл на новый круг6.

Управление требованиями на схеме стоит под всеми фазами. Требования приходят и меняются в любой момент, и метод не даёт им потеряться на переходе от фазы к фазе6.

Пример на весь цикл. Интернет-магазин: заказы собираются медленно, клиенты уходят. Видение — собирать вдвое быстрее. «Как есть»: заказ вручную переносят с сайта на склад. «Как должно быть»: сайт и склад обмениваются данными сами, как две информационные системы, а не два отдела. Разрыв — обмена нет. Дорожная карта — сначала обмен по заказам, потом по остаткам. Переходное состояние — полгода работают и старая выгрузка, и новый обмен. Надзор — проверить, что подрядчик сделал обмен, а не ещё одну выгрузку. Новый круг — когда откроется второй склад.

Порядок фаз можно менять: TOGAF прямо разрешает подстраивать его под то, насколько архитектурная работа в организации уже поставлена6.

Что ещё нужно знать, если будете читать сам свод

TOGAF состоит из двух блоков3. Первый — шесть документов: введение и ключевые понятия; метод разработки архитектуры; техники к нему; его применение на практике; содержание архитектурных описаний; устройство архитектурной работы и руководство ею3. Второй блок — серия руководств о том, как подстроить первый под свою задачу.

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

Блоки бывают двух видов. Архитектурный блок говорит, какая способность нужна: «единый вход для обращений клиентов». Блок решения отвечает, чем её обеспечат: вот эта система, вот этот канал связи6. Подписывают документ, а переиспользуют блок — поэтому компания, которая копит документы вместо блоков, каждый раз проектирует заново.

Континуум и репозиторий. Континуум — способ разложить накопленные описания по степени общности: от годных кому угодно до сделанных под эту компанию. Репозиторий — хранилище, где они лежат и откуда их берут6. Вместе они отвечают на вопрос «почему мы третий год рисуем одно и то же».

Всё выше разобрано по полному тексту редакции 9.26. Читателю десятой это не помешает: набор документов в ней тот же, и цикл по-прежнему в центре свода3.

Кто это делает и кому полезно

Как на стройке: архитектор проектирует и следит за стройкой, а прораб строит. Корпоративный архитектор проектирует переход и ведёт цикл; руководитель проекта строит по дорожной карте. В небольшой компании это может быть один человек, если у него хватает полномочий и знаний.

Что даёт каждому:

• ИТ-директору — общую картину и аргументы для бюджета;
• руководителю проекта — понимание, откуда берутся требования;
• аналитику — язык «как есть / как должно быть»;
• разработчику — ответ, почему его система обязана обмениваться данными по общим правилам.

Сколько стоит и как сертифицируются

Сам стандарт бесплатен для некоммерческого использования5. Порядок такой: личная лицензия на девяносто дней, чтобы ознакомиться; потом бессрочная, на использование внутри своей компании; обе бесплатны. Для коммерческого использования нужна платная годовая лицензия5. Цены владелец в тексте страницы не показывает, поэтому сумм здесь нет.

Деньги берут за обучение и сертификацию. Правообладатель ведёт собственные сертификации сразу по двум редакциям — 9.2 и десятой; подготовка занимает от нескольких часов до многодневных курсов8. Сертификации с названием «TOGAF 10» нет: новые уровни названы по компетенциям, а не по номеру редакции8. Прежде чем платить за курс, посмотрите, какой редакции он соответствует.

О спросе стоит судить осторожнее, чем обещает реклама курсов: в нашей выборке из 894 вакансий TOGAF назван дважды — реже, чем ArchiMate, и несопоставимо реже, чем ITIL. Живые вакансии, где TOGAF назван, вместе с зарубежными собраны в списке на странице спроса.

Где ломается применение

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

Ссылаются на редакцию 9.2. Текущая — десятая1.

Рисуют схемы вместо решений. Артефакт без принятого решения и владельца остаётся картинкой.

Заводят архитектора без полномочий. Если решения о системах принимаются мимо него, метод превращается в документооборот.

Копят документы вместо блоков. Признак — каждый новый проект начинает описание с чистого листа, хотя папка с прежними согласованиями растёт.

С чего начать

Без трёх условий цикл не запускается: нужен список тех, кто заинтересован и кто решает; описание того, что уже есть — системы и связи между ними; и цели компании, к которым всё привязано.

1. Ограничьте охват. У TOGAF на это четыре мерки: часть предприятия, подробность, срок и число сторон архитектуры из четырёх6.
2. Возьмите одну болезненную область — например, обмен данными между системами — и пройдите по ней сокращённый цикл: как есть, как должно быть, что мешает, какой первый шаг.
3. Договоритесь, какие решения обязаны проходить через архитектора, а какие нет. Без этого метод не работает.
4. И только потом расширяйте охват на другие области.

Плюсы и минусы

За. Повторяемый порядок: другая команда пройдёт те же шаги и получит описание того же вида. Общий язык для бизнеса и ИТ: «как есть», «как должно быть», разрыв, дорожная карта. У каждой фазы есть результат и согласование. Стандарт бесплатен для внутреннего применения5 и соединяется с другими сводами: в редакции 9.2 названы ITIL, COBIT, CMMI, PRINCE2 и PMBOK6.

Против. Тяжёл и рассчитан на масштаб. Сам по себе пользы не приносит: без архитектора с полномочиями превращается в документооборот. Повседневную работу с услугами не описывает — для этого нужен ITIL.

Что покрывает — и чего не покрывает

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

Практики, которые описывает свод:

Заполнены немногие, и это свойство TOGAF, а не недостаток. Он про архитектуру предприятия, а не про повседневную работу ИТ.

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

Чем отличается от соседей

От ArchiMate — языка схем. TOGAF говорит, что делать и в каком порядке; ArchiMate — как это нарисовать на общем языке. Оба стандарта принадлежат The Open Group, и на практике их применяют вместе.

От схемы Захмана — таблицы-классификатора. Схема говорит, какие описания должны существовать; TOGAF — как их получить и кто согласует.

От IT4IT — эталонной модели самой ИТ-службы. IT4IT описывает данные и связи внутри ИТ, TOGAF — архитектуру всего предприятия.

От ITIL — свода о повседневной работе с услугами. Пересечение почти нулевое: там поддержка и уровни услуг, здесь — проектирование целевого состояния и переход к нему. TOGAF не считает соседей помехой: редакция 9.2 прямо велит соединять метод с ними, а IT4IT называет справочным материалом своей библиотеки6.

Что читать дальше

Три свода рядом: ArchiMate — язык, которым архитектуру рисуют, IT4IT — эталонная модель для управления самой ИТ-службой, схема Захмана — классификация, с которой в этой области всё начиналось.