Абстрактная 3D-иллюстрация региональных данных и ситуационного центра. Практический метод формирования целевой архитектуры
Короткий ответ

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

01

Что делать на практике

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

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

02

Роль источника SystemsDesign

SystemsDesign содержит страницу доклада Максима Кантаровича о целевых архитектурных моделях. Максим Кантарович указан здесь как спикер; страница мероприятия не приписывается ему как авторская статья.

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

03

Объекты, идентификаторы и владельцы

Границу описывают карточками объектов, а не названиями систем. Для объекта «инициативы, зависимости и ресурсы» карточка содержит смысл, идентификатор, источник, владельца качества и событие обновления; для объекта «цели и управленческие решения» дополнительно фиксируется правило связи.

Разрыв между объектами «инициативы, зависимости и ресурсы» и «цели и управленческие решения» проверяют на сквозном примере. Команда выполняет действие «сопоставить приложения и данные», прослеживает преобразования и устанавливает, где возникает расхождение, кто его исправляет и какие зависимые результаты пересчитываются.

  • Граница 1. Объект: Цели и управленческие решения. Для него задаются источник, периодичность, допустимые преобразования и реакция на сигнал «несогласованные карты систем».
  • Объект 2: Возможности и процессы. Поля карточки: источник, владелец смысла, владелец качества, правило актуализации. Контрольный сигнал: Показатели без владельцев решений.
  • Предметная область 3: Данные и показатели. Основание проверки: системный источник, полномочия владельца и признак «инвестиции без целевого состояния».
04

Источники и интеграции

Обмен данными описывается как контракт между владельцами. Для объекта «цели и управленческие решения» указываются инициирующее событие, системный источник, обязательные поля, контроль до передачи и реакция получателя на ошибку.

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

  • Контрольная запись 5. Объект: Инициативы, зависимости и ресурсы. Наблюдаемый признак: Конкурирующие инициативы без общих критериев. Ответственность: владелец смысла и владелец качества.
  • Карточка 4. Объект: Системы и интеграции. Обязательные сведения: идентификатор, происхождение, правило качества и событие обновления. Сигнал: Повторяющиеся разрывы между стратегией и проектами.
  • Предметная область 3: Данные и показатели. Основание проверки: системный источник, полномочия владельца и признак «инвестиции без целевого состояния».
05

Сервисы и критичные зависимости

Для объекта «цели и управленческие решения» последовательность начинается с действия «сформировать целевые переходы». Его выход проверяет владелец следующего шага; неполный результат возвращается с конкретным замечанием к данным, правилу, полномочию или архитектурной зависимости.

Для объекта «цели и управленческие решения» ведётся журнал допущений. Каждая запись содержит основание, владельца, дату пересмотра и событие, после которого допущение нужно подтвердить, изменить либо закрыть.

  • 1. Действие — описать бизнес-сервисы; проверяемый результат — данные и показатели.
  • Решение 2: сопоставить приложения и данные. Основание для следующего шага — системы и интеграции.
  • Шаг 3. Зафиксировать интерфейсы и владельцев. Выход: инициативы, зависимости и ресурсы.
  • Выявить критичные зависимости — действие этапа 4. На выходе фиксируется цели и управленческие решения.
06

Решение и его основание

Решение формулируют до подготовки перечня требований. В нём называются объект «возможности и процессы», роль с правом выбора, допустимое действие и материал, на основании которого участники смогут подтвердить или отклонить вариант.

Сигнал «повторяющиеся разрывы между стратегией и проектами» и риск «планирование проектов без зависимостей» не объединяют в один показатель: первый описывает наблюдаемое состояние, второй — возможное последствие. Действие «сформировать целевые переходы» связывает их в проверяемом сценарии.

  • Решение 1: объект — цели и управленческие решения; сигнал — инвестиции без целевого состояния; действие — сформировать целевые переходы.
  • Решение 2: объект — возможности и процессы; сигнал — повторяющиеся разрывы между стратегией и проектами; действие — описать бизнес-сервисы.
  • Решение 3: объект — данные и показатели; сигнал — конкурирующие инициативы без общих критериев; действие — сопоставить приложения и данные.
07

Что проверить до проекта

Диагностика рассматривает конкретный эпизод, связанный с объектом «инициативы, зависимости и ресурсы». В карточке указываются время, участники, использованные данные, принятое решение и последствие; повторяемость проверяется по второй выборке.

