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

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

Расширение общей области

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

Структура бизнес-результатов

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

Результат	Измерение	Цель	Интервал времени	Приоритет действия
Сокращение расходов на ИТ	Бюджет центра обработки данных	Сокращение на 2 млн долл. США	12 месяцев	1
Прекращение использования центров обработки данных	Уход из центров обработки данных	2 центра обработки данных	6 месяцев	2
Повышение гибкости организации	Сокращение времени выхода на рынок	Сокращение времени развертывания на шесть месяцев	2 года	3
Улучшение качества взаимодействия с клиентами	Удовлетворенность клиентов (CSAT)	Улучшение на 10 %	12 месяцев	4

Важно!

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

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

Быстрые действия с сохранением баланса

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

Важность решений о прекращении использования

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

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

• Использовалась ли рабочая нагрузка пользователями в течение последних шести месяцев?
• Трафик пользователей остается стабильным или растет?
• Потребуется ли эта рабочая нагрузка в течение 12 месяцев с настоящего момента?

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

• Можно ли установить план прекращения использования или план истечения срока действия для этой рабочей нагрузки?
• Можно ли прекратить использование этой рабочей нагрузки до ухода из центра обработки данных?

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

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

Изменения в процессе внедрения

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

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

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

• Команда по облачной стратегии поддерживает очередь невыполненной работы с установленными приоритетами для рабочих нагрузок, которые будут перенесены.
• Команда по вопросам облачной стратегии и команда по внедрению в облако проводят собрание по планированию выпуска перед завершением каждого выпуска.
• На собрании по планированию выпуска группы договариваются о 5–10 основных рабочих нагрузках в очереди невыполненной работы с установленными приоритетами.
• До собрания по планированию выпуска группа по внедрению облачных технологий задает следующие вопросы владельцам приложений и профильным специалистам:
  • Можно ли заменить это приложение эквивалентным решением PaaS (платформа как услуга)?
  • Это приложение стороннего производителя?
  • Утвержден ли бюджет для вложений в текущую разработку приложения на следующие 12 месяцев?
  • Улучшит ли дополнительная разработка этого приложения взаимодействие с клиентами? Вы создаете конкурентное решение? Оно приносит дополнительный доход организации?
  • Будут ли данные в этой рабочей нагрузке использоваться в последующих инновациях, связанных с бизнес-аналитикой, машинным обучением, Интернетом вещей или подобными технологиями?
  • Совместима ли рабочая нагрузка с современными платформами приложений, такими как Служба приложений Azure?
• Ответы на приведенные выше вопросы и результаты любого другого необходимого качественного анализа повлияют на изменение приоритетов невыполненной работы. Эти изменения могут включать в себя следующее.
  • Если рабочую нагрузку можно заменить решением PaaS, она может быть полностью удалена из очереди невыполненной работы по миграции. Как минимум, следует добавить задачу дополнительного комплексного анализа, позволяющего выбрать между повторным размещением и заменой, временно понизив приоритет этой рабочей нагрузки в очереди невыполненной работы по миграции.
  • Если рабочая нагрузка находится (или должна находиться) в процессе разработки, то для нее лучше применить модель рефакторинга, перепроектирования или перестроения. Поскольку инновации и миграция требуют разных технических навыков, для управления приложениями, подходящими для применения метода рефакторинга, перепроектирования и перестроения, рекомендуется использовать очередь невыполненных работ по инновациям, а не очередь невыполненных работ по миграции.
  • Если рабочая нагрузка используется в последующих инновациях, то может быть целесообразно выполнить рефакторинг платформы данных, а для прикладных уровней запланировать повторное размещение. Незначительный рефакторинг платформы данных рабочей нагрузки часто можно выполнить с помощью очереди невыполненной работы по миграции или инновации. Рационализация может привести к добавлению более детальных рабочих элементов в очередь невыполненной работы, но зато изменять приоритеты не потребуется.
  • Если рабочая нагрузка не является стратегический, но совместима с современными облачными платформами размещения приложений, возможно, будет целесообразно выполнить незначительный рефакторинг приложения, чтобы развернуть его как современное приложение. Это может повлиять на общую экономию, так как сократится количество лицензий для IaaS и ОС, необходимых для миграции в облако.
  • Если рабочая нагрузка является сторонним приложением, а ее данные не планируется использовать в последующих инновациях, то лучше оставить ее как кандидат для повторного размещения в очереди невыполненной работы.

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

Изменения процесса миграции

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

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

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

Повторное размещение: требует, чтобы члены группы реализовывали изменения инфраструктуры. Обычно они используют такие инструменты, как Azure Site Recovery, чтобы перенести виртуальные машины или другие ресурсы в Azure. Эта работа хорошо подходит администраторам центра обработки данных или разработчикам ИТ. Команда по миграции в облако имеет все необходимое для выполнения этой работы в большом масштабе. В большинстве сценариев это самый быстрый подход к переносу существующих ресурсов.

Рефакторинг: требует, чтобы члены группы изменяли исходный код, изменяли архитектуру приложения или внедряли новые облачные службы. Как правило, для этого применяются инструменты разработки, такие как Visual Studio, и инструменты конвейера развертывания, такие как Azure DevOps, для повторного развертывания модернизированных приложений в Azure. Эта работа хорошо подходит разработчикам приложений или разработчикам конвейеров DevOps. Группа по облачным инновациям лучше всего укомплектована для выполнения этой работы. Замена существующих ресурсов облачными при таком подходе может занять больше времени, но приложения смогут использовать преимущества собственных функций облака.

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

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

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

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

Общие сведения о глобальных рынках