Gianpaolo Carraro
Fred Chong

Microsoft Corporation

October 2006
日本語版最終更新日 : 2007 年 1 月 9 日

適用対象:
   SaaS (Software as a Service)

要約: SaaS (Software as a Service) シリーズの第 3 回の記事では、コンシューマとしての企業の観点から SaaS について説明します。この記事には英語のページへのリンクも含まれています。

目次

はじめに
SaaS について
SaaS を利用するメリット
SaaS の連続体
SaaS の採用に関する問題点
サービス中心の IT
SaaS が IT に及ぼす影響
統合アーキテクチャ
複合アーキテクチャ
SaaS プロバイダになる
まとめ
謝辞
追加の資料およびフィードバック

はじめに

SaaS (Software as a Service) は、IT (インフォメーション テクノロジ) 部門の企業のその他の部門に対するかかわり方、およびこれらの部門にコンピューティング サービスを提供する役割に対する考え方に変化をもたらす可能性があります。効率的なソフトウェア配布メカニズムとしての SaaS の出現は、IT 部門の主な役割をアプリケーションの展開とサポートから、アプリケーションが提供するサービスの管理へと切り替えるきっかけとなります。サービス中心に転じた IT では、内部ソースと外部ソースの両方からサービスを取り入れ、企業の目標に正確に一致させることで、企業に多くの価値を直接にもたらすことに成功しています。

この文書は SaaS シリーズの第 3 回の記事です。最初の 2 つの記事では、SaaS アプリケーションの開発と顧客への提供について詳しく説明しています (参照するには ここをクリック (英語) してください)。今回は、問題の見方を変えて、コンシューマとしての企業の観点から SaaS について説明します。具体的には、サービス ポートフォリオに SaaS アプリケーションを追加することでどのようなメリットを得ることができるか、外部でホストされたアプリケーションを企業のコンピューティング環境に追加した場合の影響、SaaS のためにどのような準備が必要かについて説明します。この記事では、これらの点に加えて、IT 部門がコンシューマであると同時に SaaS プロバイダになることが有意義であると見なされるいくつかの特殊なケースについて説明します。

SaaS について

簡単に言うと、SaaS は、"ホストされたサービスとして展開され、インターネット上でアクセスするソフトウェア" と定義できます。

SaaS の概念は、"パッケージされた" アプリケーションをインターネット経由でビジネス ユーザーに提供していた 1990 年代のアプリケーション サービス プロバイダ (ASP) に関連していると考えることがよくあります。これらの初期のインターネットでのソフトウェア配布の試みは、ライセンスやアーキテクチャなどのいくつかの点で、最新の SaaS アプリケーションよりも従来のオンプレミス アプリケーションと共通する点が多数ありました。これらのアプリケーションは最初からシングルテナント型アプリケーションとして構築されているので、他のアプリケーションとデータや処理を共有する機能は限られており、ローカルにインストールされたアプリケーションと比較して、経済的なメリットが少ない傾向にありました。

今日の SaaS アプリケーションでは、シングルインスタンスのマルチテナント型アーキテクチャによる一元化のメリットが得られ、同程度のオンプレミス アプリケーションに匹敵する機能豊富なエクスペリエンスを提供します。一般的な SaaS アプリケーションは、ベンダーが直接に提供する場合と、アグリゲータと呼ばれる仲介者が、さまざまなベンダーの SaaS をバンドルし、統合アプリケーション プラットフォームの一部として提供する場合があります。

オンプレミス ソフトウェアでは、1 回限りのライセンシング モデルが一般的ですが、SaaS アプリケーションへのアクセスは、サブスクリプション モデルを使用して販売されることが多く、アプリケーションの使用料金を顧客が払い続けるという形式で提供されます。料金体系はアプリケーションごとに異なります。均一料金でアプリケーションの一部またはすべての機能を無制限に利用できる場合もあれば、使用量に基づいて料金を請求される場合もあります。

技術面では、SaaS プロバイダが、アプリケーションとデータを一元的にホストします。アプリケーションの修正プログラムや更新プログラムは透過的に展開され、エンド ユーザーはブラウザまたはスマート クライアント アプリケーションを使用してインターネット上でアクセスできます。多くのベンダーは、アプリケーション プログラミング インターフェイス (API) を通じて開発者にアプリケーションのデータや機能を公開しており、開発者はこれらを使用して複合アプリケーションを作成できます。データの転送および保存では、機密データの安全を守るため、さまざまなセキュリティ メカニズムを使用できます。アプリケーション プロバイダが提供するツールを使用して、顧客がデータ スキーマ、ワークフロー、およびアプリケーションの運用に関するその他の要素を使い方に応じて変更できる場合もあります。

SaaS を利用するメリット

IT インフラストラクチャに SaaS を追加できるからと言って、それだけでは SaaS を利用する理由にはなりません。有効な業務上の理由が必要です。SaaS の利用は、すべての規模の企業に対して、ソフトウェアを取得するリスクを回避し、企業の IT 部門を受身的なコスト センターから積極的に価値を生み出す部門に切り替えるきっかけを与えます。

ソフトウェアを取得するリスクの管理

以前は、ERP や CRM アプリケーション スイートなどの大規模なビジネス クリティカルなソフトウェア システムを展開するのは、企業にとって一大事でした。大企業がこれらのシステムを展開するには、数十万ドルのライセンス コストを前払いで負担し、通常では、アプリケーションのカスタマイズおよび企業のその他のシステムやデータとの統合のため、多数の IT 担当者およびコンサルタントが必要になります。この規模の展開には多くの時間、人材、および予算が必要となるため、すべての規模の企業にとって大きなリスクとなります。また、小規模の企業では、このリスクがなければ、ソフトウェアから多くのユーティリティを得ることが可能ですが、このようなソフトウェアには手が届かない場合がほとんどです。

