Equilibrar as prioridades concorrentes

O sucesso de qualquer transformação digital é determinado pela capacidade dos intervenientes empresariais e tecnológicos de equilibrarem as prioridades concorrentes.

Tal como outras transformações digitais, a adoção da cloud expõe prioridades concorrentes ao longo do ciclo de vida de adoção. Tal como acontece com outras formas de transformação, a capacidade de equilibrar essas prioridades tem um efeito significativo na realização do valor empresarial. Equilibrar estas prioridades concorrentes requer conversas abertas e por vezes difíceis entre os intervenientes e, por vezes, com contribuidores individuais.

Este artigo descreve algumas das prioridades concorrentes frequentemente abordadas durante a implementação de cada metodologia. Pode ajudá-lo a preparar-se para essas discussões quando desenvolver a sua estratégia de adoção da cloud.

As secções seguintes alinham-se com o fluxo no diagrama de ciclo de vida de adoção da cloud anterior. No entanto, é importante reconhecer que a adoção da cloud é um processo iterativo, não sequencial, e que estas prioridades concorrentes podem ser reemergues em vários pontos durante o percurso de adoção da cloud.

O tema geral da abordagem 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. A adoção da cloud é, muitas vezes, uma nova experiência para uma empresa e as respetivas equipas técnicas. Tal como acontece com a maioria das novas experiências, é provável que os pressupostos iniciais sejam provados como incorretos.

Seguir princípios ágeis comprovados de decisões técnicas atrasadas é a abordagem favorecida para a maioria das orientações neste quadro. Esta abordagem segue um padrão consistente: estabelecer um estado final geral, avançar rapidamente para a implementação inicial, testar e validar pressupostos e refatorizar cedo para resolver pressupostos defeituosos. Este tipo de mentalidade de crescimento maximiza a aprendizagem e minimiza o risco para o valor comercial, mas requer algum conforto com ambiguidade.

Por vezes, a ambiguidade pode ser mais assustadora, ou mais perigosa, do que falsas suposições. Embora este quadro dê prioridade à aprendizagem e resolva a ambiguidade durante a implementação, muitas situações exigem que a equipa dê prioridade a abordagens baseadas em análises ou em pressupostos. As secções seguintes fornecem pelo menos um "exemplo de âmbito 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 de Estratégia é desenvolver o alinhamento entre os intervenientes. Depois de definido, a posição estratégica alinhada impulsiona o comportamento em cada uma das metodologias para garantir que as decisões técnicas estão alinhadas com os resultados empresariais pretendidos. Promover o alinhamento entre os intervenientes cria um conjunto comum de prioridades concorrentes: profundidade da justificação versus tempo para o impacto empresarial.

Prioridades concorrentes:

• Profundidade da justificação: Muitas vezes, os intervenientes querem uma análise financeira profunda e uma justificação empresarial completa antes de se sentirem confortáveis em alinhar-se com uma direção estratégica. Infelizmente, esse nível de análise pode exigir um período de tempo prolongado para permitir a recolha e análise de dados.
• Impacto do tempo para a empresa: Por outro lado, os intervenientes são muitas vezes responsabilizados pela entrega de resultados empresariais 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 dos intervenientes no início do processo. A metodologia de estratégia sugere limitar o âmbito do alinhamento durante este esforço inicial. Na abordagem sugerida, os intervenientes focam-se em alinhar-se em torno de um conjunto de motivações fundamentais, resultados mensuráveis e uma justificação comercial de alto nível. Os intervenientes devem, em seguida, comprometer-se rapidamente com alguns projetos ou pilotos iniciais para impulsionar as oportunidades de aprendizagem necessárias.

Exemplo de âmbito expandido: Se a análise de negócio inicial indicar um alto risco de afetar negativamente o negócio, os intervenientes poderão ter de abrandar e avaliar mais cautelosamente uma análise mais aprofundada durante a justificação empresarial.

Balancear durante a fase de planeamento

