第 3 章
ビジネス要件と技術要件の特定と評価
配備計画の最初のステップは、Sun JavaTM System Portal Server のビジネス要件と技術要件を見極めることです。アーキテクチャーと設計の問題に取り組む前に、ビジネス要件と技術要件に関する情報を収集する必要があります。
この章で説明する内容は次のとおりです。
ビジネスの目的
ビジネス要件では、組織の問題と機会について述べ、次のような要素について考慮します。
- サービス
- サービスの可用性
- 将来の成長
- 新しいテクノロジ
- 投資規模
設計要件を作成する際に役立つものとするには、ビジネス要件で具体的な目標と目的について記述する必要があります。
ポータルのビジネス目標は、配備に関する決定に影響を与えます。目的を理解してください。ビジネス要件を把握していないと、誤った前提条件を設定しやすくなり、配備見積もりの正確さに影響を与えかねません。
次の点について自問し、ビジネスの目的を見極めてください。
- このポータルのビジネス目標は何か。たとえば、顧客へのサービスを強化することか。または、社員の生産性を向上したり、営業コストを削減したりすることか。
- どんな種類のポータルが必要か。たとえば、企業間、企業対顧客、企業対企業、またはこれらの混合か。
- 対象利用者はだれか。
- ポータルによりどのようなサービスまたは機能をユーザーに提供するのか。
- 対象利用者はポータルからどのように利益を得るのか。
- ポータルの優先度はどれほどか。ポータルを段階的に配備する計画の場合は、各段階の優先順位を定める。
(オプション) セキュリティー保護されたポータルを配備する場合は、次の点を自問してビジネスの目的を見極めます。
- イントラネットのアプリケーションやサーバーにインターネットからアクセスできるようにして、社員の生産性を高める必要があるか。
- ポータルへのアクセスをセキュリティー保護する必要があるか。
- 既存の Virtual Private Network (VPN) ソリューションの所有コストを削減する必要があるか。
- Citrix や pcAnywhere などのイントラネットアプリケーションに、インターネットからアクセスする利便性を社員に提供するか。
- イントラネットのサーバーやマシンを、インターネットから参照する利便性を社員に提供するか。
- 対象利用者は、すべてのポータルユーザー、社員、顧客などのうちだれか。
技術目標
技術要件 (機能要件とも呼ばれる) では、組織のシステムの必要と期待される結果について詳しく述べ、次の要素について考慮します。
- パフォーマンス
- セキュリティー
- 信頼性
- ポータルに期待されるパフォーマンス基準
技術要件では、アーキテクチャーに必要なすべての機能を定義し、各コンポーネントの働きとそれらを統合してシステム全体を構成する仕組みについて説明します。組織は、最善の設計手法を作成し、適切な技術を適用してポータルに適したアーキテクチャーソリューションを導き出すための技術要件が必要です。
ポータルを提供する理由は、ポータルの実装方法に直接影響します。対象となる利用者、パフォーマンス標準、および目標に関連する他の要素について定義する必要があります。
次の点について自問し、ポータルの目標を見極めてください。
- ポータルでもっとも優先されるものは何か。
- ポータルが配信するアプリケーションは何か。
- どのような利用者を対象とするか。
- どの程度のパフォーマンス標準が必要か。
- どれほどのトランザクションの量が予期されるか。ピーク使用時にはどれほどのトランザクションの量が予期されるか。
- ピーク使用時に許容される応答時間はどれほどか。
- どの程度の並行性が必要か。並行性は、任意の時点で接続可能なユーザー数。
- ポータルへのアクセスには、イントラネットとインターネットのどちらを使用するのか。
- ポータルは、1 段階で、または数段階で配備するのか。各段階について、および段階ごとの変化について説明する。
Portal Server の機能とビジネスの必要性の対応付け
前のセクションでは、ビジネスと技術の必要を概観して、Portal Server システムのさまざまな領域について自問できる点を紹介しました。このセクションでは、組織にとって重要性の高いテクノロジを判断することを目標に、特定のテクノロジの特長について考慮します。組織の当面および中長期的な計画を念頭に、これらの機能について検討してください。
続くセクションとそれぞれの表を参考にしてリストにある機能の利点を評価し、組織にとっての相対的な優先順位を定めてください。この情報は、タイミングよく費用対効果に優れた方法で配備計画を作成するのに役立ちます。
|
|
注
|
おそらく、Sun Java System の販売担当者との間でこれらのトピックについての話し合いは以前に行われています。したがってこのセクションでは、そのプロセスについて再検討します。
|
|
アイデンティティー管理
Portal Server は、アイデンティティー管理を使用して、コンテンツ、アプリケーション、およびサービスにアクセスする際、組織全体で、時には組織外でさまざまなロールを持つ数多くのユーザーを管理します。課題としては、だれがアプリケーションを使用するのか、ユーザーはどんな能力範囲で組織または企業に労働力を提供するのか、ユーザーの使命は何か、ユーザーは何にアクセスする権限をもつべきか、他の人は管理作業をどのように支援できるか、などの点が挙げられます。
表 3-1 に、アイデンティティー管理機能とその利点を示します。
表 3-1 アイデンティティー管理機能と利点
|
機能
|
説明
|
利点
|
|
ディレクトリサービス
|
Portal Server は Access Manager と Directory Server を使用します。
|
Portal Server は、認証、シングルサインオン (SSO)、管理の委任、およびパーソナライズの目的で、LDAP ディレクトリを使用し、ユーザープロファイル、ロール、および識別情報を保存します。
Portal Server は中央集中型のユーザーディレクトリに常駐可能なオープンスキーマを使用することにより、Access Manager および Directory Server 製品に対する企業またはサービスプロバイダの投資を有効活用します。
|
|
ユーザー、ポリシー、およびプロビジョニング管理
|
Access Manager により、コンテンツ、アプリケーション、およびサービスにアクセスする間、組織全体で、時には組織外でさまざまなロールを持つ数多くのユーザーを管理できます。
|
識別情報の保存と管理を行う中央集中型のアイデンティティー管理ソリューションです。ポリシーソリューションと統合してアクセス権を制御し、これらの課題を大幅に簡素化します。共通アイデンティティーを拡張して新規アプリケーションを処理し、アプリケーションで管理作業を共有できるようにします。また、普通ならこれらのサービスを最初から構築することに関連付けられるタスクを簡素化します。
ユーザーとアプリケーションの管理を統合します。コンテンツとサービスの配信をパーソナライズします。情報とサービスへのアクセスを簡素化し、無駄を省きます。アクセスおよび配信の管理に関係するコストを削減します。
アプリケーションへのアクセスをポリシーベースで行い、セキュリティーで保護します。ポータル配備が社員の LAN アクセス範囲を超えて拡張される場合でも、アクセスを確実にセキュリティー保護します。
|
|
シングルサインオン (SSO)
|
Access Manager は、SSO API によってユーザー認証とシングルサインオンを統合します。一度認証されたユーザーは、SSO API が継承します。認証されたユーザーが保護されたページへアクセスしようとすると、毎回 SSO API は、認証クレデンシャルに基づいてユーザーが適切なアクセス権を持っているかどうかを判断します。ユーザーが有効であれば、追加認証なしでページへのアクセスが許可されます。無効であれば、ユーザーは再認証するように求められます。
|
社員、パートナー、および顧客による、コンテンツ、アプリケーション、およびサービスへのアクセスを有効にしながら、認証とシングルサインオンを管理する一貫した中央集中型メカニズムを提供することによって、ユーザーの生産性を向上させます。
|
|
管理の委任
|
Access Manager 管理コンソールは、ロールベースの管理の委任の機能を異なる種類の管理者に割り当て、指定されたアクセス権に基づいて組織、ユーザー、ポリシー、ロール、チャネル、およびポータルデスクトッププロバイダを管理します。
|
IT がポータル管理の任務を委任して、貴重な IT リソースと管理を解放できるようにします。
|
|
セキュリティー
|
ポータルでの集約アプリケーションのシングルサインオンを可能にします。
|
セキュリティーはポータルにとって重要な機能です。セキュリティーによってポータル内のさまざまな必要を満たすことができます。たとえば、ポータルへの認証、ポータルとエンドユーザー間の通信の暗号化、アクセス権を持つユーザーに限定したコンテンツとアプリケーションの承認などがあります。
|
SRA
表 3-2 に、Sun Java System Portal Server Secure Remote Access (SRA) 機能とその利点を示します。
表 3-2 SRA の機能と利点
|
機能
|
説明
|
利点
|
|
統合セキュリティー
|
ユーザー、ポリシー、および認証サービスを提供すると同時に、エクストラネット機能と Virtual Private Network (VPN) 機能を「オンデマンド」で提供します。ゲートウェイコンポーネントは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。
|
ファイアウォールの背後に配置された企業のコンテンツ、アプリケーション、ファイル、およびサービスを、許可されているサプライヤ、ビジネスパートナー、および社員に提供します。
サービス妨害攻撃を防ぐため、内部と外部の両方の DMZ ベースゲートウェイを使用できます。
|
|
SRA コア
|
ユーザーは次の 4 つのコンポーネントを通してリモートアクセスできます。
- ゲートウェイ
- NetFile
- Netlet
- ホスト
|
このコンポーネントには 4 つの構成要素があります。
- ゲートウェイ - Portal Server とさまざまなゲートウェイインスタンスの間の通信を制御します。
- NetFile - ファイルシステムとディレクトリへのリモートアクセスと操作を可能にします。
- Netlet - クライアントブラウザの Netlet アプレット、ゲートウェイ、およびアプリケーションサーバー間の通信を確実にセキュリティー保護します。
- プロキシレット - URL をゲートウェイにリダイレクトします。
|
|
汎用アクセス
|
クライアントソフトウェアをインストールせずに、またはメンテナンスの必要をなくして、Web ブラウザベースの汎用アクセスを可能にします。
|
配備にかかる時間とコストを大幅に削減すると同時に、IT 管理およびメンテナンスのオーバーヘッドを簡素化します。
|
|
Netlet プロキシ
|
クライアントからゲートウェイ、およびイントラネットに常駐する Netlet Proxy までのセキュリティー保護されたトンネルを拡張するオプションコンポーネントを提供します。
|
非武装地帯 (DMZ) とイントラネットの間に配置されたファイアウォールの開いているポート数を制限します。
|
|
リライタプロキシ
|
HTTP 要求を、宛先ホストに直接送る代わりに、リライタプロキシにリダイレクトします。次にリライタプロキシは、受け取った要求を宛先サーバーに送信します。
|
リライタプロキシを使用すると、ゲートウェイとイントラネットコンピュータの間の HTTP トラフィックをセキュリティー保護し、次の 2 つの利点を生かすことができます。
- ファイアウォールがゲートウェイとサーバーの間に配置されている場合、ファイアウォールで開放する必要のあるポートは、ゲートウェイとリライタプロキシの間のポートと、ゲートウェイと Portal Server の間のポートの 2 つのみです。
- 送信先のサーバーが、HTTPS ではなく HTTP プロトコルのみをサポートしている場合でも、ゲートウェイとイントラネットの間の HTTP トラフィックは安全です。
|
検索エンジン
検索エンジンサービスは、次のチャネルで使用されます。
- ユーザーが定義したカテゴリ別ドキュメントやディスカッションの各プロファイルエントリと一致したヒット件数 (関連情報) を要約する登録チャネル。
- 個別にコンテンツを検索し、コメントの重要度を設定するディスカッションチャネル。
表 3-3 に、検索機能とその利点を示します。
表 3-3 検索機能と利点
|
機能
|
説明
|
利点
|
|
検索エンジン
|
エンドユーザーが指定する条件に基づいてドキュメントを取得できます。
|
コンテンツにアクセスしてユーザーの時間を節約します。
|
|
カテゴリ化
|
ドキュメントを階層構造に整理します。このカテゴリ化は分類と呼ばれることもあります。
|
参照と取得が可能なドキュメントをさまざまに表示します。
|
|
ロボット
|
検索エンジンロボットは、イントラネットまたはインターネット全体の情報を見回りインデックスを作成するエージェントプログラムです。
|
リソースへのリンクを自動的に検索して抽出し、それらのリソースについて説明し、説明を検索データベースに格納します。これは、生成またはインデックス作成とも呼ばれます。
|
|
ディスカッション
|
複数のスレッド化されたディスカッションの場です。
|
コンテンツは個別に検索でき、すべてのコメントに重要度が指定されます。
|
|
登録
|
異なる関心領域の新規または変更された素材をユーザーが追跡できるようにします。
|
ディスカッション、検索カテゴリ、および自由形式検索 (保存された検索) を追跡できます。
|
パーソナライズ
パーソナライズは、選択した基準に基づいてコンテンツを配信し、ユーザーにサービスを提供する機能です。
表 3-4 に、パーソナライズ機能とその利点を示します。
表 3-4 パーソナライズ機能と利点
|
機能
|
説明
|
利点
|
|
ユーザーのロールに基づくコンテンツ配信
|
Portal Server には、組織内でのユーザーのロールに基づき、ユーザーがアクセスまたは使用可能なアプリケーションを自動的に選択する機能が組み込まれています。
|
コンテンツとサービスへのカスタマイズされた迅速なアクセスを可能にすることにより、社員の生産性を上げ、顧客関係を改善し、円滑なビジネス関係を促進します。
|
|
ユーザーによるコンテンツのカスタマイズ
|
Portal Server により、エンドユーザーは関心のあるコンテンツを選択して表示できます。たとえば、個人金融ポータルのユーザーは、財務ポートフォリオを表示する際に、閲覧する株価情報を選択できます。
|
ポータル内で表示可能な情報は、個別にパーソナライズされます。さらにユーザーは、その情報をカスタマイズして、自分の好みに合わせることができます。ポータルは、Web 体験の制御を、Web サイトの作成者ではなく Web の利用者の手に委ねます。
|
|
複数ユーザー対象コンテンツの集約とカスタマイズ
|
Portal Server により、企業またはサービスプロバイダは、パーソナライズされたコンテンツを集約し、複数のユーザーコミュニティーに同時に配信できます。
|
これにより、企業は 1 つの製品から複数の製品に複数のポータルを配備し、集中管理コンソールから管理できます。また、新規コンテンツとサービスを追加し、Portal Server を再起動せずにオンデマンドで配信できます。このすべてにより時間と資金が節約され、IT 組織の一貫性が確保されます。
|
集約と統合
ポータルの重要な役割に数えられるのは、アプリケーション、サービス、およびコンテンツなどの情報を集約し、統合する機能です。この機能には、株価情報などの変動する情報をポータルを介して埋め込み、ポータル内でアプリケーションを実行し、ポータルを通してそれらのアプリケーションを配信する能力が組み込まれています。
表 3-5 に、集約および統合機能とその利点を示します。
表 3-5 集約機能と利点
|
機能
|
説明
|
利点
|
|
集約情報
|
ポータルデスクトップは、Portal Server のプライマリエンドユーザーインタフェースであり、プロバイダアプリケーションプログラミングインタフェース (PAPI) による広範なコンテンツ集約のメカニズムを備えています。ポータルデスクトップには、コンテナ階層と、特定のチャネルを構築するための基本構築ブロックとを有効にするさまざまなプロバイダが表示されます。
|
ユーザーが情報を検索する必要はありません。代わりに、情報がユーザーを見つけます。
|
|
一貫したツールセット
|
ユーザーは、会社にいる間はずっと付いて回る、Web ベースの電子メールやカレンダ作成ソフトウェアのようなツールセットを使用できます。
|
ユーザーは、あるプロジェクトで 1 つのツールを、別の場所で別のツールを使用する必要がありません。また、これらのツールはすべてポータルのフレームワークで動作するので、ツールの見た目と使い心地、操作性に一貫性を持たせることでトレーニング時間を削減できます。
|
|
コラボレーション
|
Portal Server により、企業全体のリソースとしてデータを制御し、アクセスできます。
|
多くの企業は、個々の部門によって所有されるものとしてデータを考え、企業全体のリソースとは見ていません。ポータルは、こうしたデータの管理方法を変革し、データを必要とするユーザーが制御された方法で入手できるようにする触媒のような役割を果たします。この広範でより迅速なアクセスを可能にする仕組みにより、コラボレーションを促進します。
|
|
統合
|
Portal Server により、ユーザーがアプリケーションにアクセスしたり、アプリケーションを起動したり、データにアクセスしたりする際の唯一の場所としてポータルデスクトップを使用できます。
|
既存の電子メール、カレンダ、旧バージョン、または Web の各アプリケーションを統合することにより、統一されたアクセスポイントとしてポータルを活用し、社員、パートナー、または顧客などのユーザーが、必要とする情報にすばやく簡単にアクセスできるようにします。
|
ユーザーの動作と行動パターンについての理解
ポータルを利用するユーザーについて調査してください。ユーザーがポータルを利用する状況や前システムの使用方法などの要素は、ポータルの要件を識別するための鍵となります。組織にそうした行動パターンを提供できるだけの経験がない場合は、他の組織の経験を調査して評価します。
次の点を自問してユーザーを理解してください。
- 何人のエンドユーザーが利用するか。対象利用者はどれぐらいの規模か。
- ユーザーは毎日、同じ時刻にポータルにログインするか。ユーザーは仕事でポータルを使用するのか、それとも別の場所で使用するのか。
- ユーザーたちは、同じタイムゾーンまたは異なるタイムゾーンに属しているか。
- 標準的なユーザーの接続時間、または有効なポータルセッションが開いている時間としてどれぐらいの長さが予想されるか。既存のアプリケーションに関する使用方法の統計情報を何か持っているか。既存ポータルの Web トラフィック分析結果があるか。
- 事前定義された時間内に予想される、訪問者セッションの数、または 1 人の訪問者の訪問回数はどの程度か。
- ポータルの利用頻度は、時間の経過とともに増加することが期待できるか。または、安定した状態を維持しそうか。
- どれぐらいの割合でユーザーベースが成長するか。
- ユーザーは、ポータルで配信しようとするアプリケーションをどのように使用してきたか。
- ユーザーが定期的に使用すると期待されるのはどのポータルチャネルか。
- ユーザーはポータルのコンテンツに何を期待しているか。ポータルが提供するものの中で、前身となる Web ベース情報または他のリソースをユーザーはどのように使用してきたか。