オンデマンドの配布モデルにより、この状況が一部変更されます。SaaS アプリケーションでは、クライアントの場所に大規模なインフラストラクチャを展開する必要がないため、前払いによるリソースへの投資がなくなるか、少なくとも大幅に削減されます。初期の大きな投資を償却する必要がないため、SaaS アプリケーションを展開して望ましくない結果が生じた場合でも、企業は高価なオンプレミス インフラストラクチャを廃棄することなく、アプリケーションの使用を中止して別の方向に進むことが可能です。

さらに、カスタム統合が不要な場合は、極めて少ない作業とロールアウト アクティビティで SaaS アプリケーションを計画および実行でき、主要な IT 投資に対して非常に短期間で価値を生み出すことが可能です。また、多くの SaaS ベンダーは、リスクなしで (多くの場合は完全に無償で) ソフトウェアの "テスト ドライブ" を約 30 日間という期間限定で提供することが可能になりました。ソフトウェアを購入する前に試用する機会を見込み客に提供することで、ソフトウェアの購入にかかわる多くのリスクを回避できます。

SaaS が企業にもたらすメリットの詳細については、MSDN ライブラリの「 Architecture Strategies for Catching the Long Tail (英語) 」を参照してください。

IT が取り組む問題の管理

SaaS では、アプリケーションの展開や日々のメンテナンスをプロバイダが担当します。具体的には、修正プログラムのテストとインストール、更新プログラムの管理、パフォーマンスの監視、高い可用性の確保などの作業があります。第三者にこれらの "管理" 作業の責任を負わせることで、IT 部門では企業の事業目標に一致する価値の高いアクティビティに全力で取り組み、サポートすることが可能になります。運用業務への対応を主として作業する代わりに、CIO (最高情報責任者) および IT スタッフは、会社のその他の部門の技術戦略家として有効に機能することが可能になり、他の部門と連携してビジネス ニーズを理解し、目的を達成するための最善の技術の使用方法についてアドバイスを提供できます。IT 部門は、SaaS によって不要になるどころか、これまで以上に企業の成功のために直接に貢献する機会を得られます。

SaaS の連続体

"純粋" な形式の SaaS では、プロバイダがアプリケーションを集中管理し、代金と引き換えに複数の顧客にインターネット経由でアクセスを提供します。ただし、実際には、オンプレミス アプリケーションと SaaS アプリケーションの特質は二者択一的でなく、ソフトウェアのライセンス、場所、および管理方法という 3 つの異なる次元に沿って段階的に変化していきます。これらの特質は、一方の端に従来のオンプレミス ソフトウェアを持ち、もう一方の端に純粋な SaaS を持つ 1 つの連続体として視覚化できます。この中間に、両方の要素を組み合わせたその他のオプションが存在します。

図 1. SaaS アプリケーションは、異なる 3 つの連続体での概念的な位置によって区別されます。

• ライセンス: 通常、オンプレミス アプリケーションでは、ユーザーまたはサイトごとに 1 回の前払いの費用で永久にライセンスが供与され、また、カスタム ビルドのアプリケーションの場合は完全な所有権を得ます。多くの場合、SaaS アプリケーションは使用量ベースのトランザクション モデルでライセンスされ、顧客は使用したサービス トランザクション数に対してのみ請求されます。この中間に、よく知られている時間ベースのサブスクリプション モデルがあります。顧客は、1 か月または四半期などの特定期間ごとに 1 シートあたりの均一料金を支払うことで、その期間中にサービスを無制限に使用できます。
• 場所: SaaS アプリケーションは SaaS ホストの場所にインストールされ、当然ながら、オンプレミス アプリケーションは自社の IT 環境内にインストールされます。この中間に、アプライアンス モデルが存在します。このモデルでは、ベンダーがハードウェアやソフトウェア コンポーネントを "ブラック ボックス" として提供し、これをベンダーの場所ではなく、各社の場所にインストールします。この意味でのアプライアンスの例としては、キャッシュ付きの定期的に更新されるデータベースを持つ物流アプリケーションを含むデバイスがあります。運送会社は、大口の顧客にこのようなデバイスを提供することがあります。顧客は、毎日数千件の個別の問い合わせを運送会社のサーバーに対して実行することなく、このデバイスに対して出荷情報を問い合わせることが可能になります。
• 管理: 従来は、IT 部門がユーザーへの IT サービスの提供を担当します。つまり、IT 部門はネットワーク、サーバー、およびアプリケーション プラットフォームを熟知し、サポートとトラブルシューティングを提供し、IT セキュリティ、信頼性、パフォーマンス、および可用性の問題を解決します。これはたいへんな仕事であり、一部の IT 部門では、IT 管理に特化したサードパーティ サービス プロバイダにこれらの管理上の任務を請け負わせることがあります。スペクトラムのもう一方の端にある SaaS アプリケーションは、ベンダーまたは SaaS のホスト業者によって完全に管理されます。実際、管理タスクおよび管理責任の実装は、コンシューマに対して不透明です。サブスクライバに対する品質、可用性、およびサポートの義務は、サービス レベル合意書 (SLA) によって規定されます。

SaaS の採用に関する問題点

図 2 を指針として使用し、各連続体に対して企業のニーズおよび期待を示すことで、特定のアプリケーションまたは機能の SaaS 性向を確認できます。

図 2. 各連続体は、従来のアプローチ、SaaS、およびハイブリッド アプローチを表す 3 つの部分に分割できます (クリックすると拡大画像が表示されます)。

