Разбираемся в методе на одном примере: сеть магазинов запускает самовывоз. Пройдём цикл ADM, свяжем бизнес, данные, приложения и технологии, выберем артефакты и составим план перехода.
Архитекторы нарисовали целевое состояние, проекты стартовали по своим планам, и через год схема описывает компанию, которой не будет. Между целью и реализацией не хватало метода — того, что связывает решение с работой.
Возьмём сеть из сорока магазинов, которая запускает самовывоз. Покупатель звонит в магазин, сотрудник ищет товар вручную и записывает заказ в таблицу; остатки на сайте отстают, заказ и отложенный товар не связаны общим идентификатором, ошибки обмена замечают после звонков покупателей. Это не задача «внедрить систему заказов»: чтобы самовывоз заработал, должны одновременно измениться процесс, данные, приложения и технологии, и у каждого изменения найтись владелец. Если проект стартует с одного из четырёх, остальные три догоняют его в аварийном режиме.
TOGAF — метод, который держит четыре домена вместе и ведёт от замысла до работающих изменений. Его ядро — цикл ADM (Architecture Development Method): подготовка, архитектурное видение (A), архитектуры бизнеса (B), данных и приложений (C), технологий (D), затем возможности и решения (E), планирование перехода (F), контроль реализации (G) и управление изменениями (H); управление требованиями сопровождает весь цикл. У каждой фазы есть вопрос, на который она отвечает, и результаты, которые можно проверить. К методу приложены метамодель содержимого и каталог артефактов, но, как напоминает сам стандарт, их выбирают под задачу, а не заполняют все подряд.
В этой раздатке — цикл ADM с вопросами каждой фазы, 48 из 163 карточек страницы реестра, 12 понятий с аналогиями, пример с самовывозом «сейчас — цель» по четырём доменам и дорожная карта из трёх промежуточных состояний, план первой недели. Стандарт десятой редакции — это сотни страниц; здесь то, что нужно, чтобы понять, зачем он, и пройти первый короткий цикл на своей задаче.
Архитектура нужна не для того, чтобы нарисовать цель. Она нужна, чтобы каждый проект знал, какую часть цели он реализует и по каким критериям его примут.
Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.
Есть сопоставление с 6 осями из 17
| Ось реестра | В TOGAF | Сопоставление | Пояснение |
|---|---|---|---|
| Информация и данные | Data Architectureархитектурный домен | Охват тот же, что у оси. | Логическая и физическая структура данных. |
| Приложения и информационные системы | Application Architectureархитектурный домен | Охват тот же, что у оси. | |
| Технологическая ИТ-инфраструктура | Technology Architectureархитектурный домен | Охват тот же, что у оси. | Технологическая инфраструктура и платформы; производственные активы TOGAF отдельно не выделяет. |
| Деятельность: функции и процессы + Организация и ответственность + Стратегия и способности | Business Architectureархитектурный домен | Шире оси: этот домен объединяет больше, чем одна общая ось. | TOGAF складывает в один домен структуру, процессы, организацию и бизнес-способности — в нейтральном наборе это три разных домена. |
| Делит по другому признаку | Architecture Principles, Vision and Requirements: Preliminary · Architecture Principles, Vision and Requirements: Architecture Requirements · Architecture Definition: Motivation · Architecture Definition: Business Architecture · Architecture Definition: Information Systems Architecture — Data · Architecture Definition: Information Systems Architecture — Application · Architecture Definition: Technology Architecture · Architecture Realization: Opportunities, Solutions & Migration Planningкатегория метамодели содержимого | Вне общих осей | Категория метамодели содержимого (Content Framework), а не домен предприятия: §2.1 называет её рамкой категоризации для структурирования описания архитектуры, а §3.11.2 — устроенной по фазам ADM. Четыре из восьми категорий носят те же имена, что настоящие домены TOGAF, и до 2026-09-07 считались в матрице вторично. |
| Делит по другому признаку | Preliminary Phase · Phase A: Architecture Vision · Phase B: Business Architecture · Phase C: Data Architecture · Phase C: Application Architecture · Phase D: Technology Architecture · Phase E: Opportunities and Solutions · Phase F: Migration Planning · Requirements Management · Phase G: Implementation Governance · Phase H: Architecture Change Managementфаза метода ADM | Вне общих осей | Фаза ADM — шаг метода, а не домен. Названия фаз B–D совпадают с названиями доменов TOGAF, и именно поэтому их легко перепутать: фаза — это когда работаем, домен — что описываем. |
Дополнительные измерения этого подхода: категория метамодели содержимого, фаза метода ADM.
Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.
Какое изменение бизнеса, зачем, для кого, в каких границах, кто участвует и кто принимает решения. Для самовывоза: «клиент оформляет заказ онлайн, магазин собирает и подтверждает; владелец процесса — директор розницы». Согласуйте с заказчиком — иначе у дальнейшей работы нет адресата.
Процесс, роли, ответственность, какие способности нужны. Не рисуйте всё предприятие — только то, что затрагивает изменение. Запишите разрывы: где нет владельца, где шаг выполняется вручную, где обещание клиенту ничем не подкреплено.
Какие сущности участвуют — товар, остаток, резерв, заказ, — у кого владелец и источник. Какие системы что делают сейчас и что должны делать: сервис заказов, учётная система, рабочее место магазина. Разрывы: несвязанные идентификаторы, ручные передачи, отставание остатков.
На какой инфраструктуре это будет работать, что с наблюдаемостью обмена, отказами, резервным копированием. Соберите все требования, всплывшие за три дня, в один список с приоритетами и привязкой к решениям — это первое приближение спецификации архитектурных требований.
Сгруппируйте разрывы в пакеты и разложите по промежуточным состояниям, у каждого — условие перехода: «достоверные остатки», «самовывоз в трёх точках», «масштабирование сети». Покажите заказчику, что компания получит после каждого состояния, чего оно стоит и от чего зависит.
Без предварительной фазы непонятно, кто утверждает архитектурные решения, где они хранятся и какие принципы обязательны. Работа начинается с видения, а через два месяца выясняется, что решения архитектора никому не обязательны. Достаточно одной страницы: роли, полномочия, принципы, репозиторий.
Требование «резерв должен подтверждаться за минуту» появилось в фазе B, а в фазе D его никто не помнит, и технологическая архитектура строится без него. Управление требованиями не случайно нарисовано в центре круга: у каждого требования должен быть след в решениях каждой фазы и проверка влияния при изменении.
Для первого цикла — нет. Видение, таблицы «сейчас — цель», список требований и дорожная карта умещаются в вики и электронные таблицы. Инструмент с репозиторием нужен, когда представлений становятся десятки и их надо держать согласованными; выбирают его по языку моделирования — обычно ArchiMate, — а не по стандарту.
Захман — онтология: сетка вопросов и перспектив, по которой раскладывают описания, без указания, в каком порядке их создавать. TOGAF — метод: что делать сначала, что потом, какие результаты у каждой фазы. Их сочетают: сетка Захмана помогает проверить полноту описания, ADM — организовать работу.
С одного изменения бизнеса и подготовки: договориться, кто и как принимает архитектурные решения, и пройти один короткий цикл на реальной задаче — как самовывоз в примере. Шаблоны не выбрасывайте: каталог артефактов — справочник, откуда берут представление под конкретный вопрос.
23 страницы: что это и чем не является, устройство подхода, 42 карточки словаря, 12 понятий с аналогиями, учебный пример и план первой недели.
Пришлём ссылку сразу после отправки формы
Дословные выписки из стандарта с переводом. Строки с пояснением простыми словами отмечены.
Понятия этого подхода с объяснениями, примерами и типичными ошибками.
Это версия стандарта TOGAF, подогнанная под конкретную организацию или проект.
Актор — тот, кто действует: человек, подразделение, организация или система.
Архитектурные строительные блоки — документация и модели из репозитория архитектуры предприятия: описания того, ЧТО нужно, безотносительно того, чем это будет реализовано.
Соглашение между заказчиком и командой разработки, фиксирующее ожидаемые результаты, качество и соответствие архитектуры поставленным целям.
Это единое хранилище для всех архитектурных проектов компании.
Это описание того, как бизнес понимает конкретный термин или понятие, включая его смысл и правила использования.
Подходы, которые описывают предприятие целиком — от стратегии и процессов до данных и ИТ-инфраструктуры: язык, рамка или метод со своей моделью.
Версия 1 разработана в 1995 году на основе Technical Architecture Framework for Information Management (TAFIM), созданного Министерством обороны США: DoD дало The Open Group прямое разрешение строить TOGAF на TAFIM. Стандарт разрабатывает и сопровождает Architecture Forum консорциума The Open Group.
Technical Corrigendum 1 к десятой редакции The Open Group утвердил к публикации в апреле 2025 года.
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийБаза знаний и викиРеестр процессов
