Implementar o roteiro

Depois de estabelecer o roteiro, você precisa implementá-lo. Descobrimos que é aqui que os clientes enfrentam o próximo desafio: eles passaram um tempo pensando e agora precisam começar a fazer. Para conectar sua estratégia à implementação, recomendamos as seguintes etapas:

Decida por onde e como começar

Isso parece fácil, mas com muito a alcançar, identificar um ponto de partida é muitas vezes um desafio complicado e controverso. As organizações que estão migrando para a nuvem têm muito em que se concentrar, e a iniciativa pode se tornar opressora se não for contextualizada. Com o passar dos anos, as tendências dos clientes evoluíram, mas um ponto de partida consistente é a liderança transformacional. Impulsionar diretrizes e estratégias de cima para baixo e criar a declaração de missão, os princípios e o PR-FAQ permitem que a gerência intermediária e os indivíduos tomem decisões de forma autônoma, promovam a clareza e gerem valor comercial da transformação na nuvem. Se você ainda não realizou esse exercício ou algo semelhante, recomendamos fazê-lo como sua primeira tarefa.

Durante esse exercício, você deve reconhecer que, diferentemente de outras transformações tecnológicas, a transformação na nuvem aproxima a tecnologia dos negócios. A tecnologia é uma alavanca que as empresas usam para atingir metas mais amplas, permitindo agilidade, estabilidade, otimização de custos e resultados semelhantes. Você deve planejar essa transformação com a tecnologia e os negócios, trabalhando com base na estratégia de 3 a 5 anos de sua organização, identificando metas ao longo do caminho e não tendo medo de mudar quando necessário.

Organizar-se para o sucesso

A forma como sua organização está estruturada para atingir as metas de transformação, adoção e migração para a nuvem mudará à medida que sua organização amadurecer. Entender isso, preparar-se e ser intencional é fundamental para garantir o sucesso.

Geralmente, no início da jornada, as maiores equipes trabalham no ambiente on-premises. Então, à medida que a adoção da nuvem cresce, essas equipes migram para criar, amadurecer, operar e otimizar a plataforma na nuvem, e sua organização precisa se adaptar às novas formas de trabalhar em cada uma dessas etapas. Observamos que uma mudança difícil, porém importante, acontece quando uma organização transfere de 5 a 10% de suas workloads para a nuvem (passando da fase Lançar para a fase Escalar). Nesse ponto, uma organização usa equipes on-premises para operar recursos em nuvem porque a migração não é grande o suficiente para merecer mudanças em tempo integral, portanto, essas equipes precisam encontrar um equilíbrio entre as responsabilidades existentes e as novas. Ao mesmo tempo, as equipes on-premises que agora estão sendo solicitadas a operar serviços em nuvem precisam de novas habilidades, o que envolve uma curva de aprendizado acentuada.

Para entender sua organização e desenvolver um plano para permitir essas mudanças, recomendamos que você analise a topologia das equipes em toda a sua organização de TI. Usamos esse método com os clientes para entender a organização e a interligação de funções em uma organização de TI, que geralmente é diferente das estruturas organizacionais, e depois usamos o AWS COM Framework para obter orientação sobre como se organizar para atender às etapas e marcos da transformação. Quaisquer mudanças na estrutura organizacional que possam ser necessárias são informadas por este exercício.

As topologias que usamos com os clientes incluem modelos descentralizados, centralizados e federados. Eles expandem as representações 2 por 2 do modelo operacional abordadas em AWS Well-Architected Framework, Operational Excellence Pillar.

Descentralizado

Grandes corporações globais que operam em diferentes regiões geográficas ou segmentos da indústria geralmente usam o modelo descentralizado, que é ilustrado no diagrama a seguir. Nessas corporações, unidades de negócios individuais têm suas próprias provisões de TI que podem se sobrepor a outras regiões ou unidades de negócios. No entanto, isso geralmente é entendido e aceito como uma forma de proporcionar autonomia e especialização na região.

Usar a abordagem descentralizada significa que cada região ou unidade de negócios tem seu próprio modelo operacional da nuvem, adaptado às necessidades dessa região ou unidade de negócios.

Centralizado

Uma função de TI centralizada é o modelo que vemos com mais frequência. Quando esse modelo está em vigor, os clientes buscam manter a mesma topologia ao estabelecer seu modelo operacional da nuvem. Isso é ilustrado no diagrama a seguir.