右側の列の 3 つのボックスのすべてに当てはまる場合は、SaaS への移行を検討する段階です。左側の列の 3 つのボックスのすべてに当てはまる場合、このアプリケーションに関しては従来のオンプレミス ソリューションを続行した方がいいことを表しています。その他の組み合わせの場合は、ハイブリッド アプローチが適切であることを表している可能性があります。市場を調べて、適切なソリューションを探求してください。

各連続体で適切な位置を見つけるには、さまざまな問題を検討する必要があります。最終的に、すべての問題は制御とコストの対立に要約されます。ここでは、アプローチの選択を左右するいくつかの問題について説明します。

• 政治的な問題: 企業の内部からの反対によって、意思決定が妨害されることがあります。重要な人物が、特定の機能を IT の管理下で社内で処理すると主張した場合、他の問題は重要視されません。テスト ドライブを展開すると、リスク嫌いの上司を説得して試験的なプロジェクトが承認される場合もあります (前述の「ソフトウェアを取得するリスクの管理」を参照)。
• 技術の問題: 通常、SaaS アプリケーションは、顧客が構成できるようにいくらかの柔軟性を備えていますが、これには限界があります。運用およびサポートに特殊な技術が必要となる重要なアプリケーション、または SaaS ベンダーが提供できないカスタマイズの必要なアプリケーションでは、SaaS ソリューションを利用できない可能性があります。

  また、定期的にアプリケーション間で転送されるデータの種類および量も検討の対象になります。企業 LAN でよく使われているギガビット イーサネット リンクと比べて、インターネットの帯域幅は細いため、企業のサーバー ルーム内のサーバー間では数分で転送される場合でも、全国に展開された SaaS アプリケーションとの間では数時間かかる場合があります。このため、ネットワーク遅延を考慮に入れてソリューションを検討するのは有意義なことです。たとえば、アプライアンス ベースのソリューションでは、キャッシュや一括処理が可能な場合もあります。

• 財務の問題: 同等のオンプレミス アプリケーションと比較して、SaaS アプリケーションの総所有コスト (TCO) を検討します。通常、SaaS からソフトウェア機能を取得する場合、オンプレミス アプリケーションと比べて初期費用は安く済みますが、長期的な費用はあまり明確ではありません。SaaS アプリケーションの TCO に影響を与える要素には、ライセンス ユーザー数、SaaS アプリケーションを企業のインフラストラクチャと統合するために必要なカスタム構成の量、既存のデータ センターにスケール メリットが備えられ、SaaS による節約効果をそれほど期待できない場合などがあります。

  また、実装したばかりの高価なアプリケーションを SaaS に置き換える場合は、満足できる投資収益 (ROI) を達成するまで SaaS の実装を延期する場合もあります。

• 法的な問題: 世界各地のさまざまな法律により、規制の対象となる業種もあります。SaaS ソリューションの候補によっては、各種の報告書や記録管理の要件を満たすことができない場合もあります。企業が営業活動を行っているさまざまな管轄区域の規制環境を調べ、アプリケーション ニーズへの影響を検討します。

  技術や財務の問題が、法律上の問題に影響を与える場合もあります。たとえば、SaaS プロバイダの候補によって、データのセキュリティおよびプライバシーに関する内部基準が満たされるかどうかを検討します。顧客やその他の関係者に対する法的義務を調べ、SaaS によりこれらの義務を引き続き果たすことが可能かどうかを検討します。

サービス中心の IT

これまでは、SaaS のメリットをビジネスや技術の観点から詳しく説明してきました。結局、このメリットを大きく左右する要素は、SaaS がサービス中心の IT モデルを導くための適切なインセンティブを備えているかどうかという事実です。

この数十年間に IT が企業で果たした革新的な役割を調べると、過去の平凡な記録管理や計算タスクから、今日の企業を差別化するワークフローや通信の合理化へと、技術が進化していることがわかります。

図 3. サービス中心の IT モデルの成長 (クリックすると拡大画像が表示されます)

図 3 は、企業が技術を調達し、さまざまな機能を活用して成長する一般的なモデルを示しています。

初期の段階で、企業が技術の導入を検討するとき、企業では一般に、ソリューションのニーズを限定された機能を提供する特定のアプリケーションと結び付けて考えます。たとえば、ハードウェア コンポーネントの設計についてパートナーと通信する必要がある場合は、共同作業と通信のための主要なツールとして簡単な電子メール アプリケーションで満足する場合があります。

特定のビジネス ニーズを 1 つのアプリケーションだけではなく、関連アプリケーションの集合によって満たすことが最善であると企業が認識するようになると、サービス中心の視野を取り入れたアプリケーション ポートフォリオの導入へと進化します。前述のパートナーとの通信の例では、バージョン管理、スレッド式ディスカッション、リアルタイムのホワイトボード、スライド プレゼンテーションなどをサポートするドキュメント共有機能を利用できる Web ポータルにより、共同作業の拡張が可能であることを認識します。その結果、ポータル ソリューションを購入および展開し、共同作業のために現在の電子メールだけの IT サービス機能を拡張する場合があります。

