Práticas recomendadas para a fase de design

A fase de projeto de uma SAP implementação nova é 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. Você deve garantir que várias partes interessadas do projeto concordem com um cronograma, uma estratégia de paisagem e SAP uma AWS arquitetura, 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 SAP projeto. Volte para obter as datas de quando a equipe do SAP Basis deve concluir seu trabalho e quando a infraestrutura deve estar pronta para a equipe do SAP Basis instalar os SAP aplicativos.

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. 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 e a equipe da SAP Basis de uma maneira fácil de compreender.

  

• Uma SAP implementação típica de greenfield 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 SAP paisagem típico de alto nível. As caixas representam ambientes, que são uma coleção de aplicativos (por exemplo, SAP S/4HANA), e as paisagens 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 em nuvem (CCoE), 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, geralmente são necessárias instâncias de alto desempenhoSAP, portanto, você deve garantir que esses recursos estejam disponíveis nas regiões primária ou secundária. Escolha um tipo de instância que seja certificado para SAP aplicativos. 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 limites que se integram comSAP. Se você estiver hospedando aplicativos de limite ou de satélite AWS, é melhor hospedar 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 os aplicativos de limite são criados em uma região diferente dos seus SAP aplicativos.

• O local de recuperação de desastres (DR) também deve ser o mesmo SAP e os sistemas que se integram para que os SAP testes de DR possam ser coordenados de forma realista. Sistemas diferentes podem exigir soluções diferentes. Por exemplo, um SAP sistema 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 (RDSAmazon).

Estabelecer convenções de nomenclatura

Examine e documente minuciosamente as convenções de nomenclatura do host, do SAP ambiente, da nuvem privada virtual (VPC) e AWS das contas. 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 SAP ambiente UATe 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çãoVPCs. 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

• VPCestrutura

• 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.