Equilibrar o portfólio

A adoção da nuvem é um esforço de gerenciamento de portfólio, inteligentemente disfarçado de implementação técnica. Como qualquer exercício de gerenciamento de portfólio, o balanceamento do portfólio é crítico. Em um nível estratégico, isso significa balancear a migração, a inovação e a experimentação para aproveitar a nuvem ao máximo. Quando a tentativa de adoção da nuvem se inclina demais em uma direção, a complexidade encontra seu caminho no esforço de adoção. Este artigo orientará o leitor pelas abordagens para alcançar o equilíbrio no portfólio.

Expansão do escopo geral

O balanceamento do portfólio é estratégico por natureza. Como tal, a abordagem adotada neste artigo é igualmente estratégica. Para fundamentar a estratégia em decisões baseadas em dados, este artigo pressupõe que o leitor tenha avaliado o acervo digital existente ou iniciou esse processo. O objetivo dessa abordagem é auxiliar na avaliação das cargas de trabalho para garantir o equilíbrio adequado em todo o portfólio através de perguntas qualitativas e refinamento do portfólio.

Documentar os resultados empresariais

Antes de balancear o portfólio, é importante documentar e compartilhar os resultados de negócios que levam ao esforço de migração na nuvem. A tabela a seguir pode ajudar a documentar e compartilhar os resultados empresariais desejados. É importante notar que a maioria das empresas tem buscando vários resultados de cada vez. A importância deste exercício é esclarecer os resultados que estão mais diretamente relacionados ao esforço de migração na nuvem:

A tabela acima poderia representar com precisão as prioridades da equipe de estratégia da nuvem e da equipe de adoção da nuvem. Devido a restrições de curto prazo, essa equipe tem dado maior ênfase à redução de custos de TI e priorizado a saída de um datacenter como uma forma de atingir as reduções de custos de TI desejadas. No entanto, ao documentar as prioridades concorrentes nesta tabela, a equipe de adoção da nuvem tem o poder de ajudar a equipe de estratégia da nuvem a identificar oportunidades para alinhar melhor a implementação da estratégia do portfólio abrangente.

Mova-se rapidamente mantendo o equilíbrio

A orientação referente à racionalização incremental do acervo digital sugere uma abordagem na qual a racionalização começa com uma posição desequilibrada. A equipe de estratégia da nuvem deve avaliar cada carga de trabalho para verificar a compatibilidade com uma abordagem de nova hospedagem. Essa abordagem é sugerida porque permite a rápida avaliação de um acervo digital complexo com base em dados quantitativos. Fazer essa pressuposição inicial permite que a equipe de adoção da nuvem se envolva rapidamente e reduza o tempo de obtenção dos resultados dos negócios. No entanto, conforme indicado nesse artigo, as perguntas qualitativas fornecerão o equilíbrio necessário no portfólio. Este artigo documenta o processo de criação do equilíbrio prometido.

A importância das decisões de aposentadoria e caducidade

A tabela na seção de documentação dos resultados empresariais acima, deixa de fora um importante resultado que daria suporte ao primeiro objetivo de redução dos custos de TI. Quando as reduções de custos de TI ocupam um lugar na lista de resultados empresariais, é importante considerar o potencial da caducidade ou aposentadoria das cargas de trabalho. Em alguns cenários, a economia de custos pode vir da não migração de cargas de trabalho que não garantem um investimento de curto prazo. Alguns clientes relataram economias de custo que ultrapassaram os 20% das reduções totais de custos quando retiraram cargas de trabalho subutilizadas.

Para equilibrar o portfólio, refletindo melhor sobre as decisões de caducidade e desativação, a equipe de estratégia da nuvem e a equipe de adoção da nuvem serão incentivadas a fazer as seguintes perguntas a cada carga de trabalho durante as fases de avaliação e migração:

• A carga de trabalho foi usada pelos usuários finais nos últimos seis meses?
• O tráfego do usuário final mantém-se consistente ou tem crescido?
• Esta carga de trabalho será exigida pela empresa daqui a 12 meses?

Se a resposta a qualquer uma dessas perguntas for "não", a carga de trabalho poderá ser uma candidata à aposentadoria. Se o potencial de aposentadoria for confirmado pelo proprietário do aplicativo, talvez não faça sentido migrar a carga de trabalho. Isso exige algumas questões de qualificação:

