As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Implemente 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, encontrar um ponto de partida costuma ser uma questão difícil e debatida. 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 clareza e gerem valor comercial a partir da transformação da nuvem. Se você ainda não realizou este exercício ou algo semelhante, nós o recomendamos 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.

Organize-se para o sucesso

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

Geralmente, no início da jornada, as maiores equipes trabalham no ambiente local. Então, à medida que a adoção da nuvem cresce, essas equipes migram para criar, amadurecer, operar e otimizar a plataforma de nuvem, e sua organização precisa se adaptar às novas formas de trabalhar em cada um desses estágios. Observamos que uma mudança difícil, mas importante, acontece quando uma organização transfere de 5 a 10 por cento de suas cargas de trabalho para a nuvem (passando da fase de lançamento para a fase de escala). Nesse ponto, uma organização usa equipes locais 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 locais que agora estão sendo solicitadas a operar serviços em nuvem exigem 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 a Estrutura AWS COM para obter orientação sobre como se organizar para atender aos estágios 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 no 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, as 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 em 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 de nuvem. Isso é ilustrado no diagrama a seguir.

Nesse modelo, a equipe central fornece uma plataforma organizada que pode ser usada por equipes de carga de trabalho que têm seus próprios modelos operacionais de nuvem. Com essa abordagem, as equipes de carga de trabalho 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 carga de trabalho pode estar na casa das centenas ou milhares. Para gerenciar nessa escala sem perder os benefícios 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 da carga de trabalho. 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 cargas de trabalho. Nesse modelo, a equipe central precisa trabalhar da mesma forma centrada no produto que as equipes de engenharia, mas seu produto é a plataforma.

Alterando a topologia para corresponder à viagem

A topologia escolhida depende do tamanho da sua empresa, mas também se ajusta ao estágio de sua jornada para a nuvem. A organização dos departamentos ou das equipes não é estática, mas muda a cada estágio 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:

Estabeleça mecanismos para impulsionar a mudança

Na Amazon, um mecanismo é definido da seguinte forma: um processo completo que converte entradas em saídas e é montado a partir de 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 de 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 de nuvem. Uma abordagem popular é adotar princípios ágeis. Mecanismos ágeis quebram barreiras organizacionais e baseadas em processos entre equipes isoladas e criam ciclos de feedback para garantir que sua organização dedique tempo à inovação nas atividades mais impactantes que gerarão o maior valor comercial.

Desenvolva incrementalmente a maturidade

A maturidade no contexto de um modelo operacional em nuvem se refere ao quão próximos seus recursos estão das formas de trabalhar que priorizam a nuvem. Por exemplo, 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 estão mais voltadas para a primeira, sua maturidade (na nuvem) é baixa; se for a segunda, sua maturidade é maior. Estar 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 AWS clientes, usamos uma escala de maturidade dentro da Estrutura AWS COM 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 (produção) e, em seguida, realizar eventos baseados na experiência, como Game Days (ciclos 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 alcançar marcos imediatos, mas permite uma melhoria incremental que dura além das fases iniciais da jornada.

Prestar atenção ao amadurecimento das capacidades de sua organização e à criação incremental das mudanças necessárias em capacidades específicas, em momentos específicos do seu roteiro, vincula a estratégia à implementação. Também ajuda você a aproveitar as economias de escala decorrentes de suas conquistas anteriores.