Best practice per la fase di progettazione

La fase di progettazione di un'implementazione greenfield di SAP è la base per una fase di build di successo. In questa fase, collaborerai con le parti interessate dell'infrastruttura per raccogliere i requisiti e documentare l'architettura. Ci sono anche altri allineamenti da prendere in considerazione. È necessario assicurarsi che le diverse parti interessate al progetto concordino una tempistica, una strategia di landscape e SAP su architettura AWS , inclusi ambienti ad alta disponibilità (HA) e ripristino di emergenza (DR). Questa sezione offre consigli per affrontare alcune delle sfide che potresti incontrare nella fase di progettazione del progetto.

Creazione di tempistiche di consegna e diagrammi landscape

Definisci una tempistica di consegna dell'infrastruttura non appena la tempistica del progetto di trasformazione aziendale viene condivisa con te. Questo ti aiuta a pianificare in anticipo e ad allinearti all'interno del team dell'infrastruttura. L'input principale per la creazione della sequenza temporale proviene dagli integratori di sistema (SIs) del team di progetto SAP. Calcola le date entro le quali il team SAP Basis dovrebbe completare il lavoro e quando l'infrastruttura dovrebbe essere pronta per l'installazione delle applicazioni SAP da parte del team SAP Basis.

Considerazioni:

• Una rappresentazione visiva della tempistica di consegna consente al team di comprendere rapidamente cosa viene compilato, le date di scadenza richieste e il possibile numero di risorse disponibili. Consente inoltre alle principali parti interessate di visualizzare gli ambienti in fase di creazione, la durata del progetto e il passaggio di consegne tra il team SAP Basis e il team SAP AWS Basis in un modo facile da comprendere.

  

• Una tipica implementazione greenfield di SAP dura un anno o più. Include momenti in cui il team dell'infrastruttura non compila attivamente i componenti dell'infrastruttura, quindi è importante considerare le attività e i risultati finali durante quel periodo. Esempi di attività da mappare includono la configurazione e il test dell'alta disponibilità, la configurazione e il test del ripristino di emergenza, i test delle prestazioni e gli script di automazione della compilazione.

• In un'implementazione greenfield, la comprensione dei concetti di landscape e ambiente può creare confusione. Una sequenza temporale codificata a colori che distingue tra ambienti e landscape (N, N+1, N+2) può aiutare le parti interessate a comprendere rapidamente questa matrice di informazioni.

  Di seguito è riportato un esempio di un tipico diagramma landscape SAP di alto livello. I riquadri rappresentano gli ambienti, che sono una raccolta di applicazioni (ad esempio, SAP S/4HANA), mentre i landscape sono una raccolta di ambienti utilizzati per una particolare versione.

  

• Quando crei la tabella di marcia, ti consigliamo di rivedere la tabella di marcia di alto livello e di condurre una pianificazione a lungo termine su base trimestrale fino alla costituzione del team. Oltre alla migrazione, includi altri elementi della roadmap come i flussi di lavoro per il cloud center of excellence (CCoE), l'automazione delle operazioni, la sicurezza e la conformità e il disaster recovery nel cloud.

Informazioni sui servizi regionali e documentazione delle decisioni

All'inizio della fase di progettazione, ti consigliamo di dedicare del tempo alla comprensione e alla discussione dei servizi disponibili in un determinato momento, in Regione AWS modo da poter scegliere correttamente la regione principale. In particolare, per SAP sono spesso necessarie istanze ad alte prestazioni, quindi è necessario assicurarsi che tali risorse siano disponibili nelle regioni primarie o secondarie. Scegli un tipo di istanza certificato per applicazioni SAP. Accertati che il tipo di istanza sia disponibile nelle Regioni AWS selezionate. Un modo semplice e veloce per assicurarsene consiste nell'utilizzare il comando AWS Command Line Interface (AWS CLI) per le offerte di tipo di istanza. Se i servizi non sono attualmente disponibili nella regione che desideri utilizzare per l'implementazione, considera i tempi di consegna per ordinare l'infrastruttura per quella regione.