Nesse modelo, a equipe central fornece uma plataforma selecionada que pode ser usada por equipes de workloads que têm seus próprios modelos operacionais da nuvem. Com essa abordagem, as equipes de workloads podem se concentrar no valor que oferecem aos clientes finais sem precisar se preocupar com os serviços, as operações ou a segurança da plataforma que estão usando. Esse modelo funciona bem para empresas menores. No entanto, em grandes organizações globais, o número de equipes de workloads pode estar na casa das centenas ou milhares. Para gerenciar nessa escala sem perder as vantagens de uma plataforma central, as organizações frequentemente fazem a transição para o modelo federado, descrito na próxima seção.

Federado

Muitas organizações adotam o modelo de TI federada porque ele fornece uma função central responsável pela plataforma de nuvem, mas permite uma variedade de modelos operacionais no nível de workload. Isso significa que a equipe central pode se concentrar em fornecer a melhor plataforma possível para a organização sem a restrição de trabalhar com o menor denominador comum. O diagrama a seguir ilustra o modelo federado.

Em grandes organizações, o modelo federado fornece a autonomia exigida pelas equipes de engenharia e, ao mesmo tempo, garante que a equipe central forneça a plataforma e o trabalho pesado indiferenciado que são comuns a todas as workloads. Nesse modelo, a equipe central precisa trabalhar da mesma forma centrada no produto que as equipes de engenharia, mas seu produto é a plataforma.

Alteração da topologia para corresponder à jornada

A topologia escolhida depende do tamanho da sua empresa, mas também se ajusta à etapa de sua jornada para a nuvem. A organização dos departamentos ou das equipes não é estática, mas muda a cada etapa da adoção da nuvem. Isso significa que você pode projetar, discutir e ampliar diferentes topologias à medida que o ambiente muda. Exemplos de fatores de influência incluem:

Estabelecer mecanismos para impulsionar as mudanças

Na Amazon, um mecanismo é definido da seguinte forma: um processo completo que converte entradas em saídas e é formado por alavancas organizacionais. Ele usa dados e feedback para apoiar o processo e garantir que os resultados sejam alcançados. Como cada organização é diferente, cada jornada do modelo operacional da nuvem é diferente, mas todas precisam de um mecanismo para impulsionar a mudança.

Recomendamos que você dedique algum tempo para entender e desenvolver mecanismos que correspondam às mudanças necessárias para implementar seu modelo operacional da nuvem. Uma abordagem conhecida é adotar os princípios ágeis. Mecanismos ágeis quebram barreiras organizacionais e baseadas em processos entre equipes isoladas e criam loops de feedback para garantir que sua organização esteja dedicando tempo à inovação nas atividades mais impactantes que gerarão o maior valor comercial.

Desenvolver incrementalmente a maturidade

A maturidade no contexto de um modelo operacional da nuvem refere-se ao quão próximas seus recursos estão das metodologias de trabalho que priorizam a nuvem. Por exemplo, o quão autônomos são seus processos e quanto envolvimento humano é necessário para gerenciar os negócios normalmente (administrar a empresa) em comparação com a inovação (mudar a empresa)? Se suas atividades estiverem mais voltadas para a primeira, sua maturidade (na nuvem) é baixa; se for a segunda, sua maturidade é maior. Estar em um nível baixo na escala de maturidade não é negativo, é um reflexo de onde você está em sua jornada. O objetivo é entender onde você está e aonde precisa chegar. Quando trabalhamos com os clientes da AWS, usamos uma escala de maturidade dentro do AWS COM Framework para fornecer as etapas ao longo da jornada.

Recomendamos o uso de um mecanismo para aumentar incrementalmente a maturidade em todos os recursos do AWS COM Framework. Um exemplo de como trabalhamos com clientes dessa forma é converter avaliações de maturidade e priorização (entradas) em um aumento na maturidade (saída) e, em seguida, realizar eventos baseados na experiência, como Dias de jogo (loops de feedback) para verificar os resultados e ajustar conforme necessário. Ao estabelecer esses mecanismos junto com os clientes, descobrimos que, quando essa força organizacional é desenvolvida, ela não apenas permite a conquista de marcos imediatos, mas também uma melhoria incremental que dura além das fases iniciais da jornada.

Dedicar-se a desenvolver as capacidades da sua organização e incorporar as alterações exigidas em habilidades específicas de forma progressiva, em pontos definidos do seu cronograma, conecta a estratégia com a prática. Também ajuda você a aproveitar as economias de escala decorrentes de suas conquistas anteriores.