Balancear as prioridades concorrentes

O sucesso de qualquer transformação digital é determinado pela capacidade dos stakeholders de negócios e tecnologia de equilibrar prioridades concorrentes.

Assim como outras transformações digitais, a adoção da nuvem expõe prioridades concorrentes em todo o ciclo de vida de adoção. E assim como acontece com outras formas de transformação, a capacidade de equilibrar essas prioridades tem um efeito significativo na realização do valor comercial. Equilibrar essas prioridades concorrentes requer conversas abertas e às vezes difíceis entre os stakeholders e, às vezes, com colaboradores individuais.

Este artigo descreve algumas das prioridades concorrentes comumente discutidas durante a implementação de cada metodologia. Ele pode ajudá-lo a se preparar para essas discussões ao desenvolver sua estratégia de adoção da nuvem.

Diagrama que fornece uma visão geral do ciclo de vida de adoção da nuvem.

As seções a seguir se alinham ao fluxo no diagrama de ciclo de vida de adoção da nuvem anterior. No entanto, é importante reconhecer que a adoção da nuvem é um processo iterativo, não sequencial, e que essas prioridades concorrentes podem reemergir em vários pontos durante sua jornada de adoção da nuvem.

O tema geral da abordagem Cloud Adoption Framework

Soluções monolíticas e planejamento avançado baseiam-se em uma série de suposições que podem ser imprecisas ao longo do tempo. A adoção da nuvem geralmente é uma nova experiência para uma empresa e suas equipes técnicas. Assim como acontece com a maioria das novas experiências, há alguma probabilidade de que essas suposições iniciais sejam comprovadamente incorretas.

Seguir os princípios Agile comprovados das decisões técnicas atrasadas é a abordagem preferida para a maioria das diretrizes nessa estrutura. Essa abordagem segue um padrão consistente: estabelecer um estado final geral, mover rapidamente para a implementação inicial, testar e validar suposições e refatorar antecipadamente para resolver suposições com falha. Esse tipo de mentalidade de crescimento maximiza o aprendizado e minimiza o risco de valor comercial, mas exige um pouco tolerância à ambiguidade.

Às vezes, a ambiguidade pode ser mais assustadora, ou mais perigosa, do que falsas suposições. Embora essa estrutura priorize o aprendizado e o endereçamento da ambiguidade durante a implementação, muitas situações exigem que a equipe priorize abordagens baseadas em análise ou suposições. As seções a seguir fornecem pelo menos um "exemplo de escopo expandido" para ilustrar quando uma segunda iteração mais profunda pode ser valiosa.

Balancear durante a fase de estratégia

O objetivo principal da metodologia estratégia é desenvolver o alinhamento entre os stakeholders. Depois de definida, a posição estratégica alinhada orienta o comportamento em cada uma das metodologias para garantir que as decisões técnicas se alinhem aos resultados de negócios desejados. Promover o alinhamento entre os stakeholders cria um conjunto comum de prioridades concorrentes: profundidade de justificativa versus tempo de impacto nos negócios.

Prioridades dos concorrentes:

  • Profundidade da justificativa: Os stakeholders geralmente querem uma análise financeira profunda e uma justificativa comercial completa antes de se sentirem confortáveis em se alinhar a uma direção estratégica. Infelizmente, esse nível de análise pode exigir um longo período de tempo para permitir a coleta e análise de dados.
  • Tempo de impacto nos negócios: Por outro lado, os stakeholders geralmente são responsabilizados por fornecer resultados de negócios dentro de períodos definidos. A análise e a avaliação demoradas podem colocar esses resultados em risco antes mesmo do início do trabalho técnico.

Escopo mínimo: Encontrar o equilíbrio correto requer discussões de stakeholders no início do processo. A metodologia de estratégia sugere limitar o escopo do alinhamento durante esse esforço inicial. Na abordagem sugerida, os participantes concentram-se em alinhar um conjunto de motivações principais, resultados mensuráveis e uma justificativa de negócios de alto nível. Em seguida, os stakeholders devem se comprometer rapidamente com alguns projetos iniciais ou pilotos para impulsionar as oportunidades de aprendizado necessárias.

