Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Bonnes pratiques pour l'étape de conception
La phase de conception d'une implémentation inédite de SAP est la base d'une phase de génération réussie. Au cours de cette phase, vous collaborez avec les parties prenantes de votre infrastructure pour recueillir les exigences et documenter l'architecture. Il existe également des alignements supplémentaires que vous devez prendre en compte. Vous devez vous assurer que les différentes parties prenantes du projet s'accordent sur un calendrier, une stratégie de paysage et une architecture SAP sur AWS , y compris les environnements de haute disponibilité (HA) et de reprise après sinistre (DR). Cette section fournit des recommandations pour relever certains des défis que vous pourriez rencontrer lors de la phase de conception de votre projet.
Création d'un calendrier de livraison et des schémas de paysage
Établissez un calendrier de livraison de l'infrastructure dès que le calendrier du projet de transformation d'entreprise vous est communiqué. Cela vous permet de planifier à l'avance et de vous aligner au sein de l'équipe d'infrastructure. La principale contribution à l'élaboration de la chronologie provient des intégrateurs système (SIs) de l'équipe de projet SAP. Revenez pour déterminer les dates auxquelles l'équipe SAP Basis doit terminer son travail et auxquelles l'infrastructure doit être prête pour que l'équipe SAP Basis installe les applications SAP.
Considérations :
-
Une représentation visuelle du calendrier de livraison permet à l'équipe de comprendre rapidement ce qui est en cours de génération, les échéances et les éventuels conflits entre les ressources. Il permet également aux principales parties prenantes de visualiser les environnements en cours de création, la durée du projet et le transfert entre l'équipe SAP Basis AWS et l'équipe SAP Basis d'une manière facile à comprendre.
-
Une implémentation inédite de SAP type s'étale sur un an ou plus. Elle inclut les moments où l'équipe d'infrastructure ne génère pas activement les composants de l'infrastructure. Il est donc important de prendre en compte les activités et les livrables pendant cette période. Les exemples d'activités à mapper incluent la configuration et les tests HA, la configuration et les tests DR, les tests de performance et les scripts d'automatisation de la génération.
-
Dans une implémentation inédite, les concepts de paysage et d'environnement peuvent être difficiles à comprendre. Une chronologie codée par couleur qui fait la différence entre les environnements et les paysages (N, N+1, N+2) peut aider les parties prenantes à comprendre rapidement cette matrice d'informations.
Voici un exemple de diagramme de paysage SAP de haut niveau. Les cases représentent les environnements, qui sont un ensemble d'applications (par exemple, SAP S/4HANA), tandis que les paysages sont un ensemble d'environnements utilisés pour une version particulière.
-
Lorsque vous créez la feuille de route, nous vous recommandons de revoir la feuille de route de haut niveau et de procéder à une planification à long terme sur une base trimestrielle jusqu'à ce que l'équipe soit constituée. Outre la migration, incluez d'autres éléments de feuille de route tels que les flux de travail pour le centre d'excellence cloud (CCoE), l'automatisation des opérations, la sécurité et la conformité, et la reprise après sinistre dans le cloud.
Compréhension des services régionaux et documentation des décisions
Au début de la phase de conception, nous vous recommandons de prendre le temps de comprendre et de discuter des services disponibles dans une région donnée Région AWS afin de pouvoir choisir correctement la région principale. Plus précisément, des instances à hautes performances sont souvent requises pour SAP. Vous devez donc vous assurer que ces ressources sont disponibles dans les régions principales ou secondaires. Choisissez un type d'instance certifié pour les applications SAP
Confirmez, reconfirmez et documentez les décisions relatives à la région. Communiquez ces décisions au sein de l'ensemble de l'équipe de projet afin que les principales parties prenantes soient informées. S'il existe un comité d'examen de l'architecture pour le projet, assurez-vous de présenter ce sujet afin de donner à chacun l'occasion de se prononcer avant que la décision ne soit prise.
Considérations :
-
Les systèmes de délimitation qui s'intègrent à SAP constituent un élément clé à prendre en compte. Si vous hébergez des applications limites ou satellites sur AWS, il est préférable d'héberger SAP dans la même région principale, afin d'éviter toute discussion inutile sur la latence. Même si vous confirmez que la latence n'est pas un problème, il sera difficile d'expliquer à vos parties prenantes pourquoi les applications limitrophes sont créées dans une région différente de celle de vos applications SAP.
-
Le site de reprise après sinistre (DR) doit également être le même pour SAP et les systèmes intégrés à SAP afin que les tests de reprise après sinistre puissent être coordonnés de manière réaliste. Différents systèmes peuvent nécessiter des solutions différentes. Par exemple, un grand système SAP tel que BusinessObjects Winshuttle peut ne pas fonctionner avec une solution différente utilisant une base de données Amazon Relational Database Service (Amazon RDS) AWS Elastic Disaster Recovery et nécessiter une solution différente.
Établissement de conventions de dénomination
Vérifiez et documentez minutieusement les conventions de dénomination de l'hôte, de l'environnement SAP, du cloud privé virtuel (VPC) et AWS des comptes. Assurez-vous de respecter les normes ou les conventions en vigueur. Dans une implémentation inédite, vous devrez probablement définir vos conventions de dénomination en partant de zéro. Soyez cohérent. Par exemple, si vous appelez le VPC Pre-Prod, l'environnement SAP UAT et le AWS compte TST, il sera difficile d'associer ces trois noms du point de vue du support. Assurez-vous de parvenir à un consensus et d'attribuer des noms dans lesquels chaque caractère a une signification, tout en laissant de la place à la flexibilité. Par exemple, ne codez pas en dur le nom de la région dans le nom du serveur, au cas où vous devriez changer de région à l'avenir. Évitez d'utiliser la même convention de dénomination que celle pour vos serveurs sur site. Recommandez plutôt une convention de dénomination cloud flexible si votre organisation n'en possède pas déjà une.
Considérations :
-
Utilisez le balisage AWS pour les informations susceptibles de changer.
-
Ne mettez pas d'environnements non liés à la production en production VPCs. S'il s'agit d'une exigence, assurez-vous qu'il existe une raison valable avant d'accepter.
Documentation de toutes les décisions
Nous vous recommandons de documenter minutieusement toutes les variantes de chaque décision, en indiquant qui a pris la décision, à quelle date et qui était présent. Stockez les décisions dans un lieu public, tel qu'Atlassian Confluence ou une feuille de calcul, et veillez à ce qu'elles soient correctement validées. Une partie prenante ou un membre de l'équipe peut oublier le consensus obtenu et contester une décision plus tard lors de la phase de conception ou de génération. Dans ce cas, vous devez disposer de données facilement accessibles pour répondre à toutes vos questions. Voici des exemples de décisions clés à documenter :
-
Décisions de la région
-
Applications pertinentes pour la haute disponibilité
-
Décisions relatives à la reprise après sinistre
-
Modèle de prise en charge d'environnement pendant la phase du projet
-
Méthodes et outils de sauvegarde et de restauration
-
Structure de VPC
-
AWS décisions relatives aux comptes
-
Décisions de sécurité
En outre, suivez toutes les demandes de fonctionnalités du produit et documentez le temps qu'il a fallu à l'équipe pour mettre en œuvre les modifications.
