技術の要件 (または機能の要件) は、組織のシステムニーズの詳細です。
既存の利用率パターンを、配備実現のための明確で評価可能な目標として定義します。そのような目標を定義する際に参考となる質問を、次に示します。
現在のサービスはどのように利用されていますか。
ユーザーは分類可能ですか (一時的なユーザー、常用ユーザー、ヘビーユーザーなど)。
ユーザーはどのような方法でサービスにアクセスしますか (自身のデスクトップから、共有 PC または工場の現場から、ローミングラップトップからなど)。
ユーザーが通常送信するメッセージのサイズはどのくらいですか。
カレンダのアポイントには、通常、何人くらいの招待が掲載されていますか。
ユーザーはメッセージをいくつ送信しますか。
通常、ユーザーが日ごとまたは時間ごとに作成するカレンダ予定および作業はいくつですか。
ユーザーがメッセージを送信するのは、社内のどのサイトですか。
必要とされる並行性 (任意の時刻に接続可能なユーザーの数) はどの程度ですか。
サービスにアクセスするユーザーについて調査します。ユーザーはいつ既存のサービスを使うのかといった要素が、配備の要件、ひいては配備の目標を定める重要なポイントとなります。組織の今までの事例からこれらのパターンを得ることができない場合は、他の組織の事例を研究し、推測します。
利用率のきわめて高い部署では、専用のサーバーが必要になる場合もあります。一般に、ユーザーが実際のサーバーから遠く離れており、回線速度も遅い場合、応答時間が長くなります。応答時間が適切であるかどうかを検討する必要があります。
次の質問を検討して、サイトの分散が配備目標に与える影響を理解します。
サイトは地理的にどのように分散されていますか。
サイト間の帯域幅はどれだけありますか。
集中化方式を採用する場合は、分散化方式よりも広い帯域幅が必要です。ミッションクリティカルなサイトには、専用サーバーが必要です。
ネットワーク要件の理解に役立つ質問を、次に示します。
内部ネットワーク情報をわかりにくくしたいと考えますか。
ネットワークサービスに冗長性を持たせたいと考えていますか。
レイヤーホストにアクセスする場合に、利用可能なデータを制限したいと考えていますか。
エンドユーザーの設定を簡略化したいと考えていますか (たとえば、エンドユーザーを移動する場合に変更が不要な単一のメールホストをエンドユーザーに入力させるなど)。
ネットワークの HTTP トラフィックを削減したいと考えていますか。
これらの質問に「はい」と答えた場合は、2 層アーキテクチャーをお勧めします。
より信頼性の高い高可用性帯域幅が利用できる場合は、集中化サーバーを採用できます。
既存のインフラストラクチャーと設備で、この配備が可能ですか。
DNS サーバーは追加の負荷を処理できますか。ディレクトリサーバーはどうですか。ネットワークはどうですか。ルーターはどうですか。スイッチはどうですか。ファイアウォールはどうですか。
24時間、週に 7 日 (24 x 7) 体制のサポートは、特定のサイトでのみ提供されます。少数のサーバーによる簡単なアーキテクチャーの場合は、サポートが容易です。
運用グループと技術サポートグループに十分な能力があり、この配備を促進できる状況にありますか。
運用グループと技術サポートグループは、配備期間中に増大する負荷に対処できますか。