Tal como durante a fase de estratégia, é necessário durante a fase de planeamento equilibrar a profundidade do planeamento inicial em comparação com as decisões técnicas atrasadas.

Prioridades concorrentes:

• A profundidade do planeamento inicial para a implementação técnica na cloud baseia-se frequentemente em muitos pressupostos. Especialmente quando existem lacunas de competências na equipa, o ambiente sofre de lacunas de deteção ou as cargas de trabalho não têm estados finais arquitetónicos claramente definidos. Todos estes pressupostos são comuns em planos detalhados de adoção da cloud. A experimentação, os pilotos e a análise qualitativa são necessários para verificar ou melhorar estes pressupostos.
• As decisões técnicas atrasadas baseiam-se no pressuposto de que, quanto mais tarde for tomada uma decisão técnica, mais precisa será. Os princípios seguintes do planeamento ágil do produto ajudam a atrasar as decisões técnicas, permitindo que ocorram no momento certo, com base em informações suficientes. No entanto, esta abordagem resulta numa maior ambiguidade no plano inicial.

Âmbito mínimo: Sugerimos abordagens ágeis de desenvolvimento de produtos para impulsionar a ação rápida dentro de planos geríveis. A metodologia Do Plano recomenda os seguintes passos para alcançar este equilíbrio:

1. Crie um inventário do património digital completo com ferramentas de deteção automatizadas, mas utilize a racionalização incremental para planear até aos próximos 1 a 3 meses de trabalho.
2. Certifique-se de que o alinhamento organizacional adequado se move rapidamente.
3. Crie um plano de preparação de competências para a equipa atribuída. Utilize a estratégia e o modelo de plano para implementar rapidamente um atraso inicial.

Exemplo de âmbito expandido: Por vezes, a entrega de um plano de adoção da cloud pode ser uma resposta a um evento empresarial sensível ao tempo ou de elevado impacto. Quando o sucesso requer a movimentação de um elevado número de recursos durante um período de tempo fixo, os passos anteriores são frequentemente seguidos por um esforço de planeamento mais profundo. A chave para o sucesso nestes cenários é planear o suficiente para começar e, mais tarde, planear o envolvimento completo. Esta abordagem reduz a probabilidade de o planeamento bloquear os resultados empresariais.

Balanceamento durante a fase de preparação

Quando as equipas se preparam para os primeiros passos para a adoção da cloud, existem muitas vezes prioridades concorrentes entre o tempo para a adoção e as operações a longo prazo. A equipa pode ter dificuldades com o equilíbrio entre ser adequada para cumprir a tarefa em questão e ser bem gerida. Esta luta é necessária em ambientes de TI tradicionais, onde o ato de desenvolver uma plataforma requer recursos 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 refatorização, reduzem a necessidade de serem bem geridas desde o início.

Prioridades concorrentes:

• Operações de longo prazo: Muitas vezes, as organizações são bloqueadas pelo desejo de ter um ambiente na cloud que cumpra a paridade de funcionalidades com a gestão de operações, governação e sistemas de segurança atuais. Num estudo, mais de 90% das organizações precisavam de apoio para ultrapassar essa mentalidade. Este bloqueador pode criar meses de atraso, abrandar ou impedir o impacto empresarial.
• Hora da adoção: Ferramentas baseadas na cloud, como Azure Policy, Azure Blueprints e grupos de gestão, podem simplificar o processo de refatorização na plataforma de TI. Além disso, as zonas de destino predefinidas fornecem recomendações para acelerar a implementação em direção a um ambiente que já cumpre muitos requisitos de paridade de funcionalidades. Estas ferramentas proporcionam oportunidades para acelerar o tempo de comercialização com um efeito mínimo nas operações a longo prazo.

