Управление изменениями и конфигурациями

Решение по управлению конфигурациями и управлению изменениями на основе системы управления архитектурой предприятия alfabet planningIT 3.1

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

ITSM (IT Service Management, управление IT услугами) — подмножество библиотеки ITIL, описывающее процессный подход к предоставлению и поддержке IT услуг. Данная часть ITIL получила наибольшую известность в силу того, что предоставление и поддержка IT-услуг является первичной задачей IT-подразделений и специализированных IT-компании, которые зачастую сталкиваются с недостаточной зрелостью данных процессов, необходимостью измерять и контролировать качество услуг.

Как наиболее известная часть ITIL, Управление IT-услугами (ITSM) нередко считается эквивалентным библиотеке ITIL в целом. Однако ITIL, включая в себя ITSM, описывает не только управление услугами, но и сопутствующие процессы. Под ITSM подразумеваются две книги ITIL: «Предоставление услуг» («Service Delivery») и «Поддержка услуг» («Service Support»).

Поддержка услуг (Service Support)

Неотъемлемой частью процессной организации по ITSM является Service Desk — функция, обеспечивающая единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов.

Процессами, входящими в Service Desk являются, среди прочих, такие процессы как:

• Процесс управления конфигурациями (Configuration Management)
• Процесс управления изменениями (Change Management)

Процесс управления конфигурациями (Configuration Management)

Цель процесса управления конфигурациями — сбор и актуализация достоверной информации о составляющих частях IT-инфраструктуры – конфигурационных элементах, обеспечение данной информацией других процессов Управления услугами.

Процесс управления изменениями (Change Management)

Цель процесса управления изменениями — обеспечение внесения Изменений в IT-инфраструктуру в соответствии со стандартизованными процедурами, для эффективного проведения Изменений и минимизации воздействия Изменений на функционирование инфраструктуры.

Управление изменениями приобретает все большую важность по мере ускорения внедрения новых технологий. По статистике, плохо спланированные или ошибочные изменения влекут за собой более 50% сбоев в ИТ инфраструктуре.

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

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

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

Проблемы управления изменениями

Проблемы, с которыми сталкиваются компании разработчики ПО при управлении изменениями (в % от опрошенных специалистов, по данным CA):

• 88% — развертывание приложений на нескольких платформах;
• 44% — развертывание приложений на более чем четырех платформах;
• 61% — ведение нескольких версий программного обеспечения;
• 52% — необходимость поддержки параллельной разработки;
• 46% — сопровождение нескольких жизненных циклов для различных видов разработки;
• 39% — внесение частых изменений в серийное программное обеспечение.

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

Во главе постоянно нарастающей сложности разработки находится необходимость увеличения объема работ. Почти четверть опрошенных заявила, что их просили намного чаще выпускать обновления. Большинство респондентов считали, что имеется возможность повысить свою производительность разработки, и только 14% респондентов были полностью удовлетворены производительностью своих групп разработчиков.

Неудивительно, что в центре внимания опрошенных разработчиков находится управление изменениями. 40% респондентов внедрили методологию или аккредитацию, и 83% респондентов уже используют инструментарий для управления изменениями или рассматривают вопрос о его использовании.

В исследовании, проведенном Standish Group, приводятся результаты проектов разработки приложений:

• среднее превышение времени разработки — 222%
• среднее превышение затрат на разработку — 189%
• отставание в удовлетворении требований пользователя на 27 месяцев.

Также сообщается, что лишь 25% проектов внедрены успешно, 28% проектов остановлены, и в 46% проектов возникли значительные проблемы с поставкой.

Причины простоев информационных систем

Ошибки эксплуатации информационных систем – 40%

• Отсутствие формализованных процедур эксплуатации и их контроля
• Ошибки резервирования данных
• Ошибки безопасности информационных систем

Ошибки приложений – 40%

• Плохое тестирование приложений
• Отсутствие управления изменениями
• Перегрузка аппаратного и программного обеспечения
• Медленное устранение проблем

Прочие ошибки – 20%

• Ошибки, связанные с неисправностью оборудования и системного ПО
• Сбои активного и пассивного коммуникационного оборудования
• Проблемы с электропитанием и тепловым режимом
• Стихийные бедствия

Проблемы проектов по внесению изменений

Широко известные факты в области управления проектами:

• Сбор данных о реальной структуре текущей инфраструктуры составляет 15-30% от бюджета проекта (ист. Deloitte, Detecon, TSI)
• 40% ошибок проектирования вызваны ошибочными функциональными требованиями (ист. IBM, Standish Group)
• 50% общей стоимости проекта уходит на переделку выполненных работ, из них 70% вызваны неправильными функциональными требованиями (ист. IBM, Standish Group)
• В среднем, используется лишь 7% функциональности ПО (ист. Gartner);
• 85% ИТ-проектов не достигают цели, причем 32% просто обрываются. (Ист. Gartner)
• Формализация процессов управления проектом позволяет экономить до 40% неоперационных расходов на зарплату персонала (ист. MIT)
• Планирование и стандартизация элементов IT-инфраструктуры может дать экономию 20-30% расходов (ист. McKinsey, IBM, Meta Group)
• Опыт реализации проектов по внедрению информационных технологий показывает, что общий объем работ по управлению проектом составляет от 10% общего объема работ по проекту для небольших проектов до 25% для крупных проектов.

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

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

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

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

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

Эффективность управления изменениями

Управление изменениями занимает существенную часть усилий на управление проектами:

