Prácticas recomendadas para la fase de diseño

La fase de diseño de una implementación desde cero de SAP es la base para una fase de creación exitosa. En esta fase, se trabaja con las partes interesadas en la infraestructura para recopilar requisitos y documentar la arquitectura. También existen alineaciones adicionales que debe tener en cuenta. Debe asegurarse de que las distintas partes interesadas en el proyecto estén de acuerdo en cuanto al cronograma, la estrategia del panorama y la arquitectura de SAP en AWS , que incluye entornos de alta disponibilidad (HA) y de recuperación de desastres (DR). En esta sección, se brindan recomendaciones para abordar algunos de los desafíos que podrían surgir en la fase de diseño de un proyecto.

Cree un cronograma de entrega y diagramas de panorama

Cree un cronograma de entrega de infraestructura tan pronto como reciba el cronograma del proyecto de transformación empresarial. Esto ayuda a planificar con antelación y a alinearse con el equipo de infraestructura. La información principal para elaborar el cronograma proviene de los integradores de sistemas (SIs) del equipo del proyecto de SAP. Determine las fechas en las que el equipo de SAP Basis debe completar el trabajo y cuándo debe estar lista la infraestructura para que el equipo de SAP Basis instale las aplicaciones de SAP.

Consideraciones:

• Una representación visual del cronograma de entrega permite al equipo comprender rápidamente lo que se crea, las fechas de entrega requeridas y las posibles limitaciones de recursos. También permite a las partes interesadas clave visualizar los entornos que se están creando, la duración del proyecto y el traspaso entre el equipo de SAP Basis AWS y el equipo de SAP Basis de una manera fácil de comprender.

  

• Una implementación desde cero de SAP típica dura un año o más. Incluye momentos en los que el equipo de infraestructura no crea componentes de infraestructura de forma activa, por lo que es importante tener en cuenta las actividades y los resultados durante ese tiempo. Entre los ejemplos de actividades que se pueden asignar se incluyen la configuración y las pruebas de alta disponibilidad, la configuración y las pruebas de DR, las pruebas de rendimiento y la creación de scripts de automatización.

• En una implementación desde cero, los conceptos de panorama y de entorno pueden resultar confusos. Un cronograma codificado mediante colores que diferencie entre entornos y panoramas (N, N+1, N+2) puede ayudar a las partes interesadas a comprender rápidamente esta matriz de información.

  A continuación, se muestra un ejemplo de diagrama de un panorama de SAP general. Los recuadros representan entornos, que son un conjunto de aplicaciones (por ejemplo, SAP S/4HANA), y los panoramas son un conjunto de entornos que se utilizan para una versión determinada.

  

• Cuando cree la hoja de ruta, le recomendamos que revise la hoja de ruta de alto nivel y lleve a cabo una planificación a largo plazo trimestralmente hasta que el equipo se haya establecido. Además de la migración, incluya otros elementos de la hoja de ruta, como los flujos de trabajo para el centro de excelencia (CCoE) en la nube, la automatización de las operaciones, la seguridad y el cumplimiento y la recuperación ante desastres en la nube.

Comprender los servicios regionales y documentar las decisiones

Al principio de la fase de diseño, le recomendamos que dedique tiempo a comprender y analizar los servicios disponibles en una región concreta Región de AWS para poder elegir correctamente la región principal. En concreto, SAP suele requerir instancias de alto rendimiento, por lo que debe asegurarse de que estos recursos estén disponibles en las regiones principales o secundarias. Elija un tipo de instancia certificada para aplicaciones de SAP. Asegúrese de que el tipo de instancia esté disponible en la Regiones de AWS que elija. Una forma rápida y sencilla de determinar esto es utilizar el comando AWS Command Line Interface (AWS CLI) para ver ofertas de tipos de instancias. Si los servicios no están disponibles actualmente en la región que desea utilizar para la implementación, tenga en cuenta el tiempo necesario para solicitar la infraestructura para esa región.

Confirme, vuelva a confirmar y registre las decisiones relacionadas con la región. Difunda esas decisiones entre todo el equipo del proyecto para que las partes interesadas clave estén informadas. Si existe una junta de revisión de la arquitectura del proyecto, asegúrese de presentar este tema para que todos tengan la oportunidad de opinar antes de tomar una decisión definitiva.

Consideraciones:

• Una consideración clave son los sistemas límite que se integran con SAP. Si aloja aplicaciones limítrofes o satélites AWS, lo mejor es alojar SAP en la misma región principal para evitar discusiones innecesarias sobre la latencia. Incluso si confirma que la latencia no es un problema, será difícil explicar a las partes interesadas por qué las aplicaciones límite se crean en una región diferente a la de las aplicaciones de SAP.

• El sitio de recuperación de desastres (DR) también debería ser el mismo para SAP y los sistemas que se integran con SAP, de modo que las pruebas de DR se puedan coordinar de forma realista. Los diferentes sistemas pueden requerir soluciones diferentes. Por ejemplo, es posible que un sistema SAP grande, como BusinessObjects Winshuttle, no funcione AWS Elastic Disaster Recovery y necesite una solución diferente que utilice una base de datos Amazon Relational Database Service (Amazon RDS).

Establezca convenciones de nomenclatura

Examine y documente minuciosamente las convenciones de nomenclatura para el host, el entorno SAP, la nube privada virtual (VPC) y AWS las cuentas. Asegúrese de seguir las normas o las convenciones vigentes. En una implementación desde cero, es probable que tenga que definir convenciones de nomenclatura desde cero. Sea coherente. Por ejemplo, si llama a la VPC Pre-Prod, al entorno SAP UAT y a la AWS cuenta TST, será difícil asociar estos tres nombres desde el punto de vista del soporte. Asegúrese de llegar a un consenso y asignar nombres en los que cada carácter tenga un significado, pero deje lugar a la flexibilidad. Por ejemplo, en caso de que tenga que cambiar a otra región en el futuro, no codifique el nombre de la región en el nombre del servidor. Evite utilizar el mismo nombre que utiliza en servidores en las instalaciones. En lugar de eso, recomiende una convención flexible de nomenclatura en la nube, si la organización aún no la tiene.

Consideraciones:

• Utilice el etiquetado de AWS para obtener información que pueda cambiar.

• No coloque entornos que no sean de producción en producción. VPCs Si esto es un requisito, asegúrese de que haya una razón válida antes de aceptar.

Registre todas las decisiones

Recomendamos registrar minuciosamente cada variación de cada decisión, quién la tomó, en qué fecha y quién estuvo presente. Guarde las decisiones en un lugar público, como Atlassian Confluence o una hoja de cálculo, y asegúrese de aprobarlas correctamente. Una parte interesada o un miembro del equipo podría olvidar el consenso alcanzado y cuestionar una decisión más adelante en la fase de diseño o creación. Si eso ocurre, será conveniente tener los datos disponibles para responder a cualquier duda. A continuación, se muestran ejemplos de decisiones clave que se pueden registrar:

• Decisiones respecto a la región

• Aplicaciones que son pertinentes para la alta disponibilidad

• Decisiones de recuperación de desastres

• Modelo de soporte ambiental durante la fase de proyecto

• Métodos y herramientas de respaldo y restauración

• Estructura de VPC

• AWS decisiones contables

• Decisiones sobre la seguridad

Además, haz un seguimiento de todas las solicitudes de funciones del producto y documenta cuánto tiempo tardó el equipo en implementar los cambios.