Balancear as prioridades concorrentes
O sucesso de qualquer transformação digital é determinado pela capacidade das partes interessadas de negócios e tecnologia de equilibrar as prioridades concorrentes.
Como outras transformações digitais, a adoção da nuvem expõe prioridades concorrentes em todo o ciclo de vida da adoção. E, como acontece com outras formas de transformação, a capacidade de equilibrar essas prioridades tem um efeito significativo na realização do valor do negócio. Equilibrar essas prioridades concorrentes requer conversas abertas e, às vezes, difíceis entre as partes interessadas e, às vezes, com contribuintes 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.
As seções a seguir se alinham ao fluxo no diagrama de ciclo de vida de adoção de nuvem anterior. No entanto, é importante reconhecer que a adoção da nuvem é um processo iterativo, não sequencial, e que essas prioridades concorrentes podem ressurgir em vários pontos durante sua jornada de adoção da nuvem.
O tema geral da abordagem do Cloud Adoption Framework
Soluções monolíticas e planejamento avançado são construídos sobre uma série de suposições que podem se provar imprecisas ao longo do tempo. Adotar a nuvem costuma ser uma experiência nova para uma empresa e suas equipes técnicas. Como acontece com a maioria das novas experiências, há alguma probabilidade de que essas suposições iniciais se provem 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: estabeleça um estado final geral, avance rapidamente para a implementação inicial, teste e valide suposições e refatore antecipadamente para resolver suposições defeituosas. Esse tipo de mentalidade de crescimento maximiza o aprendizado e minimiza o risco de valor comercial, mas exige um pouco tolerância à ambiguidade.
A ambiguidade às vezes pode ser mais assustadora, ou mais perigosa, do que falsas suposições. Embora essa estrutura priorize o aprendizado e a abordagem da ambiguidade durante a implementação, muitas situações exigem que a equipe priorize abordagens baseadas em análise ou em 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.
Equilíbrio durante a fase de estratégia
O objetivo central da metodologia da Estratégia é desenvolver o alinhamento entre as partes interessadas. Depois de definida, a posição estratégica alinhada direciona o comportamento em cada uma das metodologias para garantir que as decisões técnicas estejam alinhadas com os resultados de negócios desejados. Promover o alinhamento entre as partes interessadas cria um conjunto comum de prioridades concorrentes: profundidade da justificativa versus tempo para impacto nos negócios.
Prioridades dos concorrentes:
Profundidade da justificativa: as partes interessadas geralmente querem uma análise financeira profunda e uma justificativa completa do negócio 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 período de tempo prolongado para permitir a coleta e análise de dados.
Tempo para impacto nos negócios: Por outro lado, as partes interessadas geralmente são responsabilizadas por entregar resultados de negócios dentro de prazos 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 com as partes interessadas 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. As partes interessadas devem, então, comprometer-se rapidamente com alguns projetos iniciais ou pilotos para impulsionar as oportunidades de aprendizagem necessárias.
Exemplo de escopo expandido: se a análise comercial inicial indicar um alto risco de afetar negativamente os negócios, as partes interessadas talvez precisem desacelerar e avaliar com mais cautela uma análise mais profunda durante a justificativa do negócio.
Equilíbrio durante a fase de planejamento
Como durante a fase de estratégia, há uma necessidade durante a fase de planejamento de 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 é baseada em muitas suposições. Especialmente quando há lacunas de habilidades na equipe, o ambiente sofre com 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.
As decisões técnicas tardias baseiam-se no pressuposto de que quanto mais tarde uma decisão técnica é tomada, mais precisa ela é. Seguir princípios de planejamento ágil de produtos ajuda a atrasar decisões técnicas, permitindo que elas aconteçam 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ções imediatas dentro de planos gerenciáveis. A metodologia do Plano recomenda os seguintes passos para alcançar esse equilíbrio:
- Faça o inventário de todo o patrimônio digital usando ferramentas de descoberta automatizadas, mas use a racionalização incremental para planejar os próximos 1 a 3 meses de trabalho.
- Garanta que o alinhamento organizacional adequado seja obtido rapidamente.
- 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 de nuvem às vezes pode ser uma resposta a um evento de negócios sensível ao tempo ou de alto impacto. Quando o sucesso requer a movimentação de um alto número de ativos durante um período fixo de tempo, 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, posteriormente, planejar o engajamento total. 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 seus primeiros passos na adoção da nuvem, geralmente há prioridades concorrentes entre o tempo de adoção e as operações de longo prazo. A equipe pode ter dificuldades com o equilíbrio entre ser bem 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 em código, as táticas tradicionais de desenvolvimento, como a refatoração, reduzem a necessidade de ser bem gerenciado 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, retardando ou impedindo o impacto nos negócios.
Tempo para adoção: ferramentas baseadas em nuvem, como a Política do Azure, integração contínua e abordagens de entrega contínua (CI/CD), como infraestrutura como código (IaC) e grupos de gerenciamento, podem simplificar o processo de refatoração em toda a plataforma de TI. Além disso, as zonas de aterrissagem predefinidas fornecem recomendações para acelerar a implantação em direção a um ambiente que já atenda a muitos requisitos de paridade de recursos. Essas ferramentas oferecem oportunidades para acelerar o tempo de lançamento no mercado com o mínimo de efeito nas 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 o guiam para uma seleção de zonas de pouso predefinidas, cada uma fornecida com modelos IaC. 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 visão mais robusta das zonas de aterrissagem. Nessas situações, você deve considerar as metodologias Governar e Gerenciar durante as conversas iniciais da zona de aterrissagem. 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 nos resultados de negócios, a equipe de adoção deve testar cargas de trabalho reais na nuvem e, ao mesmo tempo, criar uma zona de aterrissagem 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 geralmente assumem que as cargas de trabalho serão rehospedadas na nuvem em sua configuração atual. Essa suposição compete com um plano voltado para o futuro para rearquitetar cada carga de trabalho para aproveitar melhor os recursos de nuvem. Os dois modos de exibição não são mutuamente exclusivos e podem ser complementares quando você os gerencia usando um processo comum.
Prioridades dos concorrentes:
Rehost: as organizações geralmente igualam a migração a uma abordagem lift-and-shift que replica todos os ativos para a nuvem em sua configuração atual. Essa abordagem resulta em pouca deriva dentro do portfólio de TI. Também é a maneira mais rápida de aposentar ativos em um datacenter existente.
Rearquitetar: modernizar a arquitetura de cada carga de trabalho maximiza o valor da adoção da nuvem em termos de 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 rehost para planejamento, com um entendimento claro de que essa escolha é baseada em uma suposição comercial 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 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 de missão crítica ou de alta sensibilidade, como aplicativos de microsserviços de mainframe ou multicamadas, 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 entregar um conjunto de recursos planejado e a implementação de um processo de desenvolvimento de empatia com o 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 conduza a implementação técnica, levando a um esforço de desenvolvimento focado em recursos. Essa abordagem geralmente leva à satisfação temporária das partes interessadas, 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 construir com a empatia do cliente como meta é uma medida mais precisa do sucesso em um esforço de inovação. É mais provável que o foco nos clientes em vez de recursos resulte em satisfação do cliente e impacto nos negócios a curto e longo prazo.
Escopo mínimo: A metodologia Inovar ilustra como integrar estratégia e planos por meio do consenso de valor do negócio. Em seguida, o guia apresenta ferramentas nativas da nuvem que podem acelerar cada disciplina de inovação e as melhores práticas para implementação. Por fim, a seção de melhorias de processo demonstra abordagens para criar empatia com o cliente, respeitando planos e estratégias em toda a jornada de adoção da nuvem. Essa abordagem se concentra em oferecer inovação com o mínimo de tecnologia possível.
Exemplo de escopo expandido: às vezes, uma inovação depende de cargas de trabalho de missão crítica ou de alta sensibilidade. Quando o cliente é um usuário interno, o esforço de desenvolvimento pode ser de missão crítica e de alta sensibilidade 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 em nuvem é um equilíbrio entre duas prioridades concorrentes: velocidade e agilidade versus um ambiente bem governado. 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 pretendem 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 o negócio 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 de negócios, política e processo. Como participante ativo durante toda a adoção da nuvem, a equipe de governança pode implementar um conjunto mínimo de salvaguardas para abordar 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 salvaguardas para atender a novos riscos. Essa abordagem maximiza o aprendizado e a inovação, minimizando os riscos.
Exemplo de escopo expandido: quando o risco dos negócios é 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 orientações 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 pouso.
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 afasta da proposta de valor central da TI, a visão sobre o gerenciamento de operações mudou. À medida que a TI aumenta o foco na entrega de valor aos negócios, as equipes de gerenciamento de operações são confrontadas pela necessidade de equilibrar no-ops e low-ops versus 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 da nuvem.
No-ops e low-ops: use ferramentas de operações nativas da 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 para gerar valor de outras maneiras. Isoladamente, no entanto, essa abordagem pode levar a um suporte de operações abaixo do esperado.
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 no-ops 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 uma pequena porcentagem de cargas de trabalho justifica investimentos profundos em operações de TI. Para essas cargas de trabalho, a equipe de TI pode querer 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 esforço da TI para atender às demandas de negócios por velocidade e agilidade. A mesma mudança está aparecendo em alterações em organogramas ou estruturas de equipes virtuais para fornecer melhor suporte aos 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: Este 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, presume-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 atingir 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 avançar em direção a uma estrutura de centro de excelência em nuvem (CCoE) para fornecer abordagens de controle delegado.
Exemplo de escopo expandido: muitas situações desencadeiam 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 limitantes 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 criticidade e na sensibilidade de cada carga de trabalho. Fornecer ambientes com menos controle, mas um escopo ou perfil de risco reduzido, 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.