SaaS 配布モデルが提供するプラットフォームおよび基幹業務アプリケーションが増加すると、企業は多数のベンダーの選択が可能になっただけでなく、アプリケーションを提供する場所および方法についてもさまざまな選択肢が提供されるようになります。前述のとおり、SaaS は企業のリソース割り当てに対して、ライセンス、運用、管理などのさまざまなモデルを通じて影響を与えます。賢明な企業は、サービス実装の詳細に対する直接制御と引換えに、追加の柔軟性を導入して、基幹事業の戦略を最適化し、目標を達成することが可能になります。ただし、企業が SaaS を利用できる範囲は、どれだけのリスクを制御および軽減できるかに直接関係しています。また、サービス レベル合意書をよく理解することが、リスク管理ゲームの重要な部分を占めます。したがって、ファイアウォールを越えた IT のサービス ポートフォリオの境界の拡張は、サービス中心の IT によって、企業および技術がさらに高度になることを象徴しています。

サービス中心の IT の一部として SaaS を採用した企業では、リスクの軽減を超えて、オンプレミスおよび "雲の中" のサービスのポートフォリオを通じて公開された機能およびデータを使用して、企業の利益を最大化することを学ぶ必要があります。異種のシステムによって処理されたビジネス データがクリーンで一貫性があり、安全であることの確認は、一般に、ビジネスに有効な IT を構築するための基本ステップです。統合技術を使用すると、データの変換およびプロセスの編成により、この基盤を備えることが可能になります。これは定評のあるレストランでよく実施されている下準備の作業に類似しています。それは、最高のシェフが調理する最終的な "レパートリー" に備えて、ニンニク、ハーブなどの食材を適切な大きさに切って準備しておくことです。同様に、効率的な統合アーキテクチャは、アップストリームの複合アプリケーションでのユーザーの利用に備えて、企業の情報資産を統合および整理します。複合アプリケーションのコンピューティング構造により、ビジネス機能および情報は、エンド ユーザー向けに効率的に構成 (または加工) されます。複合アプリケーションを使用すると、エンド ユーザーは実際の情報源に気付くことなく (また気付く必要なしに)、技術関連のコンテキスト スイッチを最小限に抑えてビジネス情報の統合および分析に集中できます。

成長モデルを要約すると、次のようになります。

• レベル 1 (左上) では、孤立したアプリケーションの集まりによって、初歩的な方法で企業のユーザー ニーズを満たしています。
• レベル 2 (右上) では、すべての機能を備えた関連アプリケーションから成るサービス ポートフォリオにより、企業のユーザー ニーズへの対応が向上しています。
• レベル 3 (左下) では、サービス ポートフォリオが最適化されています。サービス ポートフォリオが、SaaS プロバイダからの追加のオプションによって強化され、企業の IT 戦略およびコスト配分をさらに最適化するための意思決定が可能です。
• レベル 4 (右下) では、"雲の中" のサービスおよびオンプレミス サービスがシームレスに統合され、業務に正確に一致したアプリケーション構成のプラットフォームを提供しています。

この記事の最後にある 2 つの項では、企業のコンピューティング戦略への SaaS の取り込みに対して、統合および複合アーキテクチャが果たす重要な役割について詳しく説明します。その前に、次の項では、サービス中心の企業で、SaaS が IT の管理および役割に及ぼす影響について説明します。

SaaS が IT に及ぼす影響

SaaS の利用が決定したら、次のステップでは、SaaS の展開による既存 IT 資産への影響を評価し、移行を円滑に実行できるように対策を講じて、移行のための準備を行います。

IT 管理に対する影響

適正評価は、成功するすべての IT インフラストラクチャ展開プロジェクトで実施されている一般的な作業であるため、基本をよく理解している必要があります。ただし、一部の要素には特別な配慮が必要です。適正評価チェックリストで取り扱う項目を次に示します。

• データ セキュリティ基準: 重要なビジネス データを "外部" に移動すると、データの損失や機密情報の漏洩などのリスクを伴います。データ セキュリティ ニーズを評価し、プロバイダで設定されている対策が、企業の基準を満たしているかどうかを確認します。
• SLA の保証: 企業と SaaS プロバイダ間の管理契約は、サービス レベル合意書 (SLA) の形式をとり、この合意書により、SaaS ベンダーが提供するパフォーマンス、可用性、およびセキュリティ レベルが保証されます。また、これらの保証内容を満たすことができなかった場合にプロバイダがとる処置、またはプロバイダが提供する補償についても規定しています。SLA が適切であり、保証内容が企業のニーズを満たしていること、および最悪のシナリオでも十分な軽減レベルが提供されることを確認してください。
• 移行の戦略: ある時点で、SaaS アプリケーションから別のソリューションへの移行が必要になる場合もあります。したがって、アプリケーションから既存データを取り出して別のアプリケーションに移動できることが重要となります。SaaS プロバイダ候補が使用しているデータ移行戦略および手順を、データおよびコード エスクローに対する規定も含めて、プロバイダに問い合わせます (移行データの準備については、この記事の「統合アーキテクチャ」を参照してください)。
• 社内の統合要件: SaaS への移行によって、企業で設定されている機能およびデータ統合に関する要件が満たされることを確認します。統合シナリオについては、この記事の後半で詳しく説明します。
• レポート サービス: SaaS では、一部のデータに対する直接制御を断念しなければならないため、正確かつ有効なレポート機能が特に重要です。プロバイダがどのようなレポート サービスを提供しているかを調べ、自社のビジネス インテリジェンス要件に適合しているかどうかを確認します。

IT の役割および責任に対する影響