Exemplo de escopo expandido: Se a análise de negócios inicial indicar um alto risco de afetar negativamente os negócios, talvez os stakeholders precisem desacelerar e avaliar com mais cautela uma análise mais profunda durante a justificativa comercial.

Equilíbrio durante a fase de planejamento

Como durante a fase de estratégia, há uma necessidade durante a fase de planejamento para equilibrar a profundidade do planejamento inicial versus decisões técnicas atrasadas.

Prioridades dos concorrentes:

  • A profundidade do planejamento inicial para implementação técnica na nuvem geralmente se baseia em muitas suposições. Especialmente quando há lacunas de habilidades na equipe, o ambiente sofre de lacunas de descoberta ou as cargas de trabalho não têm estados finais de arquitetura claramente definidos. Todas essas suposições são comuns em planos de adoção de nuvem detalhados. Experimentação, pilotos e análise qualitativa são necessários para verificar ou melhorar essas suposições.
  • Decisões técnicas atrasadas baseiam-se na suposição de que, quanto mais tarde uma decisão técnica for tomada, mais precisa será. Seguir os princípios do planejamento ágil de produtos ajuda a atrasar as decisões técnicas, permitindo que elas ocorram no momento certo, com base em informações suficientes. No entanto, essa abordagem resulta em mais ambiguidade no plano inicial.

Escopo mínimo: Sugerimos abordagens ágeis de desenvolvimento de produtos para impulsionar a ação de prompt dentro de planos gerenciáveis. A metodologia De plano recomenda as seguintes etapas para alcançar esse equilíbrio:

  1. Inventariar todo o patrimônio digital usando ferramentas de descoberta automatizadas, mas usar a racionalização incremental para planejar até os próximos 1 a 3 meses de trabalho.
  2. Garanta que o alinhamento organizacional adequado seja obtido rapidamente.
  3. Crie um plano de preparação de habilidades para a equipe atribuída. Use o modelo estratégia e plano para implantar rapidamente uma lista de pendências inicial.

Exemplo de escopo expandido: A entrega de um plano de adoção da nuvem pode, às vezes, ser em resposta a um evento de negócios com diferenciação de tempo ou de alto impacto. Quando o sucesso requer a movimentação de um alto número de ativos durante um período fixo, as etapas anteriores geralmente são seguidas por um esforço de planejamento mais profundo. A chave para o sucesso nesses cenários é planejar o suficiente para começar e, em seguida, planejar o envolvimento completo. Essa abordagem reduz a probabilidade de que o planejamento bloqueie os resultados dos negócios.

Equilíbrio durante a fase de preparação

Quando as equipes estão se preparando para suas primeiras etapas na adoção da nuvem, geralmente há prioridades concorrentes entre o tempo para a adoção e as operações de longo prazo. A equipe pode ter dificuldades com o equilíbrio entre ser adequada para entregar a tarefa em questão e ser bem gerenciada. Esse esforço é necessário em ambientes de TI tradicionais, em que o ato de desenvolver uma plataforma requer ativos físicos e ciclos de aquisição. No entanto, quando toda a plataforma de TI é definida no código, as táticas de desenvolvimento tradicionais, como refatoração, reduzem a necessidade de serem bem gerenciadas desde o início.

Prioridades dos concorrentes:

  • Operações de longo prazo: As organizações geralmente são bloqueadas pelo desejo de ter um ambiente de nuvem que atenda à paridade de recursos com os sistemas atuais de gerenciamento de operações, governança e segurança. Em um estudo, mais de 90% das organizações precisavam de apoio para superar essa mentalidade. Esse bloqueador pode criar meses de atraso, desacelerando ou impedindo o impacto nos negócios.
  • Tempo de adoção: Ferramentas baseadas em nuvem, como Azure Policy, Azure Blueprints e grupos de gerenciamento, podem simplificar o processo de refatoração em toda a plataforma de TI. Além disso, as zonas de destino predefinidas fornecem recomendações para acelerar a implantação em direção a um ambiente que já atende a muitos requisitos de paridade de recursos. Essas ferramentas oferecem oportunidades para acelerar o tempo de comercialização com efeito mínimo em operações de longo prazo.