• В новом проекте разработки 15% усилий ежедневно тратится на операции управления изменениями.
• В проектах поддержки эта цифра приближается к 25%.
• В новых проектах в распределенных средах на управление изменениями может тратиться 20% усилий.
• При поддержке распределенных приложений затраты на управление изменениями могут вырасти до 40%.

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

В таблице показана доля затрат на операции управления изменениями в общих затратах по проекту без применения инструментов управления изменениями:

Задача управления изменениями	Операции	% затрат по проекту
Доступ к программному обеспечению и получение ПО	Управление различными версиями компонента ПО, сотрудниками, имеющими доступ к определенным компонентам, и способами доступа	3%
Синхронизация изменений в среде разработок	Управление параллельной и совместной разработкой, обеспечивающее синхронизацию всех активных компонентов	10%
Миграция изменений	Управление как прямой, так и обратной миграцией изменений в жизненном цикле	6%
Управление процессом компиляции и сборки	Исполняемые файлы или загрузочные модули, созданные путем сборки и связывания исходных компонентов; определение итогового влияния, оказываемого на несколько исполняемых файлов при изменении источника	5%
Управление распространением изменений	Подготовка приложения к генерации ленты (tape generation) или электронной передаче и отслеживание версий приложения, используемых определенными сотрудниками	3%
Утверждение и разрешение	Получение утверждений и/или письменных разрешений, например, перед такими операциями, как миграция, распространение	2%
Управление запросами на изменение программного обеспечения	Отслеживание продвижения запросов на изменение	2%
Координирование коммуникации для согласованности разработки и операций	Обеспечение информационного потока, особенно между географически распределенными группами и в качестве подходов к внедрению	4%
Получение информации о статусе проекта	Получение информации для отслеживания статуса и отчета о статусе	3%
Отслеживание ошибок и их исправлений	Управление информацией, поступающей от группы тестирования, аналитиков и персонала центра поддержки и для них	2%

Затраты на управление изменениями и экономия времени с помощью решения по управлению изменениями могут зависеть от вида проекта и ранее использованного подхода к управлению изменениями.

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

Методология управления изменениями

Управление изменениями состоит из нескольких процессов:

• Управление изменением исходного текста программ (Source Code Management)
• Управление изменением метаданных (структура баз данных и т.д.)
• Управление изменением данных

Функции управления изменениями:

• Планирование изменений

• Управление запросами на изменения
• Управление портфелем проектов и программ
• Управление архитектурой приложений
• Конфигурационный контроль
• Версионный контроль
• Управление развертыванием

Субъекты управления изменениями:

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

• Разработчики
• Тестировщики
• Эксплуатанты
• Пользователи

Объекты управления изменениями:

• Запрос на изменение (Business Demand)
• Проектное предложение (Project Proposal)
• Архитектурное решение (Solution)
• Работы по проекту (Work Item)

• Проект по изменению (Project)
• Квалификация участников проекта (Skill)
• Релиз (Release, Baseline)
• Компонент релиза (Component)
• Элемент компонента (Element)
• Действие (задача) по изменению (Activity)
• Поток разработки (Development stream) - набор доступных разработчику версий элементов для просмотра, изменения или компиляции
• Поток слияния (Integration stream) – консолидированный набор компонентов для создания релиза.

Управление изменениями исходного текста программ

Процесс управления изменениями исходного текста программ:

• Создание запроса на изменение (Business Demand) и ввод его в planningIT (модуль Demand Management)
• Оценка в planningIT запроса на изменение и создание проектного предложения (Project Proposal)
• Разработка в planningIT архитектурных решений (Solution) и выбор рекомендованного архитектурного решения
• Оценка в planningIT объема работ и требований к квалификации участников проекта
• Оценка в planningIT стоимости проекта и планирование сроков реализации проекта
• Инициация в planningIT проекта (Project) на основе запроса на изменение, проектного предложения и выбранного архитектурного решения

• Экспорт из planningIT структуры компонентов и релизов (Project versioned object base) в модуль управления изменениями.
• Экспорт проекта из planningIT в систему управления проектами (модуль управление изменениями) для реализации.
• Каждая бюджетная статья становится проектом
• Подчиненные мероприятия (work items) транслируются в задачи подпроектов.
• Требования к навыкам и квалификации транслируются в ресурсные (resource pool) требования.
• Детальное планирование проекта с определением задач и распределение ресурсов в соответствии с их наличием и требованиями к квалификации и навыкам.
• Создание в модуле управления изменениями хранилища элементов (Versioned object base) для регистрации изменений и отслеживания версионности элементов.
• Определение прав доступа разработчиков к компонентам проекта
• Формирование компонентов проекта из набора элементов (файлы и директории)

• Ассоциация работ с группами (задачами) изменений (Activities)
• Присоединение разработчика в проект (Join a project) с созданием изолированного рабочего пространства (View), заполненного доступными элементами текущих версий и потока разработки (Stream) на основе текущего релиза
• Проведение изменения в рамках потока разработки
• Постановка задачи разработчика на изменение (Set activity)
• Взятие версии элемента с целью редактирования (Check out)
• Постановка элемента под контроль после внесения изменений (Check in)
• Проверка выполненной работы по изменению.
• Передача изменения (Deliver activity) во всеобщее рабочее пространство – единый поток слияния (Integration stream)
• Компиляция и тестирование изменения.
• Сборка изменений менеджером проекта в релиз.
• Проведение серии тестов и исправлений релиза и назначение релизу статуса «рекомендуемый».
• Синхронизация собственного рабочего пространства с рабочим пространством других разработчиков, делающих вклад в рекомендуемый релиз (Rebase work area).
• Внесение изменений о версии и конфигурации компонентов и релизов в репозитарий planningIT
• Инициация процесса развертывания релиза.