• É possível estabelecer um plano de aposentadoria ou caducidade para essa carga de trabalho?
• Essa carga de trabalho pode ser desativada antes da saída do datacenter?

Se a resposta para essas duas perguntas for "sim", seria prudente considerar não migrar a carga de trabalho. Essa abordagem ajudaria a atingir os objetivos de redução de custos e saída do datacenter.

Se a resposta a qualquer das perguntas for "não", pode ser sensato estabelecer um plano para hospedar a carga de trabalho até que ela possa seja desativada. Esse plano poderia incluir a transferência dos ativos para um datacenter de custo mais reduzido ou um datacenter alternativo, o que também atingiria os objetivos de redução de custos e saída do datacenter.

Adote alterações no processo

Equilibrar o portfólio exige uma análise qualitativa adicional durante a fase de adoção e isso ajudará a direcionar a racionalização simples do portfólio.

Com base nos dados da tabela da seção documentação dos resultados empresariais acima, há um risco provável do portfólio estar muito inclinado para um modelo de execução focado na migração. Se a experiência do cliente fosse a prioridade máxima, um portfólio pesado de inovação seria o mais provável. Nenhum modelo está certo nem errado, mas pender muito em uma direção geralmente leva a resultados decrescentes, adiciona complexidade desnecessária e aumenta o tempo de execução relacionado aos esforços de adoção da nuvem.

Para reduzir a complexidade, você deve seguir uma abordagem tradicional de racionalização de portfólio, mas em um modelo iterativo. As etapas a seguir descrevem um modelo qualitativo para essa abordagem:

• A equipe de estratégia da nuvem mantém uma lista de pendências priorizada das cargas de trabalho que serão migradas.
• A equipe de estratégia da nuvem e a equipe de adoção da nuvem organizam uma reunião de planejamento de versão antes da conclusão de cada versão.
• Na reunião de planejamento do lançamento, as equipes concordam com as 5 a 10 cargas de trabalho mais importantes da lista de pendências priorizada.
• Fora da reunião de planejamento do lançamento, a equipe de adoção da nuvem faz as seguintes perguntas aos proprietários de aplicativos e especialistas no assunto:
  • Este aplicativo poderia ser substituído por um aplicativo equivalente de plataforma como serviço (PaaS)?
  • Este aplicativo é um aplicativo de terceiros?
  • O orçamento foi aprovado para investimento no desenvolvimento contínuo do aplicativo nos próximos 12 meses?
  • Um maior desenvolvimento desse aplicativo melhoraria a experiência do cliente? Criaria um diferencial competitivo? Impulsionaria uma maior geração de receita para os negócios?
  • Os dados dentro dessa carga de trabalho contribuirão para uma inovação downstream relacionada ao BI, machine learning, IoT ou tecnologias relacionadas?
  • A carga de trabalho é compatível com plataformas de aplicativos modernas, como o Serviço de Aplicativo do Azure?
• As respostas às perguntas acima e qualquer outra análise qualitativa necessária influenciariam os ajustes da lista de pendências priorizada. Esses ajustes podem incluir:
  • Se uma carga de trabalho puder ser substituída por uma solução PaaS, ela poderá ser totalmente removida da lista de pendências da migração. No mínimo, a devida diligência adicional para decidir entre nova hospedagem e substituição seria adicionada como uma tarefa reduzindo temporariamente a prioridade dessa carga de trabalho na lista de pendências da migração.
  • Se uma carga de trabalho estiver (ou deveria estar) passando por um avanço de desenvolvimento, ela poderá se encaixar melhor em um modelo de refatoração-rearquitetura-recompilação. Como a inovação e a migração exigem habilidades técnicas diferentes, os aplicativos que condizentes com uma abordagem de refatoração-rearquitetura-recompilação, devem ser gerenciados por uma lista de pendências de inovação em vez de uma lista de pendências de migração.
  • Se uma carga de trabalho fizer parte de uma inovação downstream, talvez faça sentido refatorar a plataforma de dados, mas deixar as camadas do aplicativo disponíveis para nova hospedagem. A refatoração secundária da plataforma de dados de uma carga de trabalho geralmente pode ser tratada em uma lista de pendências de migração ou inovação. Esse resultado de racionalização pode resultar em itens de trabalho mais detalhados na lista de pendências, mas, por outro lado, sem alterações nas prioridades.
  • Se uma carga de trabalho não for estratégica, mas for compatível com plataformas de hospedagem de aplicativos modernas baseadas em nuvem, talvez seja prudente realizar pequenas refatorações no aplicativo para implantá-las como um aplicativo moderno. Isso pode contribuir para a economia geral reduzindo os requisitos gerais de licenciamento de IaaS e sistema operacional da migração na nuvem.
  • Se uma carga de trabalho for de terceiros e os dados da carga de trabalho não forem planejados para uso em uma inovação downstream, talvez seja melhor deixar como uma opção de nova hospedagem na lista de pendências.