Сигнал «несогласованные карты систем» оценивают вместе с владельцем процесса. Если причина находится вне выбранной границы, зависимость оформляют отдельно и не расширяют проект без нового решения о сроке, ресурсах и приёмке.

  • Диагностический признак 1: Повторяющиеся разрывы между стратегией и проектами. Карточка содержит пример и влияние на объект «данные и показатели».
  • Управленческий сигнал 2: Конкурирующие инициативы без общих критериев. Условие применения: связь с фактическим примером и объектом «системы и интеграции».
  • Диагностика фиксирует ситуацию «несогласованные карты систем», её повторяемость и влияние на инициативы, зависимости и ресурсы.
08

Роли в рабочем контуре

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

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

  • Владелец функции: полномочие связано с объектом «данные и показатели», а точка участия — с действием «выявить критичные зависимости».
  • В матрице решений архитектор связывает объект «системы и интеграции» с действием «сформировать целевые переходы».
  • Владелец данных: зона решения — инициативы, зависимости и ресурсы; контрольное действие — описать бизнес-сервисы.
  • Руководитель проекта отвечает за объект «цели и управленческие решения» и подтверждает действие «сопоставить приложения и данные».
09

Как подтвердить изменение

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

Сквозной тест начинается с сигнала «несогласованные карты систем», проходит через разрешённое решение и действие «сопоставить приложения и данные», затем завершается записью об исполнении. Дефект интерфейса и несоответствие процесса регистрируются раздельно.

  • 1. Приёмочный объект — цели и управленческие решения; сравниваются исходная выборка, ожидаемое изменение и подтверждённый факт. Сигнал проверки: Инвестиции без целевого состояния.
  • Свидетельство 2 описывает возможности и процессы, сопоставимые условия проверки и ответственного за вывод. Сигнал: Повторяющиеся разрывы между стратегией и проектами.
  • Проверка 3 относится к объекту «данные и показатели». Зафиксированы методика, владелец интерпретации и источник результата. Сигнал: Конкурирующие инициативы без общих критериев.
  • Контрольная запись 4: Системы и интеграции; версия данных, правило расчёта, ожидаемое изменение и фактический результат. Сигнал: Несогласованные карты систем.
10

Риски решения

Карта рисков начинается с двух условий: «планирование проектов без зависимостей» и «отсутствие владельца целевой модели». Для каждого определяют наблюдаемое событие, владельца решения, контроль и результат, который требует остановки либо возврата.

Для каждого допущения указываются владелец, подтверждающий материал и событие пересмотра. В этой статье особого контроля требует риск «отсутствие владельца целевой модели»: его состояние влияет на объём, последовательность работ и критерий приёмки.

  • Контролируемое ограничение: подмена архитектуры перечнем продуктов. Владелец выполняет действие «зафиксировать интерфейсы и владельцев» и предъявляет инициативы, зависимости и ресурсы.
  • Для риска «планирование проектов без зависимостей» заранее назначаются действие «выявить критичные зависимости» и свидетельство «цели и управленческие решения».
  • Проверка риска начинается с условия «разрыв между бизнес-целями и данными». Решение опирается на действие «сформировать целевые переходы» и данные об объекте «возможности и процессы».
  • Запись риска 4. Условие: Отсутствие владельца целевой модели. Контрольное действие: Описать бизнес-сервисы. Источник факта: Данные и показатели.
11

Пакет для первого решения

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

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

  • 1. Действие — описать бизнес-сервисы; проверяемый результат — данные и показатели.
  • Решение 2: сопоставить приложения и данные. Основание для следующего шага — системы и интеграции.
  • Контрольная запись 4: Системы и интеграции; версия данных, правило расчёта, ожидаемое изменение и фактический результат. Сигнал: Несогласованные карты систем.
  • Для критерия 5 выбран объект «инициативы, зависимости и ресурсы»; результат сопоставляется с базовой выборкой по одной методике. Сигнал: Показатели без владельцев решений.
Источники и связанные публикации

Документы и материалы для углублённого изучения темы.

The Open Group: официальный обзор TOGAFSystemsDesign: страница доклада Максима Кантаровича о целевых архитектурных моделях
FAQ

Частые вопросы

Как перейти от текущей модели к целевой архитектуре?+

Результат проверяют не по перечню функций, а по действию «сформировать целевые переходы» и подтверждённому факту об объекте «инициативы, зависимости и ресурсы». Решение по теме «Практический метод формирования целевой архитектуры» принимают на подтверждённом примере и закрепляют за владельцем процесса.

Какие бизнес-сервисы входят в границу (объект: «инициативы, зависимости и ресурсы»)?+

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

Как найти критичную зависимость (объект: «цели и управленческие решения»)?+

Сначала проверяют происхождение и полноту объекта «цели и управленческие решения», затем сопоставляют его с объектом «инициативы, зависимости и ресурсы». Известные исключения и правила исправления входят в ту же выборку.

Кто владеет интеграционным контрактом (объект: «возможности и процессы»)?+

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