Управление изменениями структуры баз данных

Объекты управления изменениями структуры баз данных:

• База данных (эксплуатационная, экспериментальная)
• Объекты базы данных (схемы, таблицы, профили, роли, сегменты отката и т.п.)
• Состояние базы данных (Baseline)

Методология модификации базы данных

• Определение текущего состояния базы данных и ее структур
• Сравнение текущего состояния базы данных (Baseline) с предыдущим состоянием и выявление различий.
• Реинжиниринг базы данных ее частей, отдельных схем, системных и пользовательских объектов (профили, роли, сегменты отката и т.п.)
• Формирование и сохранение плана внесения изменений в базу данных
• Анализ зависимостей объектов базы данных и последствий изменений в базу данных для оценки влияния и допустимости изменений в базе данных
• Подготовка отчета и формирование скриптов для выполнения изменений
• Запуск скриптов для выполнения изменений в экспериментальной базе данных на выполнение.
• Анализ результатов изменений в экспериментальной базе данных
• Запуск скриптов для выполнения изменений в эксплуатационной базе данных на выполнение.
• Сохранение результата реинжинринга (Baseline) для последующего сравнения различных состояний базы данных.

Предлагается интегрированное решение на основе системы alfabet planningIT v.3.1 с подключением к единому репозитарию planningIT Logical Inventory компонентов других производителей:

• управление предоставлением и поддержкой ИТ-услуг (ITIL/ITSM)
• авто-поиск конфигураций (Auto-Discovery)
• моделирование бизнес-процессов (BPM)
• управление проектами (PPM)
• управление ресурсами предприятия (ERP).

Задача управления конфигурациями

Система alfabet planningIT способна взять на себя функции следующие функции по управлению конфигурациями:

• Сбор и поддержание актуальной информации о компонентах ИТ-инфраструктуры и бизнес-архитектуры с помощью онлайновых форм, мастеров ввода, а также импорта файлов на основе шаблонов MS Word.
• Поддержка многоуровневой системы прав доступа, основанной на ролевых профилях, группах пользователей, делегировании и наследовании прав, определении прав доступа к конкретным объектам, категориям и группам объектов, а также взаимодействие с LDAP.
• Просмотр информации, внесение санкционированных изменений в описание конфигурационных элементов и их взаимосвязей.
• Поддержание единой модели данных, основанной на развитой метамодели архитектуры, предприятия, включающей бизнес-архитектуру, информационную архитектуру, архитектуру приложений, техническую архитектуру, физическую архитектуру.
• Поддержка федеративной модели архитектуры предприятия.
• Поддержка в рамках единого репозитария взаимосвязей элементов ИТ-инфраструктуры с элементами бизнес-архитектуры (бизнес-процессы, организационные единицы, бизнес-функции и т.п.)
• Объединение данных, полученных от различных средств обнаружения конфигурационных элементов.
• Анализ конфигурационной информации и создание текстовых и графических отчетов.

Автоматический сбор и поддержание актуальности информации о компонентах ИТ-инфраструктуры в alfabet planningIT можно реализовать с помощью компонентов других производителей, например с помощью компонентов BMC Discovery: BMC Foundation Discovery, BMC Configuration Discovery и BMC Topology Discovery.

Соответствие возможностей системы alfabet planningIT задачам управления конфигурациями и управления изменениями.

Объектная модель planningIT

Система planningIT добавлять к объектам единого репозитария произвольные атрибуты различных типов. Добавление произвольных атрибутов с различными типами обеспечивается с помощью раздела Evaluation в базовом описании первичных объектов единого репозитария. Атрибуты (или индикаторы Indicators- в терминологии planningIT) можно добавлять в модуле Configuration (раздел «Evaluations and Portfolios»). Атрибуты могут быть текстовыми, числовыми, списочными. Атрибуты могут группироваться по типам («Evaluation Type»). Описание атрибута (индикатора) содержит реквизиты: полное имя, короткое имя, значение по умолчанию, список возможных значений, описание, визуализация. Для визуализации значений тип атрибута и атрибут может ассоциироваться с различными группами значков из галереи с указанием минимальных и максимальных значений диапазона.

Возможно также добавление к объектам произвольных атрибутов через инструментарий настройки метамодели alfabet eXpand (закладка Classes, функция Create Custom Property). Состав реквизитов создаваемых пользовательских атрибутов: Caption, Name, Comment, Default Value, Precision, Property Type, Searchable. Типы значений создаваемых атрибутов (Property Type): Date, Boolean, Integer. Real, Reference, String, Text, URL, RefernceArray.

Создание статической гиперссылки от объекта обеспечивается через раздел Attachment в базовом описании первичных объектов репозитария. Возможно также создание пользовательских атрибутов объектов с типом URL через специализированный инструмент управления метамоделью alfabet eXpand.

Ссылка на другой объект в системе обеспечивается за счет существующей метамодели, описывающей существующие связи объектов репозитария между собой.

Ссылка на объект из внешнего источника реализуется через механизм динамических ссылок. Динамические ссылки позволяют указать внешнее приложение и место (объект) в этом приложении, ассоциированный с текущим объектом репозитария системы planningIT. Настройка динамических ссылок для различных типов объектов репозитария осуществляется в специализированном инструменте alfabet eXpand (закладка Applications, раздел WebViewManager). Атрибут в системе planningIT может иметь единичное значение или список значений, с указанием значения по умолчанию.

