Балансировка приоритетов конкурирующих задач

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

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

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

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

Общая тема подхода Cloud Adoption Framework

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

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

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

Баланс во время этапа стратегии

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

Конкурирующие приоритеты.

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

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

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

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

Балансировка на этапе планирования

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

Конкурирующие приоритеты.

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

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

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

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

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

Балансировка на этапе готовности

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

Конкурирующие приоритеты.

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

• Время внедрения: облачные инструменты, такие как Политика Azure, непрерывная интеграция и непрерывная доставка (CI/CD), такие как инфраструктура, как код (IaC), и группы управления могут упростить процесс рефакторинга на ит-платформе. Кроме того, предопределенные целевые зоны предоставляют рекомендации по ускорению развертывания в среде, которая уже соответствует многим требованиям к четности компонентов. Эти средства предоставляют возможности для ускорения времени на рынок с минимальным воздействием на долгосрочные операции.

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

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

Балансировка на этапе миграции

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

Конкурирующие приоритеты.

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

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

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

Развернутый область пример: для критически важных или высокочувствительной рабочей нагрузки, таких как мейнфрейм или многоуровневые микрослужбы, на этапе оценки может потребоваться более тщательная оценка рабочей нагрузки. В этих ситуациях вы должны использовать проверку Azure Well-Architected и Платформу Azure Well-Architected Framework для уточнения требований к рабочей нагрузке во время оценки.

Балансировка на этапе инновации

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

Конкурирующие приоритеты.

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

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

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

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

Балансировка на этапе управления

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

Конкурирующие приоритеты.

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

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

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

Балансировка на этапе менеджмента

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

Конкурирующие приоритеты.

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

• No-ops и low-ops: используйте средства для работы с облаком, чтобы свести к минимуму повторяющиеся и повторяющиеся задачи, которые ранее были доставлены сотрудниками. Сокращение этих операционных зависимостей освобождает сотрудников для повышения ценности другими способами. Однако этот подход может привести к поддержке операций подпара.

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

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

Баланс на этапе организации

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

Конкурирующие приоритеты.

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

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

Минимальная область: большинство организаций проходят естественный набор эволюций с течением времени. Методология организации описывает наиболее распространенный ряд изменений. Мы рекомендуем командам попытаться перейти к облачному центру превосходства (CCoE) для предоставления делегированных подходов к управлению.

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

Следующие шаги

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

Balance the portfolio (Балансировка портфеля)