Práticas recomendadas para a fase de design

A fase de design de uma implementação greenfield do SAP é a base para uma fase de construção bem-sucedida. Nessa fase, você trabalha com as partes interessadas com a infraestrutura para coletar os requisitos e documentar a arquitetura. Também há alinhamentos adicionais que devem ser considerados. É necessário garantir que várias partes interessadas no projeto concordem com um cronograma, uma estratégia de cenário e o SAP na arquitetura da AWS , incluindo ambientes de alta disponibilidade (HA) e recuperação de desastres (DR). Esta seção fornece recomendações para abordar alguns dos desafios que você pode encontrar na fase de design do seu projeto.

Criar um cronograma de entrega e diagramas de cenário

Crie um cronograma de entrega de infraestrutura assim que o cronograma do projeto de transformação de negócios for compartilhado com você. Isso ajudará você a planejar com antecedência e obter o alinhamento dentro da equipe de infraestrutura. A principal contribuição para criar o cronograma vem dos integradores de sistemas (SIs) da equipe do projeto SAP. Trabalhe para determinar as datas em que a equipe SAP Basis deve concluir seus trabalhos e quando a infraestrutura deve estar pronta para a equipe SAP Basis instalar as aplicações SAP.

Considerações:

• Uma representação visual do cronograma de entrega permite que a equipe entenda rapidamente o que está sendo construído, as datas de validade exigidas e possíveis contenções de recursos. Ele também permite que as principais partes interessadas visualizem os ambientes que estão sendo construídos, a duração do projeto e a transferência entre AWS a equipe do SAP Basis de uma maneira fácil de compreender.

  

• Uma implementação greenfield típica de SAP se estende por um ano ou mais. Isso inclui momentos em que a equipe de infraestrutura não cria ativamente componentes de infraestrutura. Por isso, é importante considerar as atividades e os resultados durante esse período. Exemplos de atividades a serem mapeadas incluem configuração e teste de HA, configuração e teste de DR, testes de performance e scripts de automação da construção.

• Em uma implementação greenfield, entender os conceitos de cenário e ambientes pode ser confuso. Um cronograma codificado por cores que diferencia ambientes e cenários (N, N+1, N+2) pode ajudar as partes interessadas a entender essa matriz de informações rapidamente.

  Aqui está um exemplo de um diagrama de cenário de alto nível do SAP. As caixas representam ambientes, os quais são uma coleção de aplicações (por exemplo, SAP S/4HANA), enquanto os cenários são uma coleção de ambientes usados para uma versão específica.

  

• Ao criar o roteiro, recomendamos que você revise o roteiro de alto nível e conduza um planejamento de longo prazo trimestralmente até que a equipe esteja estabelecida. Além da migração, inclua outros itens do roteiro, como fluxos de trabalho para o centro de excelência (CCoE) em nuvem, automação de operações, segurança e conformidade e recuperação de desastres na nuvem.

Entender os serviços regionais e documentar as decisões

No início da fase de design, recomendamos que você dedique algum tempo para entender e discutir os serviços que estão disponíveis em um determinado Região da AWS local para que você possa escolher a região principal corretamente. Especificamente, instâncias de alta performance geralmente são necessárias para o SAP. Portanto, você deve garantir que esses recursos estejam disponíveis nas regiões primária ou secundárias. Escolha um tipo de instância certificado para aplicações SAP. Certifique-se de que o tipo de instância esteja disponível nas Regiões da AWS escolhidas. Uma maneira rápida e fácil de determinar isso é usar o comando da AWS Command Line Interface (AWS CLI) para ofertas de tipo de instância. Se os serviços não estiverem disponíveis no momento na região que deseja usar para sua implementação, considere o prazo para solicitar a infraestrutura para essa região.

Confirme, reconfirme e documente as decisões relacionadas às regiões. Divulgue essas decisões por toda a equipe do projeto para que as principais partes interessadas sejam informadas. Se houver um conselho de revisão de arquitetura para o projeto, certifique-se de apresentar este tópico para oferecer a todos a oportunidade de opinar antes que a decisão seja tomada.

Considerações:

• Uma consideração importante são os sistemas de limite integrados ao SAP. Se você estiver hospedando aplicativos de limite ou satélite AWS, é melhor hospedar o SAP na mesma região principal, para evitar discussões desnecessárias sobre latência. Mesmo que você confirme que a latência não é um problema, será difícil explicar às partes interessadas por que as aplicações de limite são criadas em uma região diferente das regiões das aplicações SAP.

• O local de recuperação de desastres (DR) também deve ser o mesmo para o SAP e os sistemas que se integram ao SAP para que os testes de DR possam ser coordenados de forma realista. Sistemas diferentes podem exigir soluções diferentes. Por exemplo, um sistema SAP grande, como BusinessObjects o Winshuttle, pode não funcionar AWS Elastic Disaster Recovery e precisar de uma solução diferente que use um banco de dados do Amazon Relational Database Service (Amazon RDS).

Estabelecer convenções de nomenclatura

Examine e documente minuciosamente as convenções de nomenclatura para o host, o ambiente SAP, a nuvem privada virtual (VPC) e as contas. AWS Certifique-se de seguir os padrões ou convenções existentes. Em uma implementação greenfield, provavelmente será necessário definir suas convenções de nomenclatura do zero. Seja consistente. Por exemplo, se você chamar o VPC Pre-Prod, o ambiente SAP UAT e a AWS conta TST, será difícil associar esses três nomes do ponto de vista do suporte. Certifique-se de obter consenso e atribuir nomes que tenham algum significado, mas deixe espaço para flexibilidade. Por exemplo, não codifique o nome da região no nome do servidor, caso seja necessário mudar para outra região no futuro. Evite usar a mesma convenção de nomenclatura utilizada para seus servidores on-premises. Em vez disso, recomende uma convenção de nomenclatura de nuvem flexível caso sua organização ainda não tenha uma.

Considerações:

• Use tags da AWS em informações que podem sofrer alterações.

• Não coloque ambientes que não sejam de produção na produção VPCs. Se isso for um requisito, verifique se há um motivo válido antes de concordar.

Documentar todas as decisões

Recomendamos documentar minuciosamente todas as variações de cada decisão, quem tomou a decisão, em que data e quem estava presente. Armazene as decisões em um local público, como o Atlassian Confluence ou uma planilha, e garanta a aprovação adequada da decisão. Uma parte interessada ou um membro da equipe podem esquecer o consenso alcançado e contestar uma decisão posteriormente na fase de projeto ou construção. Se isso acontecer, é necessário ter os dados prontamente disponíveis para resolver qualquer dúvida. Aqui estão alguns exemplos das principais decisões que devem ser documentadas:

• Decisões regionais

• Aplicações relevantes para HA

• Decisões de recuperação de desastres

• Modelo de suporte ambiental durante a fase do projeto

• Métodos e ferramentas de backup e restauração

• Estrutura da VPC

• AWS decisões de conta

• Decisões de segurança

Além disso, acompanhe todas as solicitações de recursos do produto e documente quanto tempo a equipe levou para implementar as mudanças.