Âmbito mínimo: A metodologia Ready descreve um caminho direto desde a rápida adoção até operações de longo prazo. Esta abordagem começa com uma introdução básica às ferramentas que pode utilizar para refatorizar o seu ambiente. As ferramentas têm em conta os seus requisitos e orientam-no para uma seleção de zonas de destino predefinidas, cada uma fornecida com infraestrutura como modelos de código. Em seguida, pode refatorizar o código durante a adoção da cloud para melhorar as operações, a segurança e a gestão.

Exemplo de âmbito expandido: Para as equipas cujo plano de adoção exige um objetivo de médio prazo (no prazo de 24 meses) para alojar mais de 1000 ativos (aplicações, infraestruturas ou recursos de dados) na cloud, recomendamos uma vista mais robusta das zonas de destino. Nestas situações, deve considerar as metodologias de Governação e Gestão durante as conversações iniciais da zona de destino. No entanto, esta consideração mais profunda geralmente adiciona semanas ou meses a um plano de adoção da cloud. Para minimizar o efeito nos resultados empresariais, a equipa de adoção deve pilotar cargas de trabalho reais na cloud e, ao mesmo tempo, criar uma zona de destino mais madura e uma solução de arquitetura central.

Saldo durante a fase de migração

Durante a migração, as equipas de adoção normalmente assumem que as cargas de trabalho serão realojadas na cloud na configuração atual. Esta suposição compete com um plano orientado para o futuro para rearquitetar todas as cargas de trabalho para tirar melhor partido das capacidades da cloud. As duas vistas não são mutuamente exclusivas e podem ser gratuitas quando as gere através de um processo comum.

Prioridades concorrentes:

• Realojamento: Muitas vezes, as organizações equiparam a migração a uma abordagem lift-and-shift que replica todos os recursos para a cloud na configuração atual. Esta abordagem resulta num pequeno desvio no portefólio de TI. É também a forma mais rápida de extinguir recursos num datacenter existente.
• Rearquitetar: Modernizar a arquitetura de cada carga de trabalho maximiza o valor da adoção da cloud em todos os custos, desempenho e operações. No entanto, esta abordagem é mais lenta e, muitas vezes, requer acesso ao código fonte de cada aplicação.

Âmbito mínimo: Durante o planeamento em fase inicial, utilize a opção de realojamento para planear, com uma compreensão clara de que esta escolha se baseia numa suposição de negócio inicial e não é uma decisão técnica. Na metodologia Migrar, a equipa de adoção da cloud desafia esta suposição para cada carga de trabalho migrada. Esta metodologia segue a abordagem de avaliação/migração/promoção 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 equipa de adoção avalia o ajuste técnico e a arquitetura de cada carga de trabalho. Esse esforço de avaliação raramente resulta numa abordagem lift-and-shift pura porque muitos dos componentes na arquitetura tendem a ser selecionados para refatorização e modernização.

Exemplo de âmbito expandido: Para cargas de trabalho críticas ou de elevada confidencialidade, como aplicações de microsserviços mainframe ou multicamadas, poderá ser necessária uma avaliação mais completa da carga de trabalho durante a fase de avaliação. Nestas situações de rearquitectura, deve utilizar o Azure Well-Architected Review e o Azure Well-Architected Framework para refinar os requisitos da carga de trabalho durante a avaliação.

Balanceamento durante a fase de inovação

A verdadeira inovação voltada para o cliente cria frequentemente prioridades conflituosas entre a necessidade de cumprir um conjunto de funcionalidades planeadas e implementar um processo de desenvolvimento de empatia do cliente.

Prioridades concorrentes:

• Foco da funcionalidade: Os planos iniciais de inovação baseiam-se no património digital existente e nas capacidades da cloud para fornecer um conjunto de funcionalidades que satisfazem as necessidades de um cliente. É fácil permitir que o plano impulsione a implementação técnica, o que leva a um esforço de desenvolvimento focado nas funcionalidades. Esta abordagem conduz frequentemente à satisfação temporária dos intervenientes, mas reduz a probabilidade de impulsionar a inovação que influencia o comportamento dos clientes.
• Empatia do cliente: Os planos iniciais são uma parte importante do lado empresarial do desenvolvimento e devem ser incluídos em relatórios regulares. No entanto, aprender, medir e criar com a empatia do cliente como objetivo é uma medida mais precisa de sucesso num esforço de inovação. Concentrar-se nos clientes através das funcionalidades é mais provável que resulte na satisfação dos clientes a curto e longo prazo e no impacto comercial.

