Equilibrar o portfólio
A adoção da cloud é um esforço de gestão de portefólio, habilmente disfarçado de implementação técnica. Como qualquer exercício de gestão de portefólio, o equilíbrio do portefólio é fundamental. A nível estratégico, significa equilibrar a migração, inovação e experimentação para tirar o máximo partido da cloud. Quando o esforço de adoção da cloud se inclina demasiado numa direção, a complexidade encontra o seu caminho nos esforços de adoção. Este artigo fornece orientações ao leitor sobre diferentes abordagens para atingir um equilíbrio no portefólio.
Expansão do âmbito geral
Equilibrar o portfólio é de natureza estratégica. Como tal, a abordagem neste artigo é igualmente estratégica. Para fundamentar a estratégia em decisões condicionadas por dados, este artigo pressupõe que o leitor avaliou o património digital existente ou iniciou esse processo. O objetivo desta abordagem é auxiliar na avaliação de cargas de trabalho para garantir um equilíbrio adequado no portefólio, através de perguntas qualitativas e otimização do portefólio.
Documentar resultados comerciais
Antes de equilibrar o portefólio, é importante documentar e partilhar os resultados empresariais que impulsionam o esforço de migração da cloud. A seguinte tabela pode ajudar a documentar e partilhar os resultados de negócio pretendidos. É importante ter em conta que a maioria das empresas pretende cumprir diversos objetivos em simultâneo. A importância deste exercício é esclarecer quais os resultados mais diretamente relacionados com o esforço de migração para a cloud:
| Resultado | Medido por | Objetivo | Período de tempo | Prioridade para este esforço |
|---|---|---|---|---|
| Reduzir os custos de TI | Orçamento do datacenter | Reduzir por USD de $2M | 12 meses | N.º 1 |
| Saída do datacenter | Sair dos datacenters | 2 datacenters | 6 meses | N.º 2 |
| Aumentar a agilidade do negócio | Melhorar o tempo de produção | Reduzir o tempo de implementação em seis meses | 2 anos | N.º 3 |
| Melhorar a experiência do cliente | Satisfação do cliente (CSAT) | Melhoria de 10% | 12 meses | N.º 4 |
Importante
A tabela acima é um exemplo fictício e não deve ser utilizada para definir prioridades. Em muitos casos, esta tabela pode ser considerada um antipasta ao colocar a poupança de custos acima das experiências dos clientes.
A tabela acima pode representar com precisão as prioridades da equipa de estratégia da cloud e da equipa de adoção da cloud. Devido a restrições de curto prazo, esta equipa dá maior ênfase à redução dos custos de TI, dando prioridade a uma saída do datacenter como forma de reduzir os custos de TI ao nível pretendido. No entanto, ao documentar as prioridades concorrentes nesta tabela, a equipa de adoção da cloud tem a capacidade de ajudar a equipa de estratégia da cloud a identificar oportunidades para alinhar melhor a implementação da estratégia de portefólio global.
Manter o equilíbrio num ritmo acelerado
A orientação sobre a racionalização incremental do património digital sugere uma abordagem na qual a racionalização começa numa posição de desequilíbrio. A equipa de estratégia da cloud deve avaliar cada carga de trabalho em termos de compatibilidade com uma abordagem de realojamento. Esta abordagem é sugerida porque permite a rápida avaliação de um património digital complexo, com base em dados quantitativos. Fazer essa suposição inicial permite que a equipa de adoção da cloud se envolva rapidamente,ao reduzir o tempo dos resultados de negócio. No entanto, conforme indicado nesse artigo, as perguntas qualitativas irão proporcionar o equilíbrio necessário ao portefólio. Este artigo documenta o processo de criação do equilíbrio prometido.
A importância das decisões de desativação e descontinuação
A tabela na anterior secção documentar resultados de negócio não tem um resultado importante que suportaria o objetivo principal de reduzir os custos de TI. Quando as poupanças de custos de TI figuram na lista de resultados de negócio, é importante considerar o potencial de desativar ou descontinuar cargas de trabalho. Em alguns cenários, a poupança de custos pode ser proveniente da não migração de cargas de trabalho que não justificam um investimento a curto prazo. Alguns clientes comunicaram poupanças superiores a 20% do custo total ao descontinuar cargas de trabalho subaproveitadas.
Para equilibrar o portefólio, refletindo melhor as decisões de pôr-do-sol e extinguir, a equipa de estratégia da cloud e a equipa de adoção da cloud são incentivadas a fazer as seguintes perguntas sobre cada carga de trabalho durante as fases de avaliação e migração:
- A carga de trabalho foi utilizada pelos utilizadores finais nos últimos seis meses?
- O tráfego de utilizadores finais é consistente ou está a crescer?
- A empresa irá precisar desta carga de trabalho daqui a 12 meses?
Se a resposta a qualquer uma destas perguntas for "não", a carga de trabalho poderá ser candidata à descontinuação. Se o potencial de descontinuação for confirmado com o proprietário da aplicação, poderá não fazer sentido migrar a carga de trabalho. Isto gera algumas perguntas de qualificação:
- É possível estabelecer um plano de descontinuação ou desativação para esta carga de trabalho?
- Esta carga de trabalho pode ser descontinuada antes da saída do datacenter?
Se a resposta a ambas as perguntas for "sim", seria aconselhável considerar não migrar a carga de trabalho. Esta abordagem ajudaria a cumprir os objetivos de reduzir custos e sair do datacenter.
Se a resposta a qualquer uma das perguntas for "não", poderá ser aconselhável estabelecer um plano para alojar a carga de trabalho até poder ser descontinuada. Este plano pode incluir a mudança dos recursos para um datacenter de menor custo ou um datacenter alternativo, o que também atingiria os objetivos de redução de custos e a saída de um datacenter.
Adotar alterações ao processo
O balanceamento do portefólio requer uma análise qualitativa adicional durante a fase Adotar, o que ajudará a impulsionar a racionalização simples do portefólio.
Com base nos dados da tabela na secção documentar resultados de negócio acima, existe um risco provável de o portefólio se desviar demasiado para um modelo de execução focado na migração. Se a experiência dos clientes era a prioridade, será mais provável ter um portefólio inovador. Nenhuma das abordagens está certa ou errada, mas desviar-se muito numa direção costuma gerar uma redução de receita, acrescentar complexidade desnecessária e aumentar o tempo de execução relacionado com os trabalhos de adoção da cloud.
Para reduzir a complexidade, deve seguir uma abordagem tradicional à racionalização do portefólio, mas num modelo iterativo. Os seguintes passos descrevem um modelo qualitativo para essa abordagem:
- A equipa de estratégia da cloud mantém um registo de tarefas pendentes priorizado, com as cargas de trabalho a serem migradas.
- A equipa de estratégia da cloud e a equipa de adoção da cloud alojam uma reunião de planeamento de lançamento antes da conclusão de cada versão.
- Na reunião de planeamento de lançamento, as equipas concordam com 5 a 10 cargas de trabalho no registo de tarefas pendentes com prioridade.
- Fora da reunião de planeamento de lançamento, a equipa de adoção da cloud faz as seguintes perguntas aos proprietários de aplicações e especialistas na matéria:
- Esta aplicação pode ser substituída por um equivalente de plataforma como serviço (PaaS)?
- Esta aplicação é uma aplicação de terceiros?
- Foi aprovado orçamento para investir num desenvolvimento contínuo da aplicação nos próximos 12 meses?
- O desenvolvimento adicional da aplicação melhoraria a experiência do cliente? Criaria um diferencial competitivo? Aumentaria a receita da empresa?
- Os dados nesta carga de trabalho contribuirão para uma inovação a jusante relacionada com BI, machine learning, IoT ou tecnologias relacionadas?
- A carga de trabalho é compatível com plataformas de aplicações modernas, como o Serviço de Aplicações do Azure?
- As respostas às perguntas acima e qualquer outra análise qualitativa necessária terão influência nos ajustes ao registo de tarefas pendentes com prioridade. Estes ajustes poderão incluir:
- Se uma carga de trabalho puder ser substituída por uma solução PaaS, poderá ser totalmente removida do registo de tarefas pendentes de migração. No mínimo, as diligências adicionais para decidir entre realojar e substituir seriam adicionadas como uma tarefa, reduzindo temporariamente a prioridade dessa carga de trabalho do registo de tarefas pendentes de migração.
- Se uma carga de trabalho estiver (ou deve estar) a ser submetida a um avanço de desenvolvimento, poderá ajustar-se melhor a um modelo de refatorização-rearquitect-rebuild. Uma vez que a inovação e a migração requerem competências técnicas diferentes, as aplicações alinhadas com uma abordagem de refatorização-rearquitect-rebuild devem ser geridas através de um registo de tarefas pendentes de inovação em vez de um registo de tarefas pendentes de migração.
- Se uma carga de trabalho estiver numa inovação a jusante, poderá ser pertinente refatorizar a plataforma de dados, mas deixar as camadas de aplicação como candidato para realojamento. Uma refatorização menor da plataforma de dados da carga de trabalho pode normalmente ser resolvida num registo de tarefas pendentes de migração ou inovação. Este resultado de racionalização pode originar itens de trabalho mais detalhados no registo de tarefas pendentes, mas não há outras mudanças em termos de prioridades.
- Se uma carga de trabalho não for estratégica, mas for compatível com plataformas modernas de alojamento de aplicações baseadas na cloud, poderá ser aconselhável realizar uma refatorização secundária na aplicação para implementá-la como uma aplicação moderna. Isto poderá contribuir para uma poupança global ao reduzir os requisitos gerais de IaaS e licenciamento de SO da migração para a cloud.
- Se uma carga de trabalho for uma aplicação de terceiros e os dados dessa carga de trabalho não estiverem planeados para utilização numa inovação a jusante, poderá ser melhor deixá-la como uma opção de realojamento no registo de tarefas pendentes.
Estas perguntas não devem ser a extensão da análise qualitativa concluída para cada carga de trabalho, mas ajudam a orientar uma conversa sobre como abordar a complexidade de um portefólio desequilibrado.
Alterações ao processo de migração
Durante a migração, as atividades de balanceamento de portefólio podem ter um impacto negativo na velocidade da migração (a velocidade a que os recursos são migrados). As seguintes orientações explicarão mais detalhadamente porquê e como alinhar o trabalho para evitar interrupções no esforço de migração.
A racionalização do portefólio requer diversidade de esforços técnicos. É tentador para as equipas de adoção da cloud refletirem a diversidade de portefólio nos esforços de migração. Os intervenientes da empresa pedem que uma única equipa de adoção da cloud resolva todo o registo de tarefas pendentes de migração. Esta abordagem raramente é aconselhável e, em muitos casos, pode ser contraproducente.
Estes esforços diversos devem ser segmentados em duas ou mais equipas de adoção da cloud. Ao utilizar um modelo de duas equipas como um modo de execução de exemplo, a equipa 1 é a equipa de migração e a equipa 2 é a equipa de inovação. Para maiores esforços, estas equipas podem ser segmentadas para abordar outras abordagens, como os esforços de substituição/PaaS ou a refatorização secundária. O seguinte descreve as competências e funções necessárias para realojar, refatorizar ou refatorizar:
Realojamento: O Realojamento requer que os membros da equipa implementem alterações focadas na infraestrutura. Geralmente, utiliza-se uma ferramenta como o Azure Site Recovery para migrar VMs ou outros recursos para o Azure. Este trabalho é adequado para administradores de datacenter ou implementadores de TI. A equipa da migração para a cloud está bem estruturada para levar a cabo este trabalho em larga escala. Esta é a abordagem mais rápida para migrar recursos existentes na maioria dos cenários.
Refatorização: A refatorização requer que os membros da equipa modifiquem o código fonte, alterem a arquitetura de uma aplicação ou adotem novos serviços cloud. Geralmente, este esforço implica ferramentas de desenvolvimento como o Visual Studio e ferramentas de pipeline de implementação como o Azure DevOps, para reimplementar aplicações modernas para o Azure. Este trabalho é adequado para funções de desenvolvimento de aplicações ou funções de desenvolvimento de pipeline do DevOps. A equipa de inovação da cloud está melhor estruturada para realizar este trabalho. Pode demorar mais tempo a substituir os recursos existentes por recursos da cloud nesta abordagem, mas as aplicações podem tirar partido das funcionalidades nativas da cloud.
Refatorização secundária: Algumas aplicações podem ser modernizadas com refatorização secundária ao nível dos dados ou da aplicação. Este trabalho exige que os membros da equipa implementem dados em plataformas de dados baseadas na cloud ou façam pequenas alterações de configuração na aplicação. Isto pode exigir suporte limitado a especialistas na matéria em desenvolvimento de aplicações ou dados. No entanto, este trabalho é semelhante ao trabalho realizado pelos implementadores de TI ao implementar aplicações de terceiros. Este trabalho pode facilmente ser adequado para a equipa de migração da cloud ou a equipa de estratégia da cloud. Apesar de este esforço não ser tão rápido como uma migração de realojamento, demora menos tempo a executar do que os esforços de refatorização.
Durante a migração, os esforços devem ser segmentados das três formas listadas acima e executadas pela equipa adequada na iteração adequada. Embora deva diversificar o portfólio, certifique-se também de que os esforços se mantêm muito focados e segregados.
Passos seguintes
Compreenda como as decisões globais do mercado podem afetar o seu percurso de transformação.