前に説明したように、企業の IT 構成に SaaS を追加すると、IT 部門の情報サービス プロバイダとしての役割に根本的な変化をもたらします。部署は変化を恐れていると風刺されることがありますが、IT 部門も組織の影響を受けずにいられません。企業の SaaS に対する抵抗は、社内の他の部門と同じように簡単に IT 部門から起こる可能性があります。以前、ソフトウェアを展開する立場にあった CIO (最高情報責任者) とそのスタッフは、ソフトウェアの展開の提案に対して、データ センターではホストできないと主張することで、ソフトウェアの展開を簡単に拒否することが可能な門番の役割を果たしていました。SaaS という選択肢の出現により、データ センターの制御は、必ずしも企業全体のコンピューティング環境の制御を意味するものではなくなり、門番が制御の喪失に対する不安を抱く可能性があります。"意地の悪い" 部長は、IT 部門を完全に無視して、自分の部署のために SaaS アプリケーションにサブスクライブすることが可能になります。

当然ですが、より大きなコンピューティング環境を制御するためにデータ センターの制御に依存している CIO は、いずれにしても管理の問題を抱えることになります。成功した CIO は、各部署と協働し、特定の購入がその部署の将来に及ぼす影響について説明し、オンプレミス ソフトウェアまたは SaaS のどちらによって部署のニーズが最適に満たされるかを共同で判断します。前に説明したように、このコンサルタントの役割を果たし、各部署に最適な技術を提案することで、IT 部門は企業の価値を直接に高めることが可能になります。

法規制の順守に対する影響

監査基準書 70 号 (SAS 70) は、国際的な監査基準であり、他の企業にサービスを提供している事業は、自己の内部統制について独立監査人による信頼できる報告書を受領できます。SAS 70 監査は独立監査人によって実施され、監査の結果はSAS 70 報告書に記述されます。サービス プロバイダがこの報告書を顧客に提供することにより、客先の企業が監査を受ける場合はこの報告書を使用できます。SAS 70 は法律ではありませんが、世界各地のさまざまな管轄権の監査基準および情報公開基準 (米国のサーベンス オクスリー法など) により、最新の SAS 70 報告書は、他の企業にサービスを提供している事業にとって "事実上の" 要件となっています。すべての SaaS プロバイダは、検査時にすぐに利用できるように報告書の作成を検討する必要があります。

SAS 70 は検定ではなく、企業が満たすべき最小限の基準を指示するものではありません。SAS 70 報告書には、企業の内部統制が記述されるだけであり、基準を満たしているかどうかの判定は提供されません。したがって、適正評価では、SaaS プロバイダ候補に SAS 70 報告書を要求するだけでなく、プライバシー、データ セキュリティなどの社内基準にプロバイダが対応できるかどうかを詳しく調べる必要があります。たとえば、地域のプライバシー法により、顧客の個人的な財務データを常に暗号化して保存する必要がある場合は、プロバイダのデータの保存方法が記述された SAS 70 報告書によって、この法律を順守できるかどうかを確認できます。

SAS 70 の詳細については、 American Institute of Certified Public Accountants の Web サイト (英語) をご覧ください。

統合アーキテクチャ

SaaS アプリケーションにサブスクライブすると、制御されたローカル ネットワークの外部にあるインターネットの "雲" の中に業務データが格納されます。"統合アーキテクチャ" では、この外部データを企業の論理インフラストラクチャに取り込む方法を指定します。これにより、社内または社外でホストされたコンポーネントかどうかにかかわらず、インフラストラクチャ コンポーネント間の相互運用が可能になり、また、データの取得先にかかわらず、各コンポーネントが必要なデータにアクセスできるようにします。

ほとんどの場合、SaaS アプリケーションを実装するには、1 つ以上の既存アプリケーションまたはデータ リポジトリから新しいシステムへのデータの転送が必要になります。次に一般的なシナリオを示します。

• オンプレミス ソースからの既存データにより、SaaS アプリケーションを "ブートストラップ" します。
• 機能の一部がオンプレミス ソースから出力されるデータに依存するように SaaS アプリケーションを構成します (たとえば、CRM アプリケーションがオンプレミスの在庫管理アプリケーションによって管理されている在庫データを参照する場合)。
• 機能の一部が SaaS アプリケーションから出力されるデータに依存するようにオンプレミス アプリケーションを構成します (たとえば、オンプレミスの給与アプリケーションが SaaS の人事管理アプリケーションによって管理されている人事データを参照する場合)。

ただし、多くの場合、企業環境内への SaaS アプリケーションの統合では、処理を円滑に行うために SaaS アプリケーションと 1 つ以上の社内アプリケーション間でのデータの同期化と移動を必要とするデータの依存関係を作成します。データの移動およびシステムの統合には、統合ブローカーを使用します。

統合ブローカー

多くの企業では、アプリケーション機能の公開、ビジネス プロセスの編成、および内部バックエンド システムとの統合に、いずれかの種類の統合ブローカーを既に使用しています。多くの場合は、同一の統合ブローカーをカスタマイズおよび構成して、SaaS アプリケーションを含め、社内および社外のさまざまなデータ ソースの統合およびルーティングを実行できます。

図 4. 統合ブローカーは社内および社外のデータ ソースを統一化します (クリックすると拡大画像が表示されます)。

異なるプロトコルを使用し、互換性のないさまざまな形式を使用した異なるソースから生じたデータを使用できます。統合ブローカーの仕事は、さまざまなソースからデータを受け取り、データの処理方法およびルーティング先を決定し、送り先システムが使用できる形式でデータを目的の場所に送信します。ブローカーはパイプライン アーキテクチャの形式をとり、特定の統合処理を実行するモジュールの追加および削除が可能となっています。複数の論理パイプラインを使用して、異なる方向に移動するデータを処理できます。一般的な例を挙げると、1 つのパイプラインを使用してインターネット上のソースから受け取ったデータをローカル データ ソースと統合し、別のパイプラインを使用してローカル データを受け取ってインターネット上の SaaS データと統合できます。

