設計段階のベストプラクティス

SAP グリーンフィールド導入の設計段階は、構築段階を成功に導くための基礎となる部分です。この段階では、インフラストラクチャの利害関係者と協力してさまざまな要件を収集し、アーキテクチャを文書に記録します。検討しなければならない調整事項は他にもあります。プロジェクトの各利害関係者が、タイムライン、ランドスケープ戦略、そして、高可用性 (HA) 環境およびディザスタリカバリ (DR) 環境を含めた SAP on AWS のアーキテクチャに合意していることを確認する必要があります。こちらのセクションでは、プロジェクトの設計段階で生じやすい課題への、推奨される対処方法について説明します。

デリバリーのタイムラインとランドスケープのダイアグラムを作成する

ビジネストランスフォーメーションプロジェクトのタイムラインを受け取ったら、すぐにインフラストラクチャのデリバリータイムラインを作成します。すぐに作成すれば、前もって計画を立て、インフラストラクチャチームの内部で意見を調整することができます。タイムラインを作成するための主な情報は、SAP プロジェクトチームのシステムインテグレーター (SI) から入手します。SAP Basis チームが作業を完了すべき日付と、同チームが SAP アプリケーションをインストールするため、インフラストラクチャの準備を完了しておくべき日付を逆算して算出します。

考慮事項:

• デリバリータイムラインを視覚的に表示すれば、チームは、現在は何を構築しているか、その期日はいつか、どのようなリソースの競合があり得るかを一目で把握できます。また、主要な利害関係者は、構築中の環境、プロジェクトの期間、 と AWS SAP Basis チーム間の引き渡しを、理解しやすい方法で視覚化できます。

  

• SAP グリーンフィールド導入の一般的な所要期間は 1 年間かそれ以上にわたります。この期間には、インフラストラクチャチームがインフラストラクチャコンポーネントを活発に作成しない時期も含まれます。したがって、その時期のアクティビティと成果物を考慮に入れておく必要があります。マップすべきアクティビティには、HA の設定とテスト、DR の設定とテスト、パフォーマンスのテスト、自動化スクリプトの作成などがあります。

• グリーンフィールド導入では、ランドスケープと環境を把握する際に混乱することがあります。環境とランドスケープ (N、N+1、N+2) とを区別して色分けしたタイムラインを使えば、利害関係者も情報のマトリックスをすぐに理解することができます。

  こちらは、SAP のランドスケープを概略的に示したダイアグラムのサンプルです。各ボックスは環境を表します。環境はアプリケーション (SAP S/4HANA など) の集合です。ランドスケープは特定のリリースに使用される環境の集合です。

  

• ロードマップを作成するときは、高レベルのロードマップを再検討し、チームが確立されるまで四半期ごとに長期計画を行うことをお勧めします。移行に加えて、クラウドセンターオブエクセレンス (CCoE) のワークストリーム、運用の自動化、セキュリティとコンプライアンス、クラウドディザスタリカバリなどの他のロードマップ項目を含めます。

リージョンのサービスを把握し決定事項を記録する

設計フェーズの開始時に、プライマリリージョンを正しく選択 AWS リージョン できるように、特定の で利用できるサービスを理解し、話し合う時間を取ることをお勧めします。特に SAP では高性能なインスタンスが必要になることが多いため、そのためのリソースがプライマリリージョンまたはセカンダリージョンで利用できることを確認しておかねばなりません。インスタンスタイプは、SAP アプリケーションで認定されているものを選びます。選択した AWS リージョン でそのインスタンスタイプを使用できることを確認します。instance-type-offerings のAWS Command Line Interface (AWS CLI) コマンドを使用すれば、すばやく簡単に確認できます。導入に使用するリージョンで現時点でサービスを利用できない場合は、そのリージョンでインフラストラクチャをオーダーするのに要する時間を考慮に入れいます。

リージョン関連の決定事項は、確認および再確認して記録します。この決定事項は、より規模の大きいプロジェクトチームに回覧して主要な利害関係者に情報が行き渡るようにします。プロジェクトにアーキテクチャ検証委員会がある場合は、決定が確定する前に事項を提起し、委員全員が意見を述べられるようにします。

考慮事項:

• 重要な考慮事項の 1 つが、SAP と統合する境界システムです。境界または衛星アプリケーションをホストしている場合は AWS、レイテンシーに関する不要な議論を防ぐために、同じプライマリリージョンで SAP をホストすることをお勧めします。レイテンシーに問題がないことを確認できたとしても、境界アプリケーションを SAP アプリケーションとは異なるリージョンに構築する理由を利害関係者に説明するのは簡単なことではありません。

• ディザスタリカバリ (DR) のサイトも、DR のテストを実際に即して調整できるよう、SAP や SAP と統合するシステムと同じ場所にする必要があります。システムごとに異なるソリューションが必要になる場合があります。例えば、BusinessObjects や Winshuttle などの大規模な SAP システムは で動作せず AWS Elastic Disaster Recovery 、Amazon Relational Database Service (Amazon RDS) データベースを使用する別のソリューションが必要になる場合があります。

命名規則を作成する

ホスト、SAP 環境、Virtual Private Cloud (VPC)、 AWS およびアカウントの命名規則を徹底的に検証し、文書化します。既存の基準または規則には必ず従います。グリーンフィールド導入では、命名規則はおそらく一から定義しなければならないはずです。必ず整合性を保ちましょう。例えば、VPC Pre-Prod、SAP 環境 UAT、および AWS アカウント TST を呼び出す場合、サポートの観点からこれら 3 つの名前を関連付けるのは困難です。必ず合意を得た上で、それぞれの文字が意味を持つように、ただし柔軟性の余地は残して、名前を付けます。例えば、将来別のリージョンに切り替えなければならなくなった場合に備えて、リージョン名をサーバー名に書き込むことは避けます。オンプレミスサーバーに使用している命名規則は使用しません。代わりに、自分の組織でまだ使用したことがなければ、クラウドの柔軟な命名規則を使用することが推奨されます。

考慮事項:

• 変更の可能性がある情報には AWS タグを使用します。

• 非本番環境を本番用 VPC の中に置くことはできません。置くことが要件になっている場合は、妥当な理由があることを確認してから承諾します。

決定事項はすべて記録する

決定事項は、すべての変更履歴、決定を下した人、決定した日付、決定に立ち会った人を詳細に記録しておくことが推奨されます。決定事項は、Atlassian Confluence やスプレッドシートなど公開されている場所に保管し、適切に承認されるようにします。利害関係者やチームメンバーが、すでに合意済みであることを忘れて、設計や構築の段階に入ってから決定事項に異議を唱えるような場合があります。そうした場合に備え、異議に対処できるようデータをすぐに取り出せるようにしておくことが推奨されます。記録しておくべき決定事項には、以下のようなものがあります。

• リージョンの決定

• HA 関連のアプリケーション

• ディザスタリカバリの決定事項

• プロジェクト段階の環境支援モデル

• バックアップと復元の方法およびツール

• VPC の構造

• AWS アカウントの決定

• セキュリティに関する決定事項

さらに、すべての製品機能のリクエストを追跡し、チームが変更を実装するのにかかった時間を文書化します。