Equilibrar as prioridades concorrentes

O sucesso de qualquer transformação digital é determinado pela capacidade das partes interessadas do negócio e da tecnologia de equilibrar prioridades concorrentes.

Como outras transformações digitais, a adoção da nuvem expõe prioridades concorrentes ao longo do ciclo de vida da adoção. E, tal 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 estas prioridades concorrentes requer conversas abertas e, por vezes, difíceis entre as partes interessadas e, por vezes, com contribuidores individuais.

Este artigo descreve algumas das prioridades concorrentes normalmente 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 de 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

As soluções monolíticas e o planeamento avançado baseiam-se numa série de pressupostos que podem revelar-se imprecisos ao longo do tempo. Adotar a nuvem é muitas vezes uma nova experiência para uma empresa e suas equipes técnicas. Tal como acontece com a maioria das novas experiências, há alguma probabilidade de que as suposições iniciais se provem incorretas.

Seguir princípios ágeis comprovados de decisões técnicas atrasadas é a abordagem preferida para a maioria das orientações dentro dessa estrutura. Essa abordagem segue um padrão consistente: estabeleça um estado final geral, passe rapidamente para a implementação inicial, teste e valide suposições e refatore antecipadamente para resolver suposições incorretas. Este tipo de mentalidade de crescimento maximiza a aprendizagem e minimiza o risco para o valor do negócio, mas requer algum conforto com 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 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 impulsiona 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 justificação versus tempo para o impacto nos negócios.

Prioridades concorrentes:

• Profundidade da justificação: as partes interessadas geralmente querem uma análise financeira profunda e uma justificação 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 alargado para permitir a recolha e análise de dados.

• Tempo para o impacto nos negócios: Por outro lado, as partes interessadas são frequentemente responsabilizadas pela entrega de 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.

Âmbito mínimo: Encontrar o equilíbrio correto requer discussões com as partes interessadas no início do processo. A metodologia da estratégia sugere limitar o âmbito do alinhamento durante este esforço inicial. Na abordagem sugerida, as partes interessadas se concentram no alinhamento em torno de um conjunto de motivações centrais, 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 inicial do negócio indicar um alto risco de afetar negativamente o negócio, as partes interessadas podem precisar desacelerar e avaliar com mais cautela uma análise mais profunda durante a justificação do negócio.

Equilíbrio durante a fase de planeamento

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 concorrentes:

• A profundidade do planejamento inicial para a 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 arquitetônicos claramente definidos. Todas essas suposições são comuns em planos detalhados de adoção de nuvem. Experimentação, pilotos e análise qualitativa são necessários para verificar ou melhorar essas suposições.

• As decisões técnicas atrasadas 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, esta abordagem resulta numa maior ambiguidade no plano inicial.

Escopo mínimo: Sugerimos abordagens ágeis de desenvolvimento de produtos para impulsionar ações rápidas dentro de planos gerenciáveis. A metodologia do Plano recomenda as seguintes etapas para alcançar esse equilíbrio:

1. Faça o inventário de todo o patrimônio digital usando ferramentas de descoberta automatizadas, mas use a racionalização incremental para planejar até os próximos 1 a 3 meses de trabalho.
2. Garanta o alinhamento organizacional adequado para se mover rapidamente.
3. Crie um plano de prontidão de habilidades para a equipe atribuída. Use o modelo de 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 grande número de ativos durante um período de tempo 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, mais tarde, 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 prontidão

Quando as equipes estão se preparando para seus primeiros passos na adoção da nuvem, muitas vezes há prioridades concorrentes entre o tempo até a adoção e as operações de longo prazo. A equipa pode ter dificuldades em encontrar o equilíbrio entre estar bem preparada para cumprir a tarefa em questão e ser bem gerida. Essa luta é necessária em ambientes tradicionais de TI, onde 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 de desenvolvimento tradicionais, como a refatoração, reduzem a necessidade de ser bem gerenciado desde o início.

Prioridades concorrentes:

• Operações de longo prazo: as organizações são frequentemente 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. Este bloqueador pode criar meses de atraso, abrandando ou prevenindo o impacto nos negócios.

• Tempo para a adoção: ferramentas baseadas na nuvem, como a Política do Azure, abordagens de integração contínua e 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 um ambiente que já atende a muitos requisitos de paridade de recursos. Essas ferramentas oferecem oportunidades para acelerar o tempo de entrada no mercado com efeito mínimo nas operações de longo prazo.

Escopo mínimo: A metodologia Ready traça um caminho direto desde a adoção rápida até as 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 suas necessidades 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 destino. No entanto, essa consideração mais profunda geralmente adiciona semanas ou meses a um plano de adoção da 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.