Âmbito mínimo: A metodologia de Inovação ilustra como integrar a estratégia e os planos através do consenso de valor empresarial. Em seguida, o guia apresenta ferramentas nativas da cloud que podem acelerar cada disciplina de inovação e melhores práticas de implementação. Por fim, a secção de melhoramentos de processos demonstra abordagens para criar empatia dos clientes ao mesmo tempo que respeita planos e estratégias em todo o percurso de adoção da cloud. Esta abordagem centra-se na inovação com a utilização do mínimo de tecnologia possível.

Exemplo de âmbito expandido: Por vezes, uma inovação depende de cargas de trabalho críticas ou de elevada confidencialidade. Quando o cliente é um utilizador interno, o esforço de desenvolvimento pode ser crítico para a missão e alta sensibilidade durante as iterações mais antigas. Nestes cenários, as equipas de adoção devem utilizar o Azure Well-Architected Review e o Azure Well-Architected Framework para avaliar o design arquitetónico avançado no início do processo.

Balancear durante a fase de governação

A prática da governação da cloud é um equilíbrio entre duas prioridades concorrentes: velocidade e agilidade em comparação com um ambiente bem regido. A equipa de governação da cloud foca-se em avaliar e minimizar os riscos para o negócio através de controlos uniformes e minimizar as alterações. A equipa de adoção foca-se na condução dos resultados empresariais, que requerem novos riscos e criam alterações inerentemente.

Prioridades concorrentes:

• Bem regido: Todos os controlos concebidos para minimizar os riscos bloqueiam alguns aspetos das opções de conceção de alterações ou limites. O controlo é essencial para um ambiente bem regido. No entanto, quando os controlos são concebidos e implementados isoladamente, podem ser tão prejudiciais como os riscos que se destinam a prevenir.
• Velocidade e agilidade: A velocidade e a agilidade são requisitos empresariais fundamentais na economia digital. Ambos requerem a capacidade de impulsionar a mudança com bloqueadores mínimos para inovação ou adoção. Mas quando a mudança é impulsionada sem governação, gera novos riscos que podem prejudicar o negócio de formas inesperadas.

Âmbito mínimo: A metodologia de governação sugere que nem a governação nem a adopção devem acontecer isoladamente. Esta metodologia começa com uma compreensão das disciplinas de governação e uma conversa sobre risco empresarial, política e processo. Enquanto participante ativo em toda a adoção da cloud, a equipa de governação pode implementar um conjunto mínimo de salvaguardas para resolver os riscos tangíveis no âmbito do plano de adoção da cloud. Ao longo do tempo, a equipa de governação pode refatorizar e expandir essas salvaguardas para cumprir novos riscos. Esta abordagem maximiza a aprendizagem e a inovação, minimizando o risco.

Exemplo de âmbito expandido: Quando o risco empresarial é elevado, especialmente no início da adoção, a equipa de governação da cloud poderá ter de acelerar a expansão das implementações de governação. Pode utilizar a mesma documentação de orientação e exercícios para adicionar este nível de governação mais elevado, mas poderá ter de ir mais rápido. Em alguns cenários, pode ser necessário um estado avançado de governação enquanto está a desenvolver as primeiras zonas de destino.

Balancear durante a fase de gestão

O modelo de negócio de TI para a gestão de operações evoluiu continuamente ao longo da última década. À medida que a manutenção de hardware se afasta da proposta de valor principal de TI, a vista sobre a gestão de operações mudou. À medida que as TI aumentam o foco na entrega do valor empresarial, as equipas de gestão de operações estão em conflito com a necessidade de equilibrar as operações sem operações e as operações baixas em comparação com os grandes investimentos.

