Иерархия портфеля

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

Рабочие нагрузки

Набор технологий, обеспечивающих определённую ценность для бизнеса, называется рабочей нагрузкой. Коллекция может включать приложения, серверы или виртуальные машины, данные, устройства и другие аналогичные сгруппированные ресурсы. Большинство предприятий полагаются на несколько рабочих нагрузок для обеспечения жизненно важных бизнес-функций.

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

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

Хотя термины могут отличаться, все ИТ-решения включают ресурсы и рабочие нагрузки:

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

При развертывании первой рабочей нагрузки рабочая нагрузка и её ресурсы могут быть единственной заданной областью. Другие уровни могут быть явно определены по мере развертывания большего количества рабочих нагрузок.

ИТ-портфель

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

• Зоны высадки: Зоны высадки предоставляют рабочим нагрузкам необходимые базовые служебные программы или общие инфраструктурные компоненты, которые необходимы для поддержки одной или нескольких рабочих нагрузок. Зоны высадки настолько важны в облаке, что вся методология Ready в рамках Cloud Adoption Framework сосредоточена на зонах высадки. Более подробное определение см. в разделе Что такое целевая зона?
• Фундаментальные утилиты: Эти общие ИТ-службы необходимы для рабочих нагрузок, чтобы функционировать в рамках технологического и бизнес-портфеля.
• Основа платформы: Эта организационная конструкция централизует базовые решения и помогает гарантировать, что контроль соблюдается для всех целевых зон.
• Облачные платформы: В зависимости от общей стратегии поддержки полного портфеля клиентам может потребоваться несколько облачных платформ с различными развертываниями платформы для управления несколькими регионами, гибридными решениями или даже решениями с несколькими облаками.
• Портфель: с точки зрения технологии, портфель — это коллекция задач, активов и вспомогательных ресурсов, охватывающих все облачные платформы. Благодаря бизнес-объективу портфель — это коллекция проектов, людей, процессов и инвестиций, которые поддерживают и управляют технологическим портфелем для достижения бизнес-результатов. Вместе эти два объектива фиксируют портфолио.

Подотчетность иерархии и рекомендации

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

Заметка

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

• Портфолио: команда по облачным стратегиям и облачный центр передового опыта (CCoE) используют методологии Стратегии и Плана для принятия решений, влияющих на общий портфель. Группа облачных стратегий отвечает за корпоративный уровень иерархии облачного портфеля. Команда по облачной стратегии также должна быть проинформирована о решениях о среде, целевых зонах и высокоприоритетных рабочих нагрузках.
• Облачные платформы: команда по управлению облачными решениями отвечает за ограничения, обеспечивающие согласованность в каждой среде в соответствии с методологией Govern. Команда управления облаком отвечает за управление всеми ресурсами во всех средах. Следует обращаться к команде управления облаком по поводу изменений, которые могут потребовать исключения или изменения в политиках управления. Команда управления облаком также должна быть проинформирована о ходе внедрения рабочих нагрузок и ресурсов.
• Целевые зоны и облачный фонд: команда облачной платформы отвечает за разработку целевых зон и служебных программ платформы, которые поддерживают внедрение. Команда автоматизации облака отвечает за автоматизацию разработки и непрерывной поддержки этих целевых зон и служебных программ платформы. Обе команды используют методологию Ready для руководства по реализации. Обе команды должны быть проинформированы о ходе внедрения рабочей нагрузки и любых изменений в корпоративной или среде.
• рабочих нагрузок: внедрение происходит на уровне рабочей нагрузки. Команды по внедрению облачных решений используют методологии Миграции и Инноваций для создания масштабируемых процессов, ускоряющих внедрение. После завершения принятия ответственность за рабочие нагрузки, скорее всего, передается команде облачных операций, которая использует методологию для управления операциями. Обе команды должны уверенно использовать Microsoft Azure Well-Architected Framework для принятия подробных архитектурных решений, влияющих на рабочие нагрузки, которые они обслуживают. Обе команды должны быть проинформированы об изменениях в зонах высадки и условиях. Обе команды могут иногда вносить вклад в особенности зоны посадки.
• Активы: Активы обычно находятся в зоне ответственности команды облачных операций. Эта команда использует основу управления в методологии Управление для принятия решений по управлению операциями. Он также должен использовать Помощник по Azure и Azure Well-Architected Framework, чтобы внести подробные изменения ресурсов и архитектуры, необходимые для выполнения требований к операциям.

Варианты подотчетности

• отдельная среда: Если для предприятия требуется только одна среда, обычно не требуется CCoE.
• Единственная зона размещения: Если в среде присутствует только одна зона размещения, возможности управления и платформы, вероятно, можно объединить в одну команду.
• Одновременная рабочая нагрузка: Некоторым предприятиям требуется только одна рабочая нагрузка или несколько рабочих нагрузок в одной целевой зоне и одной среде. В таких случаях не требуется разделение обязанностей между группами управления, платформы и операций.

Распространенные примеры рабочей нагрузки и подотчетности

В следующих примерах показана иерархия портфеля.

Рабочие нагрузки COTS

Традиционно предприятия предпочитали коммерческое готовое программное обеспечение (COTS) для поддержки бизнес-процессов. Эти решения устанавливаются, настраиваются и работают. После настройки мало изменений в архитектуре решений.

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

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

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

В разработке с активными изменениями

Если готовое коммерческое решение (COTS) или услуга PaaS не соответствует потребностям бизнеса или решение отсутствует, предприятия создают настраиваемые рабочие нагрузки. Как правило, только небольшой процент ИТ-портфеля использует этот подход к рабочей нагрузке. Но эти рабочие нагрузки, как правило, обусловливают непропорционально высокий процент вклада ИТ в бизнес-результаты, особенно результаты, связанные с новыми потоками доходов. Эти рабочие нагрузки, как правило, хорошо сопоставляются с новыми инновационными идеями.

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

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

Ремонт по запросу или завершение разработки

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

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

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

Критически важные рабочие нагрузки

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

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

Примеры критически важных рабочих нагрузок с обязательным разделением обязанностей включают такие рабочие нагрузки, как SAP, Oracle или другие решения для планирования корпоративных ресурсов (ERP), охватывающие несколько бизнес-подразделений в компании.

Выравнивание портфеля стратегий

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

Портфель, ориентированный на инновации или развитие

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

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

выравнивание портфеля: ИТ-портфель, скорее всего, сосредоточится на рабочих нагрузках и владельцах рабочих нагрузок для принятия критически важных решений по архитектуре. Эти команды, скорее всего, будут находить больше ценности в руководстве по Azure Well-Architected Framework во время внедрения и операций.

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

Портфель под управлением операций

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

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

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

Портфель, сформированный под влиянием миграции

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

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

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

Портфель, управляемый принципами управления

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

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

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

Дальнейшие действия

Узнайте, как продукты Azure поддерживают иерархию портфеля.