Система planningIT построена на платформе .NET и обладает развитым API для доступа к объектам репозитария Logical Inventory. planningIT может обмениваться информационными объектами с другими приложениями с помощью протокола SOAP и выступать поставщиком веб-сервисов для внешних приложений.

Структура объектов единого репозитария, построенного на основе развитой метамодели хорошо описана и доступна для обзора (изменения) с помощью специализированного объектного инструментария alfabet eXpand.

Интеграция planningIT с другими системами

Для совершения операций над объектами существует возможностьзадать контекст, в котором выполняется операция. Контекст задается запросом на изменение. Запросы на изменения могут вестись во внешней информационной системе. При совершении операций над объектами planningIT использует уникальный номер запроса на изменение.

Сбор запросов на изменение обеспечивается через использование стандартной функциональности модуля Demand Management системы planningIT. В этом случае запросы на изменение оформляются в виде Бизнес-требования (Business Demand) с их последующей привязкой к аффектированным объектам репозитария. Требования могут создаваться в системе или импортироваться из внешней системы управления требованиями или управления изменениями. Затем на базе требований в системе planningIT могут формироваться «Задания» (Assignments) с указанием объектов, подлежащих изменению.

Получение запросов на изменение из внешней системы реализуется через импорт (синхронизацию) XML объектов из внешних информационных источников с настройкой параметров через инструментарий alfabet eXpand (закладка Classes, раздел XML Objects, свойство ExternalSourceConfiguration). Синхронизация происходит по умолчанию при каждом обращении к внешнему объекту в рамках интерфейса planningIT. Возможна также пакетная синхронизация по расписанию.

Каждый объект репозитария получает уникальный идентификационный номер в рамках своего типа. Таким образом, по этому уникальному ID возможна точная идентификация. Объекты в planningIT могут быть объединены в группы. Возможно описание и исполнение последовательности операций с помощью механизма Workflow.

При интеграции planningIT с внешней системой управления запросами на изменения, из planningIT передается список доменов и ИС в систему управления запросами на изменение. Организация связи с внешней информационной системой организуется через описание динамической ссылки (Dynamic Link). При этом обеспечивается передача необходимых параметров описания контекста.

Одним из объектов репозитария planningIT является бизнес-домен (Business Domain). Бизнес-домен определяет логическую изолированную единицу предприятия с функциональной точки зрения. Домен включает различные архитектурные элементы бизнес-архитектуры: бизнес-процесс, бизнес-функция, бизнес-объект, бизнес-приложение, ИКТ объект.

Другим типом доменов является домен территориальный (Location Domain). Он определяет совокупность компонентов, сгруппированных по географическому признаку.

Еще один тип доменов – домен развертывания (Stack). Он включает все компоненты, относящиеся к данному проекту развертывания.

Управление разделением доступа

Система planningIT имеет развитые средства управления доступом, позволяющие обеспечивать работу до нескольких тысяч пользователей с ролевым разделением доступа к объектам и функциям системы. Обеспечивается интеграция внешними источниками данных о пользователях с использованием LDAP. Кроме того, возможно использование встроенного механизма управления доступом.

Система planningIT позволяет создавать неограниченное число пользовательских профилей (ролей). Типичные роли пользователей: администратор, менеджер приложения, менеджер проекта, архитектор предприятия, архитектор приложения, директор ИТ, функциональный пользовательб суперпользователь и т.п.

Система planningIT позволяет описать доступные привилегии для каждого профиля (роли). Система поддерживает для каждого пользователя набор прав доступа, состоящий из:

• набора доступных профилей (Profiles);
• объектов репозитария, принадлежащих данному пользователю (Personal Items);
• объектов репозитария, принадлежащих другим пользователям и доступных для данного пользователя (Deputy Items),
• набора объектов принадлежащих данному пользователю, переданных другим пользователям (Role Items);
• объектов репозитария сгруппированных по группам пользователей (User Groups);
• набора преднастроенных запросов к объектному репозитарию (Queries).

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

Возможности расширения функциональности системы

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

Возможно создание нового объекта на основе существующего объекта с выбором копируемых атрибутов объекта. Кроме того возможно копирование выбранных атрибутов от одного объекта к другому.

Средство управления объектами репозитария alfabet eXpand предоставляет администратору системы и разработчику средства для создания и редактирования объектов и отчетов, доступных в системе planningIT.

Пользовательский интерфейс

Система planningIT поддерживает навигацию по объектам репозитария с помощью навигатора (Explorer), поддерживающего концепцию рабочих полей с древовидной организацией объектов репозитария и развертываемыми списками доступных атрибутов и функций. Переход к объекту обеспечивается за счет поддержки функции «Drill-down» с возможностью возврата назад с помощью интеллектуальной кнопки «Back». Количество шагов в рамках сеанса неограниченно.

Поддерживаются различные варианты поиска с вызовом нужного объекта из результата поиска. Виды поиска: Simple Search, Browse, Query, Full Text Search.

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

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

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

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

Настройка состава информации об объектах в табличном режиме возможна с помощью стандартной функции выбора отображаемых атрибутов объекта (Presentation Object Configuration). При необходимости добавления дополнительных отображаемых атрибутов возможно применение инструментария конфигурирования системы alfabet eXpand.

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

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

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

Cредства построения и отображения отчетов

Система planningIT обладает стандартными средствами отображения отчетов. Система поддерживает экспорт отчетов в различных форматах: Excel (xls), PowerPoint (ppt), SVG, JPEG, HTML, XML. Экспорт в нативный формат программы MS Word не предусмотрен.