パイプラインのデータは、データ ソースとの通信に使用するプロトコルを定義したデータ チャネルを通じて送信されます。たとえば、SOAP を使用して特定の Web サービスからブローカーにデータを送信するチャネルと、FTP を使用してブローカーから SaaS アプリケーションにデータを送信する別のチャネルを設定できます (データ転送の詳細については、この記事で後述の「データ転送パターン」を参照してください)。

パイプラインに挿入されたモジュールは、データの処理方法、ルーティング方法、および送り先でのデータの統合方法を決定します。各モジュールは、メタデータ サービスに指定された構成可能なルールを使用して処理を実行します。一般的な統合には次の処理が含まれます。

• セキュリティ: 通常、受け取ったデータはセキュリティ モジュールで処理されます。セキュリティ モジュールでは、データ ソースまたはデジタル署名の認証、データの暗号化解除、ウイルスなどのセキュリティ リスクに対する検査などが行われます。セキュリティ操作は、アクセスを制御する既存のセキュリティ ポリシーと連携できます。
• 検証: 検証モジュールは、データを関連スキーマと比較し、適合しないデータがあると、そのデータを拒否するか、変換コンポーネントに渡して適切な形式に変換します (データ変換の詳細については、この記事で後述の「データ変換パターン」を参照してください)。
• 同期ワークフロー: 同期コンポーネントは、ワークフローとルールを使用して、データの送り先にデータの変更を適用する方法、およびその順序を決定します。いずれかのワークフロー シーケンスを正常に完了できなかった場合は、トランザクションまたは補正ロジックを使用してデータ転送を正常に "アンワインド" できるため、異なるシステム間でのデータの整合性が保証されます。
• ルーティング: 最後に、ルーティング ルールは各データの送り先を定義します。単純にすべてのデータを特定のソースから指定された場所に転送するだけの場合もあれば、顧客の ID 番号などのコンテンツ情報から送り先を判定するなど、複雑なロジックを含む場合もあります。

データの可用性サービスは、新しいデータが利用可能になったとき、統合ブローカーがそれを検出するための手段を提供します。データの可用性を確認するための方法については、次の「データの可用性パターン」を参照してください。

データの可用性パターン

データを同期化するには、定期的またはイベントによって起動されたときに、新規データおよび変更されたデータをソースからターゲット (データ シンク) に転送する必要があります。ローカル ソースと SaaS アプリケーション間のデータの同期処理を起動するには、次の 3 つのパターンを使用します。

• ポーリング: "ポーリング" では、通常は定期的に、一方のソースが他方に問い合わせを実行して変更がないかどうかを確認します。
• プッシュ: プッシュでは、ポーリングと逆の操作を行います。"プッシュ" 関係では、変更されたデータを持つソースが、データ シンクに対して変更を伝達します。データ ソースは、データ ソースのデータが変更されたとき、または定期的に、プッシュを開始できます。
• パブリッシュとサブスクライブ: イベント ベースの "パブリケーションとサブスクリプション" は、ポーリングとプッシュの両方の要素を結合したハイブリッド アプローチです。データ ソースに変更が加えられると、データ ソースが変更通知イベントをパブリッシュし、それをデータ シンクがサブスクライブします。

適切なアプローチはデータごとに異なり、単一のアプリケーションに対して複数のアプローチの組み合わせを適用する場合もあります。データの変更を検出するための適切なアプローチは、データの変更をリアルタイムまたはほぼリアルタイムに反映する必要があるかどうか、更新データとの統合が必要なデータ シンクの数など、さまざまな要素によって決まります。場合によっては、妥協案を模索して利害の対立を調整することもあります。たとえば、通常、プッシュ アプローチは、常に最新の状態で維持する必要があるデータに最適ですが、多数の関連ソースへデータをプッシュすると、コンピュータおよびネットワークに負荷がかかり、アプリケーションのパフォーマンスが低下することがあります。どのアプローチを選択する場合でも、ポーリング間隔やシンジケーション フォーマットなど、実装の詳細を管理する規則を作成する必要があります。

データ転送パターン

2 つのエンドポイント間のデータの転送には、同期または非同期通信技術を使用できます。"同期転送" は、インターフェイスに類似しています。つまり、どちらか一方で情報が必要になると、結果をすぐに受信できることを期待して、他方に接続して情報を要求します。この接続は、さまざまな方法で行われます。同期転送では、簡単なファイル転送を使用することも、FTP、HTTP、またはその他の方法を使用することもできます。

"非同期転送" では、送信者による情報の転送と受信者による処理が、別々の時間に発生します。通常、非同期転送は、メッセージ ベースで行われます。即座の応答を期待せずに、相手側にメッセージを送信して情報を要求します。第二者が要求を処理し終わると、別のメッセージで第一者に返信します。メッセージの送信には、SMTP などの電子メール プロトコル、またはメッセージ キュー技術を使用できます。

データ変換パターン

"データ変換" とは、あるソースからデータを受け取り、データ シンクで使用できるように形式やコンテンツを変更することです。SaaS アプリケーションとのデータ交換には、いくらかのデータ変換を伴う可能性があります。たとえば、既存のオンプレミス システムではデータ交換に EDIFACT 規格を使用しているが、統合先の SaaS アプリケーションでは互換性のない XML ベースの形式を使用してデータを送受信している場合があります。オンプレミス システムからのデータは、SaaS アプリケーションに送信する前に変換する必要があり、またその逆の変換も必要になります。

データの変換は、複数のステップから成るプロセスです。最初に、適切なデータ形式およびスキーマとの検証を行って、変換後のデータが使用に適していることを確認します。オプションとして、別のソースのデータと結合して高度なデータを作成することも可能です。最後に、データを送り先システムの形式に変換します。