Conferma, riconferma e documenta le decisioni relative alla regione. Diffondi tali decisioni tra il team di progetto più ampio in modo che le principali parti interessate siano informate. Se esiste un comitato di revisione dell'architettura per il progetto, assicurati di presentare questo argomento per dare a tutti l'opportunità di esprimere il proprio parere prima che la decisione sia consolidata.

Considerazioni:

• Una considerazione fondamentale sono i sistemi periferici che si integrano con SAP. Se stai ospitando applicazioni periferiche o satellitari AWS, è meglio ospitare SAP nella stessa regione principale, per evitare discussioni inutili sulla latenza. Anche se confermi che la latenza non è un problema, sarà difficile spiegare alle parti interessate perché le applicazioni periferiche sono state create in una regione diversa da quella delle applicazioni SAP.

• Il sito di ripristino di emergenza (DR) dovrebbe essere lo stesso anche per SAP e i sistemi che si integrano con SAP, in modo che i test di ripristino di emergenza possano essere coordinati in modo realistico. Sistemi diversi potrebbero richiedere soluzioni diverse. Ad esempio, un sistema SAP di grandi dimensioni come BusinessObjects o Winshuttle potrebbe non funzionare AWS Elastic Disaster Recovery e potrebbe richiedere una soluzione diversa che utilizzi un database Amazon Relational Database Service (Amazon RDS).

Definizione di convenzioni di denominazione

Verifica e documenta accuratamente le convenzioni di denominazione per l'host, l'ambiente SAP, il cloud privato virtuale (VPC) e gli account. AWS Assicurati di seguire gli standard o le convenzioni in vigore. In un'implementazione greenfield, probabilmente dovrai definire le tue convenzioni di denominazione da zero. Sii coerente. Ad esempio, se si chiama VPC Pre-Prod, l'ambiente SAP UAT e l' AWS account TST, sarà difficile associare questi tre nomi dal punto di vista del supporto. Assicurati di ottenere il consenso e assegna nomi in cui ogni carattere abbia un significato, ma lascia spazio alla flessibilità. Ad esempio, non codificare il nome della regione nel nome del server, nel caso in cui dovessi passare a un'altra regione in futuro. Evita di utilizzare la stessa convenzione di denominazione che usi per i tuoi server on-premise. Consiglia invece una convenzione di denominazione cloud flessibile se la tua organizzazione non ne ha già una.

Considerazioni:

• Usa Etichettatura di AWS per le informazioni che possono cambiare.

• Non mettete in produzione ambienti non di produzione. VPCs Se questo è un requisito, assicurati che ci sia un motivo valido prima di accettare.

Documenta tutte le decisioni

Ti consigliamo di documentare accuratamente ogni variazione di ogni decisione, chi ha preso la decisione, in quale data e chi era presente. Archivia le decisioni in un luogo pubblico, come Atlassian Confluence o un foglio di calcolo e assicurati che la decisione venga approvata correttamente. Una parte interessata o un membro del team potrebbe dimenticare il consenso raggiunto e contestare una decisione più avanti nella fase di progettazione o di build. In tal caso, è necessario disporre di dati subito disponibili per rispondere a qualsiasi domanda. Ecco alcuni esempi di decisioni chiave da documentare:

• Decisioni regionali

• Applicazioni rilevanti per l'alta disponibilità

• Decisioni di ripristino di emergenza

• Modello di supporto ambientale durante la fase del progetto

• Metodi e strumenti di backup e ripristino

• Struttura del VPC

• AWS decisioni relative all'account

• Decisioni in materia di sicurezza

Inoltre, tieni traccia di tutte le richieste relative alle funzionalità del prodotto e documenta il tempo impiegato dal team per implementare le modifiche.