Отчеты и графические диаграммы поддерживают стандартную возможность перехода к выделенному объекту (Drill Down) с доступом к просмотру атрибутов объекта.

Создание в planningIT шаблонов для дополнительных отчетов возможно с использованием инструментария alfabet eXpand.

Журналирование

Система planningIT позволяет просматривать жизненный цикл объектов репозитария. Перечень этапов жизненного цикла могут настраиваться с помощью инструментария alfabet eXpand. Каждый этап жизненного цикла определяется датой начала и датой завершения. Возможен групповой просмотр жизненного цикла объектов репозитария.

Система planningIT построена на основе транзакционной модели. Все действия пользователя регистрируются и доступны для дальнейшего использования. Просмотр истории изменений объекта осуществляется с помощью стандартной функции «Artifact Audit Trail».

Масштабируемость системы

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

Для тестирования был сформирован следующий ролевой состав пользователей ИС Alfabet planningIT:

Группа пользователей (роль)	Количество пользователей	Интенсивность использования	Функциональный модуль
Ответственные за бизнес-приложения	2000	Низкая	Единый репозитарий
Ответственные за формирование стратегий, политик, целей.	170	Ниже средней	Управление стратегическими целями
Стратеги ИТ	30	Ниже средней	Управление стратегическими целями
Менеджеры по управлению портфелем проектов	10	Средняя	Управление портфелем проектов
Планировщики взаимосвязанных элементов архитектуры предприятия	50	Высокая	Управление архитектурой предприятия
Enterprise architecture managers	7	Высокая	Управление архитектурой предприятия
Chief modelers	20	Выше средней	Управление архитектурой приложений
Аналитики бизнес-требований	15	Средняя	Управление архитектурой приложений
Архитекторы ИТ	40	Средняя	Управление архитектурой приложений
Главные архитекторы приложений	50	Выше средней	Управление архитектурой приложений
Менеджеры по подготовке решений по проектным предложениям	40	Средняя	Управление архитектурой приложений
Итого	2462

Тест на производительность Alfabet planningIT был проведен на основе стандартной инсталляции системы без каких-либо дополнительных настроек системного и прикладного ПО. Тест основан на 10 различных пользовательских ролях и типовых задачах, включая доступ на чтение, запись, подготовку сложных аналитических отчетов. Время отклика измерялось с момента запроса до выдачи результата.

Тестовая конфигурация

Сервер приложений	Веб-сервер
IBM XSERIES_365	IBM XSERIES_365
Windows 2000 Service Pack 4	Windows 2000 Service Pack 4
Intel Xeon 2.20GHz (4-Processors)	Intel Xeon 2.20GHz (4-Processors)
4.193 MB RAM	4.193 MB RAM
Norton Antivirus	Norton Antivirus

Сервер баз данных

Oracle Database 9i, Спецификация сервера неизвестна.

Результаты тестирования производительности

Число одновременных пользователей	Среднее время отклика (сек.)	Макс. время отклика (сек.)	Использование памяти сервером приложений	Число потоков на сервере приложений	Использование памяти веб-сервером
10	1.63	2.01	502	25	180
15	2.10	2.26	603	30	211
18	2.40	2.60	542	33	220
25	3.10	3.80	551	43	268
36	5.00	6.00	471	53	313

Результаты тестирования показали, что стандартная установка, состоящая из трех серверов: сервер приложений, сервер баз данных и веб-сервер могут обеспечить поддержку пользовательского сообщества из 2500 пользователей (при учете промышленного стандарта соотношения числа конкурентных обращений и общего числа пользователей 1:100 для веб-ориентированных корпоративных приложений).

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

Линейная зависимость между временем отклика и числом конкурентных обращений к системе показывает, что ИС Alfabet planningIT может быть легко масштабируема для больших пользовательских сообществ с помощью простого добавления необходимого оборудования и его компонентов.

Установка и поддержка

Система planningIT поставляется с документаций: Руководство системного администратора, Руководство по настройке метамодели (alfabet eXpand), Руководства пользователей по функциональным модулям системы.

Техническая поддержка в России обеспечивается компанией РДТеХ. При необходимости обеспечивается техническая онлайновая поддержка сотрудниками компании alfabet. Поддержка осуществляется на русском и английском языках. Разработка дополнительной функциональности системы возможна силами группы разработчиков компании РДТеХ.

Установка системы является несложной процедурой за счет использования удобного инсталлятора. Первоначальная настройка системы может быть осуществлена представителями компании alfabet (компания РДТеХ). Техническая поддержка системы может также осуществляться представителями разработчика в случае наличия соглашения о технической поддержке.

Автоматизация управления изменениями

Система planningIT поддерживает управление изменениями с помощью модуля Business Demand. В рамках интерфейса могут быть созданы, оценены и удовлетворены различные требования. Требования могут группироваться с группы в зависимости от их типа, например стратегические, тактические, операционные. Требования имеют жизненный цикл с поддержкой различных настраиваемых статусов. К требованию может быть привязан любой набор объектов репозитария. Возможен импорт требований из других систем управления требованиями или управления изменениями. Поддерживается развитый поиск по различным атрибутам объектов.

Требования, привязанные к конкретному объекту репозитария доступны в описании атрибутов объекта (раздел Change Request Analisys -> Relevant Demands).

На основании анализа требований может создаваться «Задание» (Assignment), направляемое конкретному пользователю системы (владелец объекта, руководитель, исполнитель, контроллер и т.п.). Задания могут группироваться по пользователям или объектам. Отображение личных заданий пользователя доступно в разделе «Мои задания». Атрибутивный состав «Задания»: ID, Название, Кому адресовано, сообщать ли заместителю, соответствующий объект репозитария, контрольная дата, статус, тип задания, описание задания, примечания к заданию, присоединенные документы (ссылки или документы в хранилище IDOC).

