アーキテクチャ・ジャーナル エンタープライズ IT 向けソフトウェア + サービスの消費に関する考慮事項 Kevin Sangwell 2008/09/22
Page1 Page2 Page3 Page4

■データ

　基幹業務アプリケーションは、外部でソーシングされている場合でも、「孤島」で存在し続けることは多くありません。給与アプリケーションはそのよい例です。給与サービス プロバイダには、給与を毎月処理するための、社員の氏名や給与金額などの生データが必要です。この例では、内部 HR システムからの関連情報をシンプルに抽出することによって、生データが提供されます。XLS ファイルや CSV ファイルを給与プロバイダに電子メールで送信すると、必要なレベルのセキュリティ/ 機密性を確保できないので、別の形式のデータ交換が必要となります。これを提供することを期待されるのが IT 部門です。つまり、IT 部門は、エンタープライズ アプリケーション統合 (EAI) プロジェクトに直面します。

　ビルディング ブロック サービスとアタッチ サービスは、ローカル アプリケーションの拡張機能として開発者によって消費されることを目的として設計されているため、EAI の観点から見ると統合はいたって簡単です。アタッチ サービスの一例としては、Exchange Hosted Services for Filtering が挙げられます (Exchange Hosted Services の詳細については、「参考資料」を参照してください)。この場合の統合は、次の 2 つの側面を持ちます。

1. DNS: MX レコードがサービス プロバイダ ( この場合はマイクロソフト) を参照するように変更されます。
2. サービス プロバイダからの受信 SMTP しか許可しないようにファイアウォール ルールが変更されます ( これによってセキュリティが強化されます)。

　この記事では、インフラストラクチャに重点を置いているため、EAI の詳細には触れません。ただし、インフラストラクチャとデータの関連については、次の観点からも考察していきます。

• ファイアウォール ルールとフィルタ
• 暗号化と署名
• ユーザー ビュー

●ファイアウォール

　完成型サービスの消費とファイアウォールの関連性を理解するには、どの内部アプリケーションがどのような形式でソフトウェア サービスと統合するかを調べる必要があります。統合が必要な内部アプリケーションは 1 つか、複数か。公開やトラフィック フローを許可するには、どのようなファイアウォール ルールを作成する必要があるか。アプリケーションが XML を交換する場合は、ファイアウォールでの検証が必要か。また、ファイアウォールはこの機能を提供できるか。データを何らかの形式のワークフローと統合させる必要があるか。その場合、内部/ 外部のインフラストラクチャはこのワークフローにどのように組み込まれるか。こういった項目を調べる必要があります。統合が HTTP (SOAP など) 経由で行われる場合は、ルールの作成以外でもファイアウォールに影響が及ぶ可能性があります。

　ビルディング ブロック サービスとアタッチ サービスは、ローカルのバック エンド インフラストラクチャを伴う場合が多く、当然のことながら、これがデータ統合とセキュリティの焦点となります。実際、一部の SaaS ベンダは、データを企業ファイアウォールの内側に格納したとき企業の購読意欲が高まることを認識し、アプライアンスを顧客データ センター内にインストールすることによって、完成型サービスを S+S モデルに進化させるよう取り組んでいます。

●暗号化と署名

　暗号化データをインターネット上で交換する最も効果的な方法は、パブリックな証明機関からの証明書を採用することです。証明書がクライアントにインストールされると、公開キー基盤 (PKI) プロジェクトが必要となり、証明書のライフサイクル管理、証明書失効リストの公開なども必要となります。PKI プロジェクトは決して簡単ではありませんが、ひとたび完了すると、電子メールの署名やスマート カード認証などの機能がインフラストラクチャ内で有効になります。

　もちろん、S+S 実装環境でローカルのバックエンド インフラストラクチャを使用した場合、暗号化と署名はエンド ポイント数が減少するために格段に簡単になります。

●ユーザー ビュー

