Полная версия

Главная arrow Экономика arrow АРХИТЕКТУРА ПРЕДПРИЯТИЯ

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>

Этап реализации и перехода

На предыдущих этапах были решены задачи описания текущей архитектуры, проектирования целевой и определение разрывов (gaps) между ними. Именно эти разрывы, т. е. элементы архитектуры, которые в текущем и целевом состоянии имеют определенные отличия, и являются основным входом для настоящего этапа (рис. 4.40). На этапе планирования перехода происходит формирование проектов для перевода элементов архитектуры в целевое состояние, подключается «проектное управление».

Верхнеуровневая модель целевой архитектуры предприятия

Рис. 4.39. Верхнеуровневая модель целевой архитектуры предприятия

Этап реализации и перехода

Рис. 4.40. Этап реализации и перехода

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

На рис. 4.41 видно, что архитектору на данном этапе предстоит выполнить три шага. На первом из них потребуется определить потенциальное решение, которое будет реализовываться на практике. Следует обратить внимание на то, что обычно потенциальное решение всегда согласовывается с заинтересованными сторонами, ответственными за финансирование проекта. В большинстве случаев архитектор не имеет возможности самостоятельно выбрать, к примеру, конкретную программную платформу, поскольку решение по финансам принимает другое ответственное лицо.

После того как решение будет принято ответственной за финансирование или эксплуатацию заинтересованной стороной, архитектор должен понять зависимости между разрывами между текущим и целевым состоянием, которые были выделены на предыдущем этапе. Объекты, которые будут реализованы в целевой архитектуре предприятия в виде каких-то реальных решений, группируются. Выделяются промежуточные состояния архитектуры, которые принято называть переходными. Важно помнить, что работа по-прежнему ведется в терминах АП: управление проектами в этот момент еще не началось.

Только после того, как будут поняты зависимости между разрывами, а сами разрывы логически сгруппированы для дальнейшей реализации, осуществляется планирование перехода от описания АП к непосредственным проектам. Архитектор предприятия тесно взаимодействует с менеджером проектов и занимается анализом архитектурного соответствия. Задача архитектора в конце этапа — не допустить потери соответствия между реальными проектами и целевой архитектурой предприятия.

Этап реализации и перехода в соответствии cTOGAF

Рис. 4.41. Этап реализации и перехода в соответствии cTOGAF

Цели.

В общем виде можно выделить несколько целей этапа реализации и перехода:

  • • собрать воедино результаты анализа разрывов, и на их основе сформировать предложение по конкретному решению для заинтересованных сторон;
  • • определить зависимости между разрывами;
  • • сгруппировать зависимые разрывы и определить последовательность их реализации;
  • • определить потребность в переходных архитектурах;
  • • описать конкретную реализацию разрывов в виде проектов, для каждого из которых указаны затраты ресурсов, времени и т. п.;
  • • сформировать план реализации и перехода в терминах управления проектами;
  • • обеспечить архитектурное соответствие при реализации решения и переходе к эксплуатации.

Входы.

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

Таким образом, на данном этапе важны следующие входы, которые не являются артефактами АП:

  • — информация о возможных решениях;
  • — идр.

Как и на предыдущих этапах, в качестве входов фигурирует множество артефактов АП, созданных ранее.

Реестры:

  • — реестр требований;
  • — реестры бизнес-слоя;
  • — реестры слоя ИС;
  • — реестры технологического слоя;
  • — идр.

Матрицы соответствия:

  • — матрица соответствия бизнес-слоя;
  • — матрицы соответствия слоя ИС;
  • —матрицы соответствия технологического слоя;
  • — идр.

Диаграммы:

  • — диаграммы бизнес-слоя;
  • — диаграммы слоя ИС;
  • — диаграммы технологического слоя;
  • — идр.

Выходы.

В качестве выходов этапа реализации и перехода также присутствуют документы, не являющиеся артефактами АП. Например:

  • — архитектурные контракты;
  • — календарный план проектов трансформации;
  • — идр.

Артефактов АП на данном этапе создается немного. Как правило, среди них выделяются следующие.

Реестры:

  • — реестр требуемых объектов для достижения целевого состояния;
  • — идр.

Матрицы соответствия:

  • — матрица заинтересованные стороны/требуемые объекты;
  • — идр.

Диаграммы:

  • — диаграмма перехода;
  • — идр.
 
<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>