データ統合パターンの詳細については、Microsoft patterns & practices Web サイトの「 Data Integration (英語) 」および「Integration Topologies (英語) 」を参照してください。

ID の統合

前述のとおり、ユーザーの観点からは、アプリケーションが物理的に企業ファイアウォールの内部または外部でホストされているかどうかは、問題ではありません。複数の場所にあるアプリケーションに、簡単かつ一貫性のある方法でアクセスできる必要があります。この一貫性のあるユーザー エクスペリエンスにとって重大なコンポーネントの 1 つは "シングル サインオン" です。ユーザーは、1 日の始まりに、Microsoft Windows オペレーティング システムにサイン オンするときにユーザー名とパスワードを入力し、それ以降は、リソースごとに個別に資格情報を入力せずに、アプリケーションおよびネットワークのリソースにアクセスできます。シングル サインオンは便利なだけでなく、ユーザーによって管理される資格情報が少なくなり、パスワードの損失や間違いなどのセキュリティ リスクが減少します。

IT 管理者および管理の観点から、シングル サインオンは、サポート スタッフが個別の資格情報のセットを管理する必要がないことを意味します。また、既存アプリケーションのアクセス ポリシーを SaaS アプリケーションのアクセス制御に再利用できるなど、他の面でも ID の統合を促進します。たとえば、あるポリシーで、特定の価格以下の購入をすべて承認する権限を持つ特定のマネージャが指定されており、SaaS アプリケーションでもその許可を認識できるようにする場合があります。ディレクトリ サービスを SaaS アプリケーションと統合すると、アカウントのセットアップ時に、ポリシー情報を手動でレプリケートする必要がありません。

SaaS アプリケーションでは、顧客独自の企業ユーザー ディレクトリ サービスに接続された顧客ネットワーク内のフェデレーション サーバーを使用して、シングル サインオン認証を提供できます。このフェデレーション サーバーは、SaaS プロバイダのネットワーク内に設置された対応するフェデレーション サーバーと信頼関係にあります。

エンド ユーザーがアプリケーションにアクセスしようとすると、企業フェデレーション サーバーがローカルでユーザーの認証を行い、SaaS フェデレーション サーバーとネゴシエートしてユーザーに署名付きのセキュリティ トークンを提供します。SaaS プロバイダの認証システムは、このセキュリティ トークンを承諾し、ユーザーにアクセスを許可するために使用します。

図 5. フェデレーション サーバーは、SaaS アプリケーションへのシングル サインオン認証を企業顧客に提供します (クリックすると拡大画像が表示されます)。

WS-Federation や Security Assertion Markup Language (SAML) など、リモート認証でよく知られている基準を使用するフェデレーション サーバーを実装すると、幅広い SaaS プロバイダとのシングル サインオンの実装プロセスを簡単に行うことが可能になります。

Microsoft では、ディレクトリ フェデレーションで使用する多数のリソースを提供しています。詳細については、「Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 (英語) 」および「Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 (英語) 」を参照してください。

複合アーキテクチャ

複合アプリケーションでは、ビジネスの機能および情報をエンド ユーザー向けに効率的に統合できます。優れた設計の複合アプリケーションは、企業に多くのメリットをもたらします。メリットには、冗長なデータ エントリの削減、人的交流の促進、未処理タスクとその状況を通知する機能の向上、関連のあるビジネス情報の視覚化などがあります。論理レベルで複合アプリケーションの原理を一般化すると、情報は単独のデータ ストリームとしてではなく、統合体として表示することにより、ユーザーにメリットをもたらします。統合により、ユーザーは異なるソースから得たデータがどのように関連し合っているかを理解でき、独自の "ドメイン インテリジェンス" (ビジネスおよびプロセスについてこれまでに蓄積した知識) を適用して、詳細な情報を得たうえで意思決定ができるようになります。また、優れた "プロセス インテリジェンス" の作成が可能になり、ユーザーは自分の作業および責任を正確に理解できるようになります。

病院の医師について考えてみます。1 日の流れの中で、医師は患者のケアに関するさまざまな情報を確認する必要があります。レントゲン写真、患者の病歴、処方せんおよび薬学情報、保険金の制限、保険省や疾病管理センターの広報、およびその他多数の情報があります。通常、これらの情報は個別のアプリケーションで管理されますが、医師にとっては非効率的です。ビジネス インテリジェンス (上記の情報など)、プロセス インテリジェンス (手術室のスケジュールや医師の診察を待っている患者の数など)、および同僚との相談を促進するコラボレーション ツールなど、これらすべての機能を単一のアプリケーションに統合すれば、病院、病院の関係者、および患者のために大いに役立ちます。

サービス中心の IT 部門では、アプリケーションおよびその他のリソースは構成要素となります。これらの要素を結合して、タスク集中型の "複合アプリケーション" を作成することで、"ビジネス インテリジェンス" と "プロセス インテリジェンス" を単一のパッケージとして提供することが可能になります。複合アプリケーションの作成は、簡単ではありません。必ずしも相互通信を目的として設計されていない異なるアプリケーション、プロトコル、およびテクノロジを結合し、シームレスに統合する必要があります。これを可能にするのが "複合アーキテクチャ" です。

図 6. 複合アーキテクチャは、異なる場所に置かれた種類の異なる多数のソースを利用するように設計されています。

複合アーキテクチャの下位レベルには、格納されたデータや処理済みのデータを "原料" として提供するソースがあります。これらのソースには、社内アプリケーション、社内データベース、SaaS アプリケーション、Web サービス、フラット ファイル、およびその他の多数のソースが含まれます。多くの SaaS アプリケーションでは、直接に使用可能な各種プロパティおよびメソッドを API で公開しています。

