Criando um Plano de Implementação em Fases

Para identificar grupos de aplicativos que podem ser clusterizados na mesma fase de adoção, crie um gráfico de quatro quadrantes que represente a preparação para a nuvem em relação ao valor comercial para cada um de seus aplicativos.

Veja um exemplo de gráfico:

A Preparação para a nuvem captura o quanto você está preparado para mover um aplicativo para a nuvem. Por exemplo:

• Custo

• Risco

• Alteração

• Restrições técnicas

Aplicativos com maior preparação para a nuvem são aplicativos que podem mais facilmente ter a plataforma reformulada ou ser re-hospedados ou que não dependem de outros aplicativos de baixa preparação. Os aplicativos com menor preparação para a nuvem podem exigir mais refatoração ou ter dependências significativas de outros aplicativos que devem ser regravados para que possam ser migrados.

O valor comercial captura metas. Por exemplo:

• Automação

• Agilidade

• Inovação

• Continuidade dos negócios

O valor comercial ajuda a categorizar o papel que um aplicativo desempenha em seu negócio ou a prioridade estratégica associada à mudança de um aplicativo para a nuvem. O valor comercial de um aplicativo é independente de sua arquitetura.

Coloque cada aplicativo em um quadrante no gráfico. Para determinar a posição apropriada, use a análise de atributo que você executou anteriormente para arquiteturas existentes e arquiteturas futuras possíveis. Os aplicativos que você planeja migrar na mesma fase devem estar relativamente bem clusterizados. Se você estiver priorizando a preparação para a nuvem, os aplicativos em uma fase poderão abranger o espectro do valor. Da mesma forma, se você estiver focando no valor comercial primeiro, os aplicativos poderão abranger o espectro da preparação. No entanto, se uma fase abranger mais de dois quadrantes, recomendamos que você reavalie o risco e o escopo das alterações, especialmente no contexto de adoção da nuvem. Uma exceção é quando você avalia vários projetos paralelos e relativamente independentes; nesse caso, você deve observar o gráfico de cada projeto separadamente.

Se você tiver muitos aplicativos legados críticos e quiser migrar para a nuvem sem o pré-requisito demorado de regravar esses aplicativos, um bom ponto de partida será os aplicativos no canto superior esquerdo - menor preparação por causa de restrições legadas, mas maior valor comercial. Se sua organização for avessa a riscos, um ponto de partida alternativo poderá ser os aplicativos no quadrante inferior direito - maior preparação, menor valor - porque estão prontos para serem migrados para a nuvem e uma possível falha teria um impacto menor na organização. Se sua organização quiser focar em um projeto piloto inicial ou precisar de uma chance de conhecer melhor a plataforma, um dos quadrantes de alta preparação será um bom ponto de partida.

Para uma grande empresa, você pode ter aplicativos relativamente independentes e optar por adotar diferentes abordagens paralelas para a adoção da nuvem em diferentes linhas de negócios.

A criação de um plano de implementação da nuvem é um processo repetitivo. Agrupe seus aplicativos em fases, mapeie-os para suas prioridades de negócios, planeje fases para adoção e, em seguida, repita-as com as partes interessadas do negócio, confirmando datas, escopo ou sequenciamento, conforme a necessidade.

Comece identificando os grupos de aplicativos que devem ser tratados juntos. Em seguida, examine as implicações de diferentes decisões de sequenciamento. As prioridades e restrições de negócios da sua organização devem informar essa análise. Muitas vezes, os seguintes atributos desempenham o papel mais forte no agrupamento de aplicativos e nas fases do planejamento de adoção:

• Gravidade de dados: Existem grupos de aplicativos que não podem ser divididos entre nuvem e on-premises e que devem ser resolvidos juntos? Inclua cenários nos quais alguns aplicativos são retirados e outros são re-hospedados.

• Escopo de alterações: Para facilitar o gerenciamento de alterações, talvez você precise dividir grupos maiores de aplicativos em grupos menores. O gerenciamento de alterações é tanto sobre pessoas e habilidades quanto sobre o número de componentes de tecnologia. A re-hospedagem de um grupo grande de aplicativos pode ter um escopo de alteração menor do que a refatoração e reformulação de plataforma de um grupo menor de aplicativos.

• Tolerância a riscos: Como as incertezas e os riscos no projeto são amplificados ou prejudicados pelo papel que os aplicativos desempenham em seus processos de missão crítica?

• Eventos atraentes: Existem direcionadores de tecnologia de fim de vida, como suporte a software ou atualizações de hardware, ou encerramentos de bens imóveis e edifícios, que motivam uma decisão específica?

Quando você analisou sua arquitetura atual e sua arquitetura planejada, avaliou muitos atributos. Ao planejar fases de adoção, use também uma view agregada ou de alto nível. Os atributos listados anteriormente - gravidade de dados, escopo de alteração, tolerância a riscos e eventos atraentes - são um bom lugar para iniciar uma visão de alto nível. Dependendo das suas necessidades de negócios, você poderá identificar outros atributos mais importantes para agrupar aplicativos em fases e validar o seu plano.

Em seu plano, mostre como cada fase se alinha com suas metas comerciais, como criar sistemas mais resilientes, permitir novo desenvolvimento ou atender a algum evento atraente. Quando você não conseguir atingir uma fase de adoção na ordem preferencial de sua organização, documente os motivos pelos quais uma determinada fase recebeu prioridade em relação a outra.

Para validar sua estratégia, faça referência cruzada do gráfico de preparação para a nuvem, da matriz de função estratégica, da view de atributo agregado e de outras perspectivas de arquitetura com base nos atributos coletados.

O gerenciamento do escopo é essencial para fazer progresso. Repita em pequenas partes ou até mesmo subconjuntos de aplicativos. Quando apropriado, divida fluxos paralelos entre linhas de negócios. Se sua organização puder aceitar ambiguidades, não confirme todos os detalhes das fases futuras; em vez disso, identifique os principais pontos de decisão futuros e destaque-os como riscos desconhecidos ou tente identificar quando será possível tomar essas decisões. Por exemplo, sua organização escolherá uma estratégia multinuvem ou você poderá manter um modelo híbrido limitado por causa dos requisitos de residência de dados ou dos requisitos on-premises?

Além disso, é imprescindível estabelecer a expectativa de linha de base de que o planejamento da adoção da nuvem não seja uma atividade única, mas sim uma que você repita conforme aprende. A alteração dos planos para fases futuras não deve ser vista como pivô reacionário em resposta a um problema, mas como serviço para apoiar suas metas comerciais no contexto de um ecossistema de arquitetura e tecnologia de nuvem em rápida evolução.