Praktik terbaik untuk fase desain

Fase desain implementasi SAP greenfield adalah fondasi untuk fase build yang sukses. Pada fase ini, Anda bekerja dengan pemangku kepentingan infrastruktur Anda untuk mengumpulkan persyaratan dan mendokumentasikan arsitektur. Ada juga keberpihakan tambahan yang harus Anda pertimbangkan. Anda harus memastikan bahwa berbagai pemangku kepentingan proyek menyetujui garis waktu, strategi lanskap, dan SAP pada AWS arsitektur, termasuk lingkungan ketersediaan tinggi (HA) dan pemulihan bencana (DR). Bagian ini memberikan rekomendasi untuk mengatasi beberapa tantangan yang mungkin Anda temui dalam fase desain proyek Anda.

Buat garis waktu pengiriman dan diagram lanskap

Bangun timeline pengiriman infrastruktur segera setelah timeline proyek transformasi bisnis dibagikan kepada Anda. Ini membantu Anda merencanakan ke depan dan mendapatkan keselarasan dalam tim infrastruktur. Input utama untuk membangun timeline berasal dari system integrators (SIs) pada tim proyek SAP. Bekerja kembali untuk mendapatkan tanggal kapan tim SAP Basis harus menyelesaikan pekerjaan mereka dan kapan infrastruktur harus siap untuk tim SAP Basis untuk menginstal aplikasi SAP.

Pertimbangan:

• Representasi visual dari garis waktu pengiriman memungkinkan tim untuk dengan cepat memahami apa yang sedang dibangun, tanggal yang diperlukan, dan kemungkinan pertentangan sumber daya. Hal ini juga memungkinkan pemangku kepentingan utama untuk memvisualisasikan lingkungan yang sedang dibangun, durasi proyek, dan hand-off antara AWS dan tim SAP Basis dengan cara yang mudah dipahami.

  

• Implementasi SAP greenfield yang khas mencakup satu tahun atau lebih. Ini mencakup saat-saat ketika tim infrastruktur tidak secara aktif membangun komponen infrastruktur, jadi penting untuk mempertimbangkan kegiatan dan hasil selama waktu itu. Contoh aktivitas untuk dipetakan termasuk penyiapan dan pengujian HA, penyiapan dan pengujian DR, pengujian kinerja, dan skrip otomatisasi bangunan.

• Dalam implementasi greenfield, konsep lanskap dan lingkungan dapat membingungkan untuk dipahami. Garis waktu berkode warna yang membedakan antara lingkungan dan lanskap (N, N+1, N+2) dapat membantu pemangku kepentingan memahami matriks informasi ini dengan cepat.

  Berikut adalah contoh diagram lanskap SAP tingkat tinggi yang khas. Kotak mewakili lingkungan, yang merupakan kumpulan aplikasi (misalnya, SAP S/4HANA), dan lanskap adalah kumpulan lingkungan yang digunakan untuk rilis tertentu.

  

• Saat Anda membuat peta jalan, kami sarankan Anda meninjau kembali peta jalan tingkat tinggi dan melakukan perencanaan jangka panjang setiap tiga bulan sampai tim terbentuk. Selain migrasi, sertakan item peta jalan lainnya seperti workstream untuk cloud center of excellence (CCoE), otomatisasi operasi, keamanan dan kepatuhan, dan pemulihan bencana cloud.

Memahami layanan regional dan keputusan dokumen

Pada awal fase desain, kami menyarankan Anda meluangkan waktu untuk memahami dan mendiskusikan layanan yang tersedia di tempat tertentu Wilayah AWS sehingga Anda dapat memilih Wilayah utama dengan benar. Secara khusus, instance berkinerja tinggi sering diperlukan untuk SAP, jadi Anda harus memastikan bahwa sumber daya tersebut tersedia di Wilayah primer atau sekunder. Pilih jenis instans yang disertifikasi untuk aplikasi SAP. Pastikan bahwa jenis instance tersedia dalam Wilayah AWS pilihan. Cara cepat dan mudah untuk menentukan ini adalah dengan menggunakan perintah AWS Command Line Interface (AWS CLI) untuk penawaran tipe misalnya. Jika layanan saat ini tidak tersedia di Wilayah yang ingin Anda gunakan untuk implementasi Anda, pertimbangkan waktu tunggu untuk memesan infrastruktur untuk Wilayah tersebut.