複合層では、生のデータをまとめ、統一された新しい形式でユーザーに提供します。この層の役割は、データをビジネス情報およびプロセス インテリジェンスに変換 (またはその逆の変換) を行うことです。

複合層は、アクセス、データ、ワークフロー、およびルールを管理する多数のコンポーネントで構成されています。アプリケーション、データベース、Web サービス、およびその他のリソースは、"サービス エージェント" を通じてこの層に "プラグイン" されます。サービス エージェントは、接続のネゴシエートや各サービスとのメッセージ交換の詳細を処理します。ID 管理コンポーネントは、ユーザー認証が適切に行われ、許可を与えられているかどうかを確認します。また、Web サービスと通信するための資格情報も管理できます。通常、この資格情報は、ローカル ネットワークへのアクセスで使用するものとは異なります。

複合層のデータ集約コンポーネントは、データ ソースの情報を受け取り、アプリケーション エンティティ モデルによって定義される方法で情報を変換します。たとえば、カタログ エンティティには、異なるシステムから取得したさまざまな製品情報と在庫情報が必要です。これらの情報は、統合された相関性のあるデータのセットとしてエンド ユーザーに提供されます。ワークフロー コンポーネントは、条件およびフローを使用して情報を整理し、ユーザーの操作や共同作業をガイドします。イベント メカニズムは、指定した条件が満たされたときに通知を送受信して、エンド ユーザーが適切に対応できるようにします。

ユーザー中心の層では、中央の統合されたタスク集中型のユーザー インターフェイスに、ユーザーのための複合データが表示されます。意思決定のための情報と操作を実行するための機能の両方を備えています。ここでは、サービス中心の IT の能力が最大限に活用されています。1 つのシステムの機能や制限ではなく、ユーザーのニーズに焦点を合わせて、複数のアプリケーションおよびデータ ソースの最高の要素を単一のアプリケーションにまとめています。

複合アプリケーションのビジネス、アーキテクチャ、およびテクノロジの詳細については、この記事ですべてを網羅することはできません。今度の「Architecture Journal Issue #10」に、このトピックの掘り下げた説明が掲載されます。

SaaS プロバイダになる

これまでは、企業が SaaS コンシューマになった場合のメリットについて説明してきました。場合によっては、専門の SaaS プロバイダになることで企業にメリットをもたらすこともあります。

企業がフランチャイズや小売業者などの依存エンティティを持ち、これらのエンティティと多くの取引を行っているが、IT 処理の自動化や情報の伝達が劣悪な場合、この企業は SaaS プロバイダになることでメリットが生じる可能性があります。たとえば、フランチャイズ モデルにより運営されているファストフードのチェーン店について考えてみます。独立したフランチャイズ店がレストランの一部またはすべてを所有し、フランチャイズ本部との契約により、ブランド、レシピ、および必要に応じてストックやレンタル設備を使用しています。フランチャイズ店には、店舗内に衛生 IT インフラストラクチャを配置して維持するための人材も予算もないため、フランチャイズ本部とのほとんどの連絡は、昔からの方法で行われています。つまり、郵便、電話、支店での定例会議、またはその他の非技術的な方法を使用しています。本部とフランチャイズ店の間に優れた IT 関係を構築すれば、情報の伝達の円滑化、特定のプロセスの自動化が可能になり、サービスの品質が向上します。

ここが SaaS の活躍のしどころです。SaaS プロバイダになると、本部では、フランチャイズ店のための特殊なアプリケーションのほか、在庫管理、会計、プロモーション、ロイヤリティ プログラム、およびその他のビジネス機能のアプリケーションもホストできます。通常のパーソナル コンピュータとブロードバンド接続があれば、世界各地のフランチャイズ店がこれらのアプリケーションにアクセスできます。これはすべての関係者にメリットをもたらします。この例では、フランチャイズ店は SaaS がなければ使用することができなかったアプリケーションを利用できるようになります。同様に、フランチャイズ本部では、フランチャイズ店がこれらのアプリケーションを使用することにより、有効なフィードバックおよびデータを受け取り、正確で価値のあるビジネス インテリジェンスを構築できます。

また、企業が高価な IT 資産を開発し、他の企業に提供することで金銭に転化できる場合は、SaaS プロバイダになることを検討することができます。たとえば、社内用の高度な不正検出システムを開発した銀行では、このシステムの商用バージョンを開発して、SaaS アプリケーションとしてサブスクリプション用に提供できます。企業がインターネットの雲からサービスを利用できるのと同様に、企業は雲に対してサービスを提供することもできます。

まとめ

企業は、IT サービス ポートフォリオに SaaS を追加することで得られる柔軟性やリスク管理のメリットについて検討することをお勧めします。統合および複合は、アーキテクチャ戦略の重要なコンポーネントであり、これらを使用することで、SaaS をサービス中心の IT インフラストラクチャの完全な一部分として組み込むことが可能になります。

最後に、将来の企業のコンピューティング環境は、純粋なオンプレミスでもなければ、雲の中でもないと考えています。むしろ、陰と陽のように共生、調和していくと思われます。

謝辞

テクニカル ライティングでご支援いただいた Paul Henry に大いに感謝いたします。

追加の資料およびフィードバック

このトピックの詳細およびその他の多数の SaaS 関連のトピックについては、Fred Chong のブログ (英語) および Gianpaolo のブログ (英語) にアクセスしてください。この記事のフィードバックは、電子メールにて Fred Chong または Gianpaolo Carraro までお送りください。皆さまのご協力に感謝いたします。