Escopo mínimo: a metodologia Pronto descreve um caminho direto de adoção rápida para operações de longo prazo. Essa abordagem começa com uma introdução básica às ferramentas que você pode usar para refatorar seu ambiente. As ferramentas levam em conta seus requisitos e orientam você para uma seleção de zonas de destino predefinidas, cada uma entregue com infraestrutura como modelos de código. Em seguida, você pode refatorar o código durante a adoção da nuvem para melhorar as operações, a segurança e o gerenciamento.

Exemplo de escopo expandido: Para equipes cujo plano de adoção exige um objetivo de médio prazo (dentro de 24 meses) para hospedar mais de 1.000 ativos (aplicativos, infraestrutura ou ativos de dados) na nuvem, recomendamos uma exibição mais robusta das zonas de destino. Nessas situações, você deve considerar as metodologias Controlar e Gerenciar durante as conversas iniciais da zona de destino. No entanto, essa consideração mais profunda muitas vezes adiciona semanas ou meses a um plano de adoção de nuvem. Para minimizar o efeito sobre os resultados dos negócios, a equipe de adoção deve testar cargas de trabalho reais na nuvem e, ao mesmo tempo, criar uma zona de destino mais madura e uma solução de arquitetura central.

Equilíbrio durante a fase de migração

Durante a migração, as equipes de adoção normalmente pressupõem que as cargas de trabalho serão hospedados novamente na nuvem em sua configuração atual. Essa suposição compete com um plano futuro para reorganizar cada carga de trabalho para aproveitar melhor as funcionalidades de nuvem. As duas exibições não são mutuamente exclusivas e podem ser complementares quando você as gerencia usando um processo comum.

Prioridades dos concorrentes:

  • Rehost: As organizações geralmente comparam a migração com uma abordagem lift-and-shift que replica todos os ativos para a nuvem em sua configuração atual. Essa abordagem resulta em pouco descompasso no portfólio de TI. Também é a maneira mais rápida de desativar ativos em um datacenter existente.
  • Rearquisitar: Modernizar a arquitetura de cada carga de trabalho maximiza o valor da adoção da nuvem entre custo, desempenho e operações. No entanto, essa abordagem é mais lenta e geralmente requer acesso ao código-fonte de cada aplicativo.

Escopo mínimo: Durante o planejamento em estágio inicial, use a opção de hospedagem para planejamento, com uma compreensão clara de que essa escolha se baseia em uma suposição de negócios inicial e não é uma decisão técnica. Na metodologia Migrar, a equipe de adoção da nuvem desafia essa suposição para cada carga de trabalho migrada. Essa metodologia segue a abordagem de avaliar/migrar/promover para cada carga de trabalho ou grupo de cargas de trabalho para criar uma fábrica de migração. Durante a fase de avaliação, a equipe de adoção avalia o ajuste técnico e a arquitetura de cada carga de trabalho. Esse esforço de avaliação raramente resulta em uma abordagem pura de comparação e deslocamento, pois muitos dos componentes da arquitetura tendem a ser selecionados para refatoração e modernização.

Exemplo de escopo expandido: Para cargas de trabalho críticas ou de alta sensibilidade, como aplicativos de microsserviços de mainframe ou multicamada, uma avaliação mais completa da carga de trabalho pode ser necessária durante a fase de avaliação. Nessas situações de rearquitetura, você deve usar o Azure Well-Architected Review e o Azure Well-Architected Framework para refinar os requisitos de carga de trabalho durante a avaliação.

Equilíbrio durante a fase de inovação

A verdadeira inovação voltada para o cliente frequentemente cria prioridades conflitantes entre a necessidade de fornecer um conjunto de recursos planejado e implementar um processo de desenvolvimento de empatia pelo cliente.