Saldo 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 prospetivo para rearquitetar cada carga de trabalho para aproveitar melhor os recursos da nuvem. As duas visualizações não são mutuamente exclusivas e podem ser complementares quando você as gerencia usando um processo comum.

Prioridades concorrentes:

• Rehost: as organizações geralmente igualam a migração a uma abordagem de elevação e mudança 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.

• Rearquiteto: 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 muitas vezes 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 inicial de negócios e não é uma decisão técnica. Na metodologia Migrar, a equipe de adoção de nuvem desafia essa suposição para cada carga de trabalho migrada. Esta 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 de elevação e deslocamento pura, porque 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 concorrentes:

• Foco em recursos: os planos iniciais de inovação se baseiam nos recursos digitais e de nuvem existentes para oferecer um conjunto de recursos que atendam às necessidades 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 das partes interessadas, mas reduz a probabilidade de impulsionar a inovação que influencia o comportamento do cliente.

• Empatia com o 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 um objetivo é uma medida mais precisa do sucesso em um esforço de inovação. É mais provável que o foco nos clientes em detrimento dos recursos resulte em satisfação do cliente e impacto nos negócios a curto e longo prazo.

Âmbito mínimo: A metodologia Innovate ilustra como integrar estratégia e planos através do consenso de valor de negócio. Em seguida, o guia apresenta ferramentas nativas da nuvem que podem acelerar cada disciplina de inovação e melhores práticas para implementação. Por fim, a seção de melhorias de processos demonstra abordagens para criar empatia com o cliente, respeitando planos e estratégias em toda a jornada de adoção da nuvem. Esta abordagem centra-se na inovação com a utilização do mínimo de tecnologia possível.

Exemplo de escopo expandido: uma inovação às vezes 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 governação

A prática de 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 o negócio por meio de controles uniformes e minimização de mudanças. A equipe de adoção se concentra em impulsionar os resultados de negócios, que exigem novos riscos e inerentemente criam mudanças.

Prioridades concorrentes:

• Bem governado: Todo controle projetado para minimizar o risco bloqueia algum aspeto da mudança ou limita as opções de projeto. O controle é essencial para um ambiente bem governado. 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 a mudança com o mínimo de bloqueadores à inovação ou à adoção. Mas quando a mudança é impulsionada sem governança, gera novos riscos que podem prejudicar o negócio de maneiras inesperadas.

Âmbito mínimo: A metodologia Govern sugere que nem a governação nem a adoção devem acontecer 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 durante a adoção da nuvem, a equipe de governança pode implementar um conjunto mínimo de salvaguardas 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 salvaguardas para atender a novos riscos. Esta abordagem maximiza a aprendizagem e a inovação, ao mesmo tempo que minimiza os riscos.

Exemplo de escopo expandido: quando o risco de 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 gestão

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 comercial, as equipes de gerenciamento de operações entram em conflito com a necessidade de equilibrar no-ops e low-ops versus investimentos amplos.

Prioridades concorrentes:

• Investimentos amplos: investir igualmente na prevenção de interrupções, 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 da nuvem para minimizar tarefas repetitivas e recorrentes que foram anteriormente entregues por seus funcionários. A redução dessas dependências operacionais libera os funcionários para gerar valor de outras maneiras. No entanto, isoladamente, esta abordagem pode conduzir a um apoio a operações inferiores.

Escopo mínimo: A metodologia Manage sugere o estabelecimento de uma linha de base nativa da nuvem e sem operações. Reconhecendo que a linha de base no-ops não atenderá a todas as necessidades do negócio, 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, permita que equipes de plataforma ou equipes de carga de trabalho específicas mantenham 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 de 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 mudanças em organogramas ou estruturas de equipes virtuais para fornecer um melhor suporte aos resultados de negócios. À medida que os líderes de TI refletem sobre as estruturas da equipe, duas prioridades concorrentes são comumente abordadas: controle centralizado versus controle delegado.

Prioridades concorrentes:

• Controle centralizado: Este modelo operacional se concentra na centralização de todos os controles necessários para aplicar políticas rígidas. Neste modelo, a TI serve como um bloqueador para a inovação, velocidade e agilidade. No entanto, a TI pode garantir um maior grau de estabilidade, conformidade e segurança.

• Controle delegado: neste 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 atingir os objetivos de negócios. Neste 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 Organize descreve a série mais comum de evoluções. Recomendamos que as equipes tentem avançar para 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 à 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 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óximos passos

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

Equilibrar o portfólio