Essas perguntas não devem ser o âmbito da análise qualitativa concluída para cada carga de trabalho, mas ajudam a orientar uma conversa sobre como abordar a complexidade de um portfólio desequilibrado.

Mudanças no processo de migração

Durante a migração, as atividades de equilíbrio do portfólio podem ter um impacto negativo na velocidade de migração (a rapidez na qual os ativos são migrados). A orientação a seguir falará mais sobre os motivos e como alinhar o trabalho para evitar interrupções no esforço de migração.

A racionalização do portfólio exige diversidade do esforço técnico. A ideia que as equipes de adoção da nuvem correspondam à diversidade do portfólio nos esforços de migração é tentadora. Os stakeholders de negócios solicitam uma única equipe de adoção da nuvem para abordar toda a lista de pendências de migração. Isso raramente é uma abordagem recomendável e, em muitos casos, pode ser contraproducente.

Esses esforços diversos devem ser segmentados em duas ou mais equipes de adoção da nuvem. Usando um modelo de duas equipes como um modo de execução de exemplo, a equipe 1 é a equipe de migração e a equipe 2 é a equipe de inovação. Para esforços maiores, essas equipes poderiam ser mais segmentadas para tratar de outras abordagens, como esforços de substituição/PaaS ou refatoração secundária. A seguir descrevemos as habilidades e funções necessárias para nova hospedagem, refatoração ou refatoração secundária:

Nova hospedagem: a nova hospedagem exige que os membros da equipe implementem alterações focadas na infraestrutura. Geralmente usando uma ferramenta como o Azure Site Recovery para migrar VMs ou outros ativos para o Azure. Este trabalho se alinha bem com os administradores do datacenter ou implementadores de TI. A equipe de migração na nuvem está bem estruturada para fornecer esse trabalho em alta escala. Essa é a abordagem mais rápida para migrar ativos existentes na maioria dos cenários.

Refatoração: a refatoração exige que os membros da equipe modifiquem o código-fonte, alterem a arquitetura de um aplicativo ou adotem novos serviços de nuvem. Geralmente, esse esforço usaria ferramentas de desenvolvimento como o Visual Studio e ferramentas de pipeline de implantação como o Azure DevOps para reimplantar aplicativos modernizados no Azure. Esse trabalho se alinha bem com as funções de desenvolvimento de aplicativos ou funções de desenvolvimento de pipeline do DevOps. A equipe de inovação na nuvem está bem estruturada para fornecer esse trabalho. Nessa abordagem, pode até levar mais tempo para substituir os ativos existentes pelos recursos da nuvem, mas os aplicativos podem aproveitar os recursos nativos da nuvem.

Refatoração secundária: alguns aplicativos podem ser modernizados com pequenas refatorações no nível dos dados ou aplicativos. Esse trabalho exige que os membros da equipe implantem dados em plataformas de dados baseadas em nuvem ou façam alterações de configuração secundárias no aplicativo. Isso pode exigir suporte limitado para especialistas no assunto de desenvolvimento de aplicativos ou de dados. No entanto, esse trabalho é semelhante ao trabalho realizado por implementadores de TI durante a implantação de aplicativos de terceiros. Esse trabalho pode ser facilmente alinhado com a equipe de migração na nuvem ou a equipe de estratégia da nuvem. Embora esse esforço não seja tão rápido quanto uma migração de nova hospedagem, leva menos tempo para ser executado do que os esforços de refatoração.

Durante a migração, os esforços devem ser segmentados das três maneiras listadas acima e executados pela equipe apropriada na iteração apropriada. Embora você deva diversificar o portfólio, também garanta que os esforços permaneçam muito focados e separados.

Próximas etapas

Entenda como as decisões globais de mercado podem afetar seu percurso de transformação.