Konfirmasikan, konfirmasi ulang, dan dokumentasikan keputusan terkait Wilayah. Sebarkan keputusan tersebut di seluruh tim proyek yang lebih besar sehingga pemangku kepentingan utama mendapat informasi. Jika ada papan peninjau arsitektur untuk proyek tersebut, pastikan untuk menyajikan topik ini untuk memberi semua orang kesempatan untuk mempertimbangkan sebelum keputusan dipadatkan.

Pertimbangan:

• Pertimbangan utama adalah sistem batas yang terintegrasi dengan SAP. Jika Anda menghosting aplikasi batas atau satelit AWS, yang terbaik adalah meng-host SAP di Wilayah utama yang sama, untuk mencegah diskusi yang tidak perlu tentang latensi. Bahkan jika Anda mengonfirmasi bahwa latensi bukan masalah, akan sulit untuk menjelaskan mengapa aplikasi batas dibangun di Wilayah yang berbeda dari aplikasi SAP Anda kepada pemangku kepentingan Anda.

• Situs pemulihan bencana (DR) juga harus sama untuk SAP dan sistem yang terintegrasi dengan SAP sehingga pengujian DR dapat dikoordinasikan secara realistis. Sistem yang berbeda mungkin memerlukan solusi yang berbeda. Misalnya, sistem SAP besar seperti BusinessObjects atau Winshuttle mungkin tidak berfungsi AWS Elastic Disaster Recovery dan mungkin memerlukan solusi berbeda yang menggunakan database Amazon Relational Database Service (Amazon RDS).

Menetapkan konvensi penamaan

Secara menyeluruh memeriksa dan mendokumentasikan konvensi penamaan untuk host, lingkungan SAP, cloud pribadi virtual (VPC), dan akun. AWS Pastikan untuk mengikuti standar atau konvensi yang ada. Dalam implementasi greenfield, Anda mungkin harus menentukan konvensi penamaan Anda dari awal. Konsisten. Misalnya, jika Anda memanggil VPC Pre-Prod, lingkungan SAP UAT, dan AWS akun TST, akan sulit untuk mengaitkan ketiga nama ini dari perspektif dukungan. Pastikan untuk mendapatkan konsensus dan menetapkan nama di mana setiap karakter memiliki arti, tetapi sisakan ruang untuk fleksibilitas. Misalnya, jangan hardcode nama Region ke dalam nama server, jika Anda harus beralih ke Region lain di masa mendatang. Hindari penggunaan konvensi penamaan yang Anda gunakan untuk server lokal Anda. Sebagai gantinya, rekomendasikan konvensi penamaan cloud yang fleksibel jika organisasi Anda belum memilikinya.

Pertimbangan:

• Gunakan AWS tag untuk informasi yang dapat berubah.

• Jangan menempatkan lingkungan non-produksi dalam produksi VPCs. Jika itu persyaratan, pastikan ada alasan yang sah sebelum Anda setuju.

Dokumentasikan semua keputusan

Kami menyarankan Anda mendokumentasikan secara menyeluruh setiap variasi dari setiap keputusan, siapa yang membuat keputusan, pada tanggal berapa, dan siapa yang hadir. Simpan keputusan di tempat umum, seperti Atlassian Confluence atau spreadsheet, dan pastikan penandatanganan yang tepat pada keputusan tersebut. Seorang pemangku kepentingan atau anggota tim mungkin melupakan konsensus yang dicapai dan menantang keputusan nanti dalam fase desain atau pembangunan. Jika itu terjadi, Anda ingin memiliki data yang tersedia untuk menjawab pertanyaan apa pun. Berikut adalah contoh keputusan kunci untuk didokumentasikan:

• Keputusan wilayah

• Aplikasi yang relevan dengan HA

• Keputusan pemulihan bencana

• Model dukungan lingkungan selama fase proyek

• Metode dan alat Backup dan Restore

• Struktur VPC

• AWS keputusan akun

• Keputusan keamanan

Selain itu, lacak semua permintaan fitur produk dan dokumentasikan berapa lama waktu yang dibutuhkan tim untuk mengimplementasikan perubahan.