Prioridades dos concorrentes:

  • Foco do recurso: os planos iniciais para a inovação se baseiam nos recursos de nuvem e propriedade digital existentes para fornecer um conjunto de recursos que atendem a uma necessidade do cliente. É fácil permitir que o plano impulsione a implementação técnica, levando a um esforço de desenvolvimento focado em recursos. Essa abordagem geralmente leva à satisfação temporária dos stakeholders, mas reduz a probabilidade de impulsionar a inovação que influencia o comportamento do cliente.
  • Empatia do cliente: os planos iniciais são uma parte importante do lado comercial do desenvolvimento e devem ser incluídos em relatórios regulares. No entanto, aprender, medir e criar com empatia do cliente como meta é uma medida mais precisa de sucesso em um esforço de inovação. O foco nos clientes em relação aos recursos é mais provável que resulte em satisfação do cliente de curto e longo prazo e impacto nos negócios.

Escopo mínimo: A metodologia Inovar ilustra como integrar estratégias e planos por meio de consenso de valor empresarial. Em seguida, o guia apresenta ferramentas nativas de nuvem que podem acelerar cada disciplina de inovação e práticas recomendadas para implementação. Por fim, a seção aprimoramentos do processo demonstra abordagens para criar empatia do cliente, respeitando planos e estratégias em toda a jornada de adoção da nuvem. Essa abordagem se concentra em fornecer inovação com o uso do mínimo possível de tecnologia.

Exemplo de escopo expandido: Às vezes, uma inovação depende de cargas de trabalho críticas ou de alta confidencialidade. Quando o cliente é um usuário interno, o esforço de desenvolvimento pode ser crítico e de alta confidencialidade durante as primeiras iterações. Nesses cenários, as equipes de adoção devem usar o Azure Well-Architected Review e o Azure Well-Architected Framework para avaliar o design de arquitetura avançado no início do processo.

Equilíbrio durante a fase de governança

A prática da governança de nuvem é um equilíbrio entre duas prioridades concorrentes: velocidade e agilidade em relação a um ambiente bem controlado. A equipe de governança de nuvem se concentra em avaliar e minimizar os riscos para os negócios por meio de controles uniformes e minimizar as alterações. A equipe de adoção se concentra na condução de resultados de negócios, que exigem novos riscos e criam alterações inerentemente.

Prioridades dos concorrentes:

  • Bem governada: cada controle projetado para minimizar os riscos bloqueia algum aspecto das opções de design de alteração ou limites. O controle é essencial para um ambiente bem controlado. No entanto, quando os controles são projetados e implantados isoladamente, eles podem ser tão prejudiciais quanto os riscos que se destinam a evitar.
  • Velocidade e agilidade: velocidade e agilidade são requisitos de negócios fundamentais na economia digital. Ambos exigem a capacidade de impulsionar alterações com bloqueadores mínimos para inovação ou adoção. Mas quando a mudança é impulsionada sem governança, ela gera novos riscos que podem prejudicar os negócios de maneiras inesperadas.

Escopo mínimo: a metodologia de Governança sugere que nem a governança nem a adoção devem ocorrer isoladamente. Essa metodologia começa com uma compreensão das disciplinas de governança e uma conversa sobre risco, política e processo de negócios. Como participante ativo em toda a adoção da nuvem, a equipe de governança pode implementar um conjunto mínimo de proteções para lidar com os riscos tangíveis dentro do plano de adoção da nuvem. Com o tempo, a equipe de governança pode refatorar e expandir essas proteções para atender a novos riscos. Essa abordagem maximiza o aprendizado e a inovação, minimizando o risco.

Exemplo de escopo expandido: Quando o risco comercial é alto, especialmente no início da adoção, a equipe de governança de nuvem pode precisar acelerar a expansão das implementações de governança. Você pode usar as mesmas diretrizes e exercícios para adicionar esse nível mais alto de governança, mas talvez seja necessário ir mais rápido. Em alguns cenários, um estado avançado de governança pode até ser necessário enquanto você está desenvolvendo as primeiras zonas de destino.

Equilíbrio durante a fase de gerenciamento

