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

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

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

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

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

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

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

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

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

Портфель ИТ-решений

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

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

Ответственность и руководство в иерархии

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

Примечание

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

• Портфолио: Команда по облачной стратегии и облачный центр передового опыта (CCoE) используют методологии стратегии и планирования для принятия решений, влияющих на общий портфель. Команда по облачным стратегиям ответственна за корпоративный уровень иерархии облачных портфелей. Команда по облачной стратегии также должна знать о решениях, касающихся среды, целевых зон и рабочих нагрузок с высоким приоритетом.
• Облачные платформы: Команда управления облаком отвечает за дисциплины, обеспечивающие согласованность в каждой среде в соответствии с методологией управления . Команда по управлению облаком ответственна за управление всеми ресурсами во всех средах. Команда по управлению облаком должна консультироваться по изменениям, в результате которых могут потребоваться исключения из политики управления или ее корректировки. Команда управления облаком также должна получать информацию о ходе выполнения рабочей нагрузки и внедрении ресурсов.
• Целевые зоны и облачная платформа: команда облачной платформы ответственна за разработку целевых зон и служебных программ платформы для поддержки внедрения. Группа по автоматизации облака ответственна за автоматизацию разработки и постоянную поддержку таких элементов, как целевые зоны и служебные программы платформы. Обе команды используют методологию готовности для реализации. Обе команды должны быть осведомлены о ходе внедрения рабочей нагрузки и любых изменениях на предприятии или в среде.
• Рабочие нагрузки: внедрение происходит на уровне рабочей нагрузки. Команды по внедрению облачных технологий используют методологии миграции и инноваций для создания масштабируемых процессов для ускорения внедрения. После завершения внедрения права владения рабочими нагрузками, скорее всего, будут переданы группе облачных операций, которая использует методологию управления для управления операциями. Обе команды должны быть хорошо знакомы с 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 поддерживают иерархию портфеля.