Каждое требование получает в системе уникальный идентификационный номер, который может использоваться для определения контекста операции над объектом. Последовательность операций над объектами может определяться с помощью организации рабочего процесса (Workflow).

Система planningIT обеспечивает удобный интерфейс для доступа к объектам репозитария, в том числе к объектам типа «Business Demand», «Assignment».

Интеграция данных

Репозитарий planningIT может выступать основой для организации единого логического хранилища информации. Описание источников данных возможно с использованием инструментария настройки метамодели alfabet eXpand.

Система planningIT не обладает средствами автоматического определения конфигурационных единиц. Однако, возможна интеграция с системами автоопределения сторонних разработчиков.

Система planningIT не обладает возможностями обнаружения изменений конфигурационных единиц. Однако, возможна интеграция с системами обнаружения изменений сторонних разработчиков. В случае внесения изменений в описание объекта единого репозитария planningIT возможно генерирование автоматического почтового сообщения. Для этого используется механизм мониторов, устанавливаемых на любой объект репозитария. Мониторы могут устанавливаться на мониторинг изменений, отсутствие изменений и конкретную дату.

Поддержка веб-интерфейса

Система planningIT построена на платформе .NET стандартно поддерживает тонкий клиент на основе программ просмотра веб-контента (Internet Explorer 5.0+) для работы с текстовым представлением данных и просмотра графических объектов (диаграммы, отчеты и т.п.). Для редактирования диаграмм необходимо применение толстого клиента, включающего модуль «alfabet Diagram Designer».

Система planningIT позволяет настраивать пользовательский интерфейс в соответствии с требованиями и поддерживает настройку различных пользовательских профилей с настройкой любых элементов пользовательского интерфейса.

Механизм нотификации

Система planningIT поддерживает протокол SMTP для отправления сообщений на основе механизма мониторов.

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

Система позволяет настраивать различные шаблоны сообщений для различных групп пользователей.

Функциональный состав системы alfabet planningIT 3.1

Для реализации задачи «Управление конфигурациями» необходимо использование следующих модулей системы alfabet planningIT:

• Logical Inventory – единый репозитарий с поддержкой базовой функциональности системы
• Enterprise Architecture Management – управление архитектурой предприятия
• Application Architecture Management – управление архитектурой приложений.

Для реализации задачи «Управление изменениями» необходимо дополнительно использование следующих модулей:

• Demand Management – управление бизнес-требованиями
• Release Management – управление релизами
• Program Portfolio Management – управление портфелем программ

Управление бизнес-требованиями

Модуль «Управление бизнес-требованиями» (Business Demand Management) служит для постоянного документирования и консолидации потребностей бизнеса в контексте текущих и стратегических составляющих с инициализацией проектных предложений.

Через модуль «Управление бизнес-требованиями» могут проходить запросы на изменение элементов ИТ-инфраструктуры, которые могут привести к несогласованности развития И-инфраструктуры в целом. Другой вариант – обработка всех бизнес-требований, с последующей отправкой изолированных бизнес-требований, не связанных с другими элементами архитектуры в специализированные программы по управлению работами над внесением изменений.

Основные функции модуля «Управление бизнес-требованиями»

Сбор и хранение бизнес-требований:

• Выявление похожих бизнес-требований.
• Создание бизнес-требований.
• Привязка бизнес-требований к стратегическим целям предприятия и архитектурным элементам предприятия.

Ревизия бизнес-требований:

• Отказ от избыточных бизнес-требований.
• Разделение на части высокоуровневых бизнес-требований.

Инициализация предложений по бизнес-требованиям:

• Определение бизнес-требований, которые могут быть объединены.
• Объединение бизнес-требований в проектные предложения.
• Консолидация возможных эффектов и сроков реализации предложений.
• Определение ответственных за реализацию проектного предложения.

Управление релизами

Модуль управления релизами предназначен для реализации стратегического плана развития ИТ на операционном уровне. Логическое описание ИТ-инфрастурктуры – ИКТ-объекты и бизнес-приложения - транслируется в набор элементов технической архитектуры, таких как компоненты и стандартные платформы платформы. Эти наборы элементов затем физически развертываются для последующей эксплуатации.

Стеки (Stacks) – это наборы элементов логической и технической архитектуры, предназначенные для физического развертывания (Deployment). Стек непосредственно включает приложения, компоненты, стандартные платформы. Стек связывает логический и физический уровень описания ИТ-инфраструктуры.

Иерархическая природа стека позволяет последовательно детализировать различные варианты развертывания через создание подстеков. Например, можно учесть изменения стандартной платформы при конкретном развертывании приложения. На каждом уровне уточнения, возможность изменения конфигурации стека все больше ограничивается. Например, на стеке первого уровня устанавливается различие между различными типами операционных систем (Windows, Unix). В стеке второго уровня могут различаться различные диалекты Unix (Linux, Solaris), на третьем уровне стек определяет различные варианты Linux (Ubuntu, Debian, SuSe) и т.д.

Стеки могут создаваться на основе приложений, компонентов или стандартных платформ. Для программных компонентов, которые были созданы не основе готовых программных продуктов, стеки обычно определяют версии патчей от поставщика ПО. Для приложений стеки определяют уточненную конфигурацию технической платформы, на которой приложение будет работать. Стеки, построенные на основе стандартных платформ, могут добавлять новые или исключать стандартные элементы платформы, а также устанавливать сложные групповые зависимости между элементами платформы. Кроме того, стек может включать элементы конфигурации, не связанные со стратегическим уровнем планирования, но важны е с точки зрения операционного управления.