O modelo de negócios de TI para gerenciamento de operações evoluiu continuamente na última década. À medida que a manutenção de hardware se move mais longe da proposta de valor principal da TI, a exibição sobre o gerenciamento de operações mudou. À medida que a TI aumenta o foco na entrega de valor comercial, as equipes de gerenciamento de operações estão em conflito com a necessidade de equilibrar operações sem operações e baixas operações em comparação com investimentos amplos.

Prioridades dos concorrentes:

  • Investimentos amplos: investir igualmente em prevenção de paralisação, recuperação rápida e monitoramento em todo o ambiente é a abordagem tradicional para o gerenciamento de operações. Essa abordagem pode ser cara e, às vezes, duplica os produtos de suporte fornecidos pelo fornecedor de nuvem.
  • No-ops e low-ops: Use ferramentas de operações nativas de nuvem para minimizar tarefas repetitivas e recorrentes que foram entregues anteriormente por seus funcionários. A redução dessas dependências operacionais libera os funcionários a gerar valor de outras maneiras. No entanto, isoladamente, essa abordagem pode levar ao suporte a operações de subpar.

Escopo mínimo: a metodologia de Gerenciamento sugere o estabelecimento de uma linha de base sem operações nativa de nuvem. Reconhecendo que a linha de base sem operações não atenderá a todas as necessidades de negócios, trabalhe com a empresa para definir compromissos e alinhar melhor os investimentos. Expanda a linha de base para atender às necessidades comuns de todas as cargas de trabalho. Em seguida, capacite equipes de plataforma ou de carga de trabalho específicas para manter soluções bem gerenciadas em um ambiente bem gerenciado.

Exemplo de escopo expandido: Na maioria dos ambientes, o valor comercial de um pequeno percentual de cargas de trabalho justifica investimentos profundos em operações de TI. Para essas cargas de trabalho, talvez a equipe de TI queira usar o Azure Well-Architected Review e o Azure Well-Architected Framework para orientar operações mais profundas.

Equilíbrio durante a fase da organização

As prioridades concorrentes descritas neste artigo refletem o impulso da TI para lidar com as demandas de negócios por velocidade e agilidade. A mesma mudança está aparecendo em alterações em gráficos de organização ou estruturas de equipe virtual para fornecer melhor suporte para resultados de negócios. À medida que os líderes de TI refletem sobre as estruturas de equipe, duas prioridades concorrentes normalmente são abordadas: controle centralizado versus controle delegado.

Prioridades dos concorrentes:

  • Controle centralizado: Esse modelo operacional se concentra na centralização de todos os controles necessários para impor políticas rígidas. Nesse modelo, a TI serve como um bloqueador para inovação, velocidade e agilidade. No entanto, a TI pode garantir um grau mais alto de estabilidade, conformidade e segurança.
  • Controle delegado: Nesse modelo operacional distribuído, supõe-se que cada equipe de DevOps ou equipe de aplicativos de negócios fornecerá seu próprio conjunto de controles, com base nas soluções necessárias para cumprir os objetivos de negócios. Nesse modelo, a TI fornece diretrizes para ajudar as equipes a evitar riscos, mas minimiza o número de restrições técnicas impostas sempre que possível.

Escopo mínimo: A maioria das organizações passa por um conjunto natural de evoluções ao longo do tempo. A metodologia de organização descreve a série mais comum de evoluções. Recomendamos que as equipes tentem se mover em direção a uma estrutura de CCoE (centro de excelência em nuvem) para fornecer abordagens de controle delegadas.

Exemplo de escopo expandido: Muitas situações disparam a necessidade de controle centralizado. Requisitos de conformidade de terceiros e exposição temporária de segurança são dois exemplos de gatilhos para controle centralizado. Nessas situações, geralmente há a necessidade de estabelecer políticas de limitação e controles rígidos e fixos. No entanto, para permitir que a inovação e a adoção continuem, incentivamos as equipes centrais de TI a fornecer esses controles com base na criticalidade e sensibilidade de cada carga de trabalho. Fornecer ambientes com menos controle, mas um escopo reduzido ou perfil de risco permite flexibilidade mesmo quando o controle é necessário.

Próximas etapas

Aprenda a equilibrar migração, inovação e experimentação para maximizar o valor dos esforços de migração na nuvem.