Prioridades concorrentes:

• Grandes investimentos: Investir igualmente na prevenção de indisponibilidade, recuperação rápida e monitorização em todo o ambiente é a abordagem tradicional à gestão de operações. Esta abordagem pode ser dispendiosa e, por vezes, duplica os produtos de suporte fornecidos pelo fornecedor da cloud.
• No-ops e low-ops: Utilize ferramentas de operações nativas da cloud para minimizar as tarefas repetitivas e periódicas que foram anteriormente entregues pelos seus funcionários. A redução destas dependências operacionais liberta os colaboradores para impulsionar o valor de outras formas. No entanto, isoladamente, esta abordagem pode levar ao suporte de operações de subpar.

Âmbito mínimo: A metodologia Gerir sugere estabelecer uma linha de base sem opções nativa da cloud. Reconhecendo que a linha de base não ops não vai satisfazer todas as necessidades empresariais, trabalhe com a empresa para definir compromissos e alinhar melhor os investimentos. Expanda a linha de base para satisfazer as necessidades comuns de todas as cargas de trabalho. Em seguida, ative equipas de plataforma ou equipas de cargas de trabalho específicas para manter soluções bem geridas num ambiente bem gerido.

Exemplo de âmbito expandido: Na maioria dos ambientes, o valor comercial de uma pequena percentagem de cargas de trabalho justifica investimentos profundos em operações de TI. Para essas cargas de trabalho, a equipa de TI poderá querer utilizar o Azure Well-Architected Review e o Azure Well-Architected Framework para orientar operações mais profundas.

Balanceamento durante a fase da organização

As prioridades concorrentes descritas neste artigo refletem o impulso das TI para cumprir as exigências empresariais de velocidade e agilidade. A mesma mudança está a aparecer nas alterações a organogramas ou estruturas de equipa virtuais para proporcionar um melhor suporte para os resultados empresariais. À medida que os líderes de TI refletem sobre as estruturas de equipa, são geralmente abordadas duas prioridades concorrentes: controlo centralizado versus controlo delegado.

Prioridades concorrentes:

• Controlo centralizado: Este modelo operacional centra-se na centralização de todos os controlos necessários para impor políticas rígidas. Neste modelo, as TI servem de bloqueador de inovação, velocidade e agilidade. No entanto, as TI podem garantir um maior grau de estabilidade, conformidade e segurança.
• Controlo delegado: Neste modelo operacional distribuído, assume-se que cada equipa do DevOps ou equipa de aplicações empresariais fornecerá o seu próprio conjunto de controlos, com base nas soluções necessárias para cumprir os objetivos empresariais. Neste modelo, as TI fornecem diretrizes para ajudar as equipas a evitar riscos, mas minimiza o número de restrições técnicas impostas sempre que possível.

Âmbito mínimo: A maioria das organizações passa por um conjunto natural de evoluções ao longo do tempo. A metodologia Organizar descreve a série de evoluções mais comum. Recomendamos que as equipas tentem avançar para uma estrutura do centro de excelência da cloud (CCoE) para fornecer abordagens de controlo delegados.

Exemplo de âmbito expandido: Muitas situações acionam a necessidade de controlo centralizado. Os requisitos de conformidade de terceiros e a exposição temporária à segurança são dois exemplos de acionadores para controlo centralizado. Nestas situações, normalmente, é necessário estabelecer políticas de limitação e controlos rígidos e fixos. No entanto, para permitir que a inovação e a adoção continuem, incentivamos as equipas de TI centrais a fornecerem esses controlos com base na importância e sensibilidade de cada carga de trabalho. Fornecer ambientes com menos controlo, mas um âmbito ou perfil de risco reduzido permite flexibilidade mesmo quando o controlo é necessário.

Passos seguintes

Saiba como equilibrar a migração, a inovação e a experimentação para maximizar o valor dos esforços de migração da cloud.

Equilibrar o portfólio