Основные функции модуля «Управление релизами» (Release Management)

Управление развертыванием, изменениями и модернизацией:

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

Управление портфелем программ

Модуль «Управление портфелем программ» (Program Portfolio Management) служит для привязки ИТ-проектов к единой программе развития архитектуры и обеспечивает структурированный анализ ее бюджета. Используется для формирования приоритетов на основе анализа ресурсов и рисков.

В случае реализации процесса управления изменениями, в данном модуле производится оценка стоимости изменений, подготавливается архитектурное решение и оцениваются необходимые временные и человеческие ресурсы. После выбора архитектурного решения и формирования проекта и его бюджета, проект экспортируется в систему управления проектами, например в систему Mercury PPM или Primavera. Ход исполнения проекта по внесению изменений контролируется через информационный обмен между planningIT и соответствующей системой управления проектами.

Основные функции модуля «Управление портфелем программ»

Определение предложений:

• Определение/переопределение рабочих статей по проектам.
• Привязка проектных предложений к стандартным критериям.
• Привязка проектного предложения к проектной программе или организации.

Оценка и определение приоритетов предложений:

• Привязка набора оценочных показателей к проектным предложениям.
• Ранжирование и выбор проектных предложений для включения в проектную программу или организационную единицу.
• Согласование приоритетов для проектных предложений затрагивающих несколько организационных единиц.
• Определение рисков связанных с зависимостью от архитектуры.
• Определение необходимых для проектного предложения навыков персонала.

Выделение бюджетных программ:

• Определение бюджетной программы.
• Просмотр бюджетных запросов по проектным предложениям.
• Привязка бюджетных статей к проектным предложениям.

Выделение бюджетов подразделений:

• Просмотр бюджетных запросов.
• Привязка бюджетных статей к проектным предложениям.
• Формирование общего бюджета к организационной единице.
• Формирование единого бюджета.

Определение метрик предложений:

• Просмотр стратегических целей и политик.
• Определение критериев оценки.
• Определение значимости стандартов.

Управление сервисными контрактами

Единый репозитарий (Logical Inventory)

Модуль «Единый репозитарий» (Logical Inventory) обеспечивает создание и хранение детальной логической схемы существующей архитектуры предприятия на основе развитой преднастроенной расширяемой метамодели.

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

Каждый объект в Logical Inventory имеет жизненный цикл, что позволяет описывать различные состояния объекта во времени. Logical Inventory поддерживает различные состояния ИС: тестовая, опытно-промышленная, промышленная, коммерческая эксплуатация, вывод из эксплуатации. Поддерживается графическое отображение жизненного цикла ИС.

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

Logical Inventory поддерживает на уровне метамодели различные типы объектов. Между объектами на разных уровнях детализации устанавливается иерархическая взаимосвязь. Основные типы объектов: организация, бизнес-процесс, бизнес-функция, бизнес-приложение, платформа, компонент, оборудование, местоположение.

Объекты единого репозитария

Бизнес-архитектура

Объект	Название	Состав	Агрегат
Бизнес-потенциал	Business Capability	Aspect Evaluation Type Evaluation Group	Карта
Бизнес-процесс	Business Process	Business Service Request Organization Information Flow Business Support Business Object	Модель Бизнес-процесс Организация
Бизнес-функция	Business Function	Business Operation Orchestration Business Object	Категория
Организация	Organization	ICT Object Business Process Market Product Business Support Service Contract	Организация
Виртуальная организация	Virtual Organization	ICT Object Business Process Market Product Business Support Service Contract	Организация
Функциональный домен	Functional Domain	Business Process Application Business Function Business Object ICT Object	Модель Домен Тип домена
ИКТ объект	ICT Object	Application Component Standard Platform	Категория Группа
Товар (услуга)	Market Product	Sub-product Business Service Request Business Support Application Support Component Support	Группа

Информационная архитектура

Объект	Название	Состав	Агрегат
Бизнес-объект	Business Object	Business Data Application Information Flow	Категория
Бизнес-данные	Business Data	Attribute Application Information Flow	Бизнес-объект
Информационный поток	Information Flow	Business Data Interface	Приложение Компонент Бизнес-данные Бизнес-процесс

Архитектура приложений

Объект	Название	Состав	Агрегат
Бизнес-приложение	Application	Application Group Application Variant Business Process Market Product Business Service Business Support Business Data Information Flow Component Technical Platform Deployment Device Location	Группа Потребитель ИКТ объект Владелец
Внешнее бизнес-приложение	Peripheral	Information Flow	Группа

Техническая архитектура

Объект	Название	Состав	Агрегат
Шаблон платформы	Platform Template	Tier Layer
Мастер платформа	Master Platform	Component Technical Platform Standard Platform	Шаблон платформы
Стандартная платформа	Standard Platform	Technical Platform Component	Шаблон платформы Категория Каталог
Техническая платформа	Technical Platform	Component	Стандартная платформа Приложение
Компонент	Component	Business Process Market Product Business Service Business Data Information Flow Technical Service Technical Operation Deployment ICT Object Software Vendor Local Component	Техническая платформа Группа Категория

Архитектура развертывания

Объект	Название	Состав	Агрегат
Развертывание	Deployment	Component Deployment Deployment Element Device Location Business Support	Стек Развертывание
Устройство	Device	Deployment Location Information Flow ICT Object	Развертывание Группа
Стек	Stack	Sub-stack Stack Upgrade Stack Deployment Stack Element Configuration Item	Компонент Приложение Cтандартная платформа
Элемент конфигурации	Configuration Item	Component	Развертывание
Размещение	Location	Sub-Location Device Deployment	Развертывание Размещение

Пример взаимодействия системы alfabet planningIT и системы управления проектами PPM

Предлагаемая комбинация системы planningIT позволяет обеспечить непрерывный управленческий процесс согласования различных проектов по внесению изменений в элементы инфраструктуры между собой и со стратегическим планом развития организации и ее ИТ-подразделений.

Порядок шагов:

1. Бизнес-требования собираются в planningIT; любые изолированные требования, переходят в средство управления проектами (PPM).
2. Операционные требования собираются в средство PPM; все неизолированные требования переходят в planningIT для дальнейшей оценки, консолидации, анализа избыточности и планирования решений.

a) Переход нестратегических требований для обработки в модуле контроля изменений (Change Management)

b) Синхронизация изменений с модулем управления версиями (Operational release management) и базами данных конфигураций (CMDB)

3. Синхронизация объектов требований между planningIT и PPM
4. Требования, связанные со стратегическими целями оценены, переопределены, консолидированы и проверены на избыточность

a) Отклонены все требования, которые признаны слишком сложными или рискованными

b) Требования связаны с соответствующими целями бизнеса и стратегией ИТ.

c) Консолидированные наборы требований используются для создания предложений к проектам (Project proposals)

5. Предложения к проектам оценены и отправлены для дальнейшей обработки

a) Привязка элементов текущей архитектуры к предложениям к проекту

b) Оценка предложений к проекту с точки зрения влияния на ценность для бизнеса и архитектурной сложности

c) Создание правильно структурированного набора предложений

d) Создание одного или нескольких архитектурных решений с вариантами будущих (to-be) архитектур

e) Приглашение внутренних и внешних соискателей для организации процесса подготовки решений

• Создание детальной структуры работ с указанием минимальных оценок стоимости и требований к навыкам и квалификации для каждого решения

f) Оценка конкурирующих вариантов архитектурных решений по сложности, затратами времени, стоимости и требованиями к навыкам и квалификации

g) Выбор предпочтительного решения для последующей обработки

h) Уточнение сгруппированных вариантов решений (Business case) и создание бюджетных статей в соответствии со правилами оформления заявок на инвестирование

i) Передача заявок на проекты для приоритизации и бюджетирования

6. Приоритизация заявок к проектам и их бюджетных статей завершение процесса создания наборов проектов

• Входящие заявки на проекты группируются для приоритизации и принятия решения

• Проверка формальной правильности бюджетных статей

• Оценка бюджетных статей в соответствии с требованиями стандартов

• Приоритизация заявок, одобрение в случае приемлемости

7. Отправка проектов для реализации в подразделение по управлению программами (Program Management Office)

• Каждая бюджетная статья становится проектом; подчиненные мероприятия (work items) могут транслироваться в задачи подпроектов

• Требования к навыкам и квалификации транслируются в ресурсные (resource pool) требования

8. Обзор параметров проекта и запуск подпроектов для более детального планирования проектов
9. Детальное планирование проекта с определением задач и распределение ресурсов в соответствии с их наличием и требованиями к квалификации и навыкам
10. Доступные ресурсы, календарные планы, описания и т.д. управляются через модуль управления ресурсами (PPM Resource Management).
11. Табельные листы (Time sheet) ведутся в модуле учета времени (PPM Time Management) для нужд управления и детального контроля за расходованием и использованием ресурсов по проектам, подпроектам, периодам и задачам.
12. Двусторонний обмен между модулями учета времени (Time Management) и управления ресурсами (Resource Management) обеспечивает свежей информацией, используемой для планирования и выполнения проектов.
13. Степень исполнения проектов и состояние всех исполняемых проектов отслеживается в модуле управления проектами (Project Management).
14. Обобщенные данные о изменении состояния по бюджетным статьям и мероприятиям передаются в модуль управления портфелем программ (Program Portfolio Management) системы planningIT, что позволяет осуществлять на их основе другие раунды приоритизации и бюджетирования.

15. Модуль управления программ (Program Management) регистрирует нарушения в исполнении проектов и категоризирует их. Запросы на изменение содержания проекта (Scope change) получают высочайший уровень нарушения, когда они влияют на бизнес-наборы и соответствующие архитектурные решения.

16. Запросы на изменение содержания проекта передаются в planningIT.
17. Запросы на изменение содержания проекта определяют по их влиянию на архитектуру. Возможные варианты:

• Изменение в сроках приводит к разрыву структуры архитектуры за счет смещения доступности отдельных элементов в другой момент времени. Это требует учета в других инициативах, которые могут зависеть от изменений в данном проекте.

• Изменение в бизнес-наборах произошедшее из-за изменений в сроках или в содержании проекта. Это приводит к последующим раундам приоритизации и бюджетирования.

• Изменения в решениях, связанных с трансформацией архитектуры и соответствующих бизнес-наборах.

18. Результирующая заявка на изменение содержания проекта передается для приоритизации и ободрения в модуль управления портфелем проектов (Portfolio Management) в planningIT.
19. Когда заявка на изменение содержания проекта одобрена, новое архитектурное решение передается в единый репозитарий (inventory) замещая ранее одобренное решение.
20. Бюджетные статьи и мероприятия возвращаются обратно в модуль управления программами (PPM Program Management) для последующего исполнения. Последовательно исполняются шаги после шага 8.