　データについては、ユーザー ビューの観点からも考察する必要があります。使い慣れたツール、つまり Microsoft Office アプリケーションで是が非でも作業を続けたいと考えているビジネス ユーザーは少なくありません。ビジネス ユーザーが日常的な管理におけるデータの抽出と Excel の使用に固執するあまり、新規アプリケーションがその可能性を最大限に発揮できないということは多々あります。抽出されたデータがアプリケーションに戻されることはめったにありません。こうした中、多くの独立系ソフトウェア ベンダが、Office をアプリケーション プラットフォームとして使用することにより、Office Business Applications としてのアプリケーション クライアントの構築に着手しています。通常、この結果として採用が進み、トレーニング オーバーヘッドが緩和されますが、IT 部門は展開と保守に関連した問題に直面します。ここでは、ソフトウェア サービス プロバイダから、企業に必要な機能がすべて提供されるか。または、ローカル ツール/ システムで操作/ 分析を実行するには、ユーザーがデータを抽出する必要があるか。ソフトウェア サービスを採用した結果、Access と Excel でさらに部門ごとにアプリケーションが構築されるか。このような点を考慮する必要があります。

データに関する考慮事項の要約

データ統合ニーズと ETL ニーズを把握するには、分析が必要です。 統合を許可するためにファイアウォール ルールが必要となる場合があります。 アプリケーション データのフィルタ機能を提供するには、ファイアウォールの更新が必要となる場合があります (XML スキーマの検証など)。 認証、暗号化、および署名要件をサポートするには、証明書の購入または PKI の実装が必要となる場合があります。

■運用

　アプリケーションまたはサービスを外部にソーシングする際の運用の統合に伴う問題は、ある意味で矛盾しています。と言うのも、コンシューマであることの主な利点は、運用がプロバイダの責任になることですが、内部の運用とプロセスは、さまざまな領域で外部のアプリケーションまたはサービスの影響を受けるからです。顕著な例がヘルプ デスクとユーザー向けトレーニングです。

●ヘルプ デスク

　非効率的でわかりにくいコール センターの運用は、多くのコンシューマにとって不満の種となっています。これと同様の問題を防ぐため、内部のヘルプ デスク チームは、IT 業務に統合される新しいアプリケーションとサービスを承知している必要があります。エンタープライズ ユーザーは、外部アプリケーションにアクセスするために、多数の内部 IT システムに依存しています。その例として挙げられるのが、ネットワーク、DNS、プロキシ サーバーなどです。これらの IT システムをサポートすることは、サービス プロバイダではなく、企業のヘルプ デスクの責任です。企業のサポート プロセスを簡略化することの重要性は、現在、多くの組織で認識され、たとえば、最初に適切な対応チームに問い合わせるための一括の電話番号やイントラネット サイトが提供されるようになっています。

●トレーニング

　ユーザー向けトレーニングは、新規アプリケーションがどこでホストされるかにかかわらず、アプリケーションの導入にかかわる重要な側面の 1 つです。完成型サービスの利点の 1 つは、一般にオンデマンドのトレーニングがプロバイダから提供されるということです。ただし、これらのトレーニングの質に対する企業の影響力はほとんどないに等しく、質の低いトレーニングにより、サポート コストが増大し、ビジネスの生産性が低下する可能性があります。また、サービスの一部としてアップグレードを導入することは、完成型サービスの購読者にもたらされるメリットの 1 つですが、これが問題となる場合もあります。全スタッフがトレーニングを受け終わるまでアップグレードの実装を待つことができないと、内部ヘルプ デスクに寄せられるサポート コールの件数が急増する可能性があるからです。これに関連する問題として、完成型サービスの個々の機能を選択的に無効化できるかということも挙げられます。つまり、社内で既に提供されている機能がある場合、IT 部門は、すべてのユーザーが内部の機能を使用するように徹底する必要があります。

「ビジネスにとってのアプリケーションの重要性が高いほど、考慮すべき項目も多くなります。完成型サービスとして配布される基幹業務アプリケーションは、統合に多大な労力を必要とします。」

●展開

　完成型サービスでブラウザがクライアントとして使用される場合は、ブラウザのバージョンとセキュリティ設定、インストールされているプラグインとそのバージョンという、互換性に関する一般的な問題が懸案事項となります。従来型アプリケーションの場合、企業は新しいバージョンにアップグレードするタイミングを決定することができます。このことは、新しいバージョンで最新のブラウザが必要となる場合に特に重要です。一方、アプリケーションが外部アプリケーションの場合、企業がこのタイミングを決定できるとは限りません。

　サービスのクライアントがブラウザ ベースでない場合、展開と実装 ( 互換性テスト、展開プランニング、ロールアウトなど) は、内部の IT 部門の責任となります。

　サービスがアタッチ サービスまたはビルディング ブロック サービスの場合は、企業のデータ センターのバックエンド インフラストラクチャまたはクライアント、あるいはその両方を展開することが必要です。バックエンド展開の場合は、通常、次のような非機能的な疑問が生じます。どの程度の容量のサーバー、ネットワーク、およびストレージが負荷を満たすために必要となるか。既存の SQL Server や Web サーバー ファームなどの共有サービスを使用できるか。回復性と障害復旧はどのように提供されるか。複数のデータ センターで実行できるか。これらの疑問に対する答えは、クラウド内のアタッチ サービスより、アプリケーションのローカル コンポーネントに依存するところが大きくなります。要するに、通常のバックエンド展開と同様に取り組むことが可能です。

●プロバイダ業務/ ビジネス継続性

　サービス プロバイダの選択、監視、および評価にあたって、SLA の内容にばかり注目することは陥りやすい間違いです。それよりも、SLA の達成方法の方が重要な考慮事項です。障害発生から 24 時間以内のサービス復旧を約束する SLA は、充実して見えますが、障害と復旧形態がどのように定義されているかがきわめて重要です。サービス コンシューマにとって、障害は、アプリケーションからレコードが不慮に削除されることを意味しても、サービス プロバイダの見方が同じであるとは限りません。この例をさらに掘り下げてみましょう。アプリケーション データを復元するというプロセスは、多くのビジネス アプリケーションにとって複雑なプロセスです。たとえば、1 つのExchange メールボックスやメッセージ、または 1 つの Sharepoint サイトやドキュメントを復元することは、成熟前のビジネス アプリケーションにとって大いなる難題です。この難題をマルチテナント型の SaaS アプリケーションに当てはめてみましょう。仮に細分化された復元が可能な場合でも、プロバイダは運用コストを理由に、復元に消極的になるでしょう。

　複数のアーキテクトから寄せられているもう 1 つの懸案事項に、サービス プロバイダが倒産するか、競合他社への移行を防ぐためにデータが拘束されるのではないかというリスクがあります。アプリケーション コードをエスクローに入れることは正しい措置ですが、十分ではありません。エンタープライズ コンシューマがデータを取得できると仮定しても、インストール手順がわからず開発者に相談できない状態で、企業のデータ センターでアプリケーションを再構築することはできないかもしれません。これに対する解決策はまだなく、最悪の事態が発生した場合にプロバイダが正しい行いをすると信頼できるかどうか、プロバイダに的確なビジネス/ 経営スキルがあることを信頼できるかどうかにかかっています。

●レポート作成

　どの SLA もそうであるように、ビジネス部門と IT 部門は、パフォーマンスに関するレポートをレビューして、SLA が満たされていない箇所を調査する必要があります。

運用に関する考慮事項の要約

新規アプリケーション向けの第一線のトラブルシューティングを実行するには、ヘルプ デスクの処理手順を更新する必要があります。また、サービス プロバイダと共にエスカレーション プロセスを定義する必要があります。 内部ヘルプ デスクの SLA をレビューし、エスカレーション対象のサポートについてサービス プロバイダに依存した場合も、SLA を満たすことができることを確認します。

INDEX
	［アーキテクチャ・ジャーナル］
	「SaaS」と「ソフトウェア＋サービス」は何が違うのか？
	1．ソフトウェア＋サービスの背景
	2．ソフトウェア サービスにおける課題（識別情報とアクセス管理）
	3．ソフトウェア サービスにおける課題（データ、運用）
	4．ソフトウェア サービスにおける課題（規制と法的義務）／まとめ

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）