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

■規制と法的義務

　規制や法的義務に対するコンプライアンスの実証は、インフラストラクチャに対する影響を伴います。また、内部システムと外部サービスの両方にまたがるビジネス プロセスの場合、コンプライアンスを確保することは特に難しくなります。同時にこのことは、コンプライアンス関連の潜在的なソリューションも提示しています。つまり、アプリケーションまたはサービスと業界との整合性がとれている場合は、主要市場における関連規制に準拠している可能性も高くなります。このことは、汎用サービスには当てはまらない場合があります。コンプライアンスがサービスのセールス ポイントである状況でも、企業内部のセキュリティ ポリシーや地域特有の法律 ( 欧州議会データ保護法など) は、サービス プロバイダのポリシーと矛盾する場合があります。

●データ所有権

　企業がビジネス データの所有権を常に保持したいと考えるのは当然であり、このことは、契約書に明記する必要があります。さらに、オンデマンドのデータ抽出が可能であることも確認するべきでしょう。

●プライバシー

　企業は、プロバイダが定めるプライバシー ポリシーと使用条件を精査して、データのプライバシーが確保されており、マーケティング目的で使用されたり、第三者に販売されたりしないことを確認する必要があります。このことは、完成型サービスが広告されている場合に特に重要です。プライバシー保護プログラムは、プロバイダの信憑性を判断する際に役立ちます。たとえば、プロバイダが TRUSTe ライセンシーになるためには、ポリシーを公開し、プライバシー原則へのコンプライアンスを確認するために独立機関からの監査を受けている必要があります。

法的義務に関する考慮事項の要約

コンプライアンスはサービス プロバイダにも拡大される場合があります。その場合にコンプライアンスをどのように実証するかを考慮することが重要です。 コンプライアンス レポートには関連コストがある場合があります。

識別情報と アクセス管理	・ フェデレーション サポートをプロバイダ選定基準に組み込むことを検討します。
	・ 複雑さを緩和し、コストを削減するための方法として、ロールベースの管理を調査します。
	・ 統合のビジネス ケースの基準は、コスト削減より、セキュリティの強化とコンプライアンスの達成に置く必要があります。
	・ フェデレーションや CardSpace などの識別情報管理テクノロジの導入に着手します。
	・ 将来のソフトウェア サービスの識別情報統合を簡略化するためのアーキテクチャを作成します。
データ運用	・ プロバイダ選定基準にオープン スタンダード (WS-* など) 要件を含めます。
	・ SLA 測定をサポートするためサービスの簡単な監視を促進します。
	・ データがプロバイダ側に常駐する場合は、ブリックレベルの復元が必要/可能かどうかを判別します。
	・ 正式な運用フレームワーク (MOF/ITIL など) の使用をプロバイダ選定基準として評価します。
	・ 運用関連の料金体制 (復元やレポートに追加料金が発生するかどうかなど) を明確に理解していることを確認します。
	・ プロバイダから提供されているトレーニングを評価します。質の高いトレーニングですか。必要な言語で提供されていますか。新機能がリリースされたときに資料が迅速に更新されていますか。
	・ クライアントへの展開が必要な場合は、プロバイダのリリース スケジュール (パッチおよび新規バージョン) を既存のデスクトップ エンジニアリングのプロセスと計画に組み込みます。
	・ 展開ニーズとその依存関係 (デスクトップ アプリケーションの互換性テスト、データ センター スペース、統合製品の購入など) を評価します。
	・ プロバイダから提供されているドキュメントを開発者に評価させます。質の高いトレーニングですか。必要な言語で提供されていますか。
	・ 回復性と障害復旧に関する復元ポリシー/処理手順をレビューします。
規制/法的義務	・ コンプライアンスがプロバイダにも適用されるかどうかを調べます。適用される場合は、コンプライアンスを実証するためにどのレポート/ポリシー/認定が必要かを特定します。
	・ ハイブリッドの内部/プロバイダ コンプライアンス レポートの作成を自動化することを検討します。これにより、サービス プロバイダによる静的レポートの提供ではなく、レポート作成 API の公開が必要となる場合があります。
	・ データがサービス プロバイダ側にある場合は、データ所有権を保持できることを契約で確認します。
	・ 外部サービス統合をサポートするように、データ統合アーキテクチャを拡張します。プロバイダ選定基準にセキュリティ認定を追加します。
全般	・ インフラストラクチャ統合アーキテクチャを作成して、ソフトウェア サービス統合のためのフレームワークを提供します。
表 1 : 推奨事項の要約

■まとめ

　消費者と中小企業は、統合を必要とせずに配布モデルのメリットを享受できます。そのため、現在の SaaS 市場では、消費者および中小企業市場をターゲットとした製品やサービスが大半を占めています。この記事で取り上げた統合に関する問題の多くは解決されず、これらのプロバイダの基幹業務アプリケーションを消費することは、どの企業にとっても高リスクです。

　ビジネスにとってのアプリケーションの重要性が高いほど、考慮すべき項目も多くなります。完成型サービスとして配布される基幹業務アプリケーションは、データ所有権などの契約上の問題が主な懸案事項である戦術的アプリケーションに関連する労力が小さいことと比べて、統合に多大な労力を必要とします。この関係を表したのが、図 4 のヒート マップです。

図 4 : 考慮事項のヒート マップ

　今日、企業の IT 部門にとって、フル機能のアプリケーションより、ビルディング ブロック サービスやアタッチ サービスを消費する方が経験豊富で、使いこなす自信もあります。Reuters 3000 などのリッチ アプリケーションのデータ フィードや、スパム フィルタなどのインフラストラクチャ サービスの場合は、このモデルをよく理解できます。

　SaaS 配布モデルが成熟し、広く普及するに伴い、統合をはじめとした多くの企業ニーズが満たされ、企業はさまざまな機能をサービスとしてソーシングできるようになります。その結果として登場するのが、オンサイト ソフトウェアとクラウド サービス間のバランスをとった、ソフトウェア + サービス アプリケーションです。

　Gianpaolo Carraro 氏と Fred Chong 氏が記事「SaaS: An Enterprise Perspective (SaaS: 企業の観点)」で述べているとおり、SaaS と S+S は、知識豊富な CIO が企業価値を高めるために使用できる補足ツールです。IT マネージャは SaaS と S+S を恐れるだけでなく、企業にメリットをもたらす代替的なソーシング モデルと、ソリューション構築のための新しいアーキテクチャアプローチという、SaaS と S+S の真価を見極める必要があります。

　ソフトウェア サービスは、正しく取り扱えば、IT に対する企業の見解を変えるために役立ちます。

【参考資料】

欧州議会データ保護法 Exchange Hosted Services 『IT Doesn' t Matter (IT は重要ではない)』Nicholas G. Carr 著 『Harvard Business Review』2003 年 5 月 『The Long Tail: Why the Future of Business Is Selling Less of More (ロング テール :「売れない商品」を宝の山に変える新戦略)』Chris Anderson 著 (Hyperion、2006 年) Microsoft Privacy Guidelines for Developing Software Products and Services ( マイクロソフト プライバシー ガイドライン: ソフトウェア製品およびサービスの開発) Microsoft Regulatory Compliance Planning Guide ( マイクロソフト法令順守プランニング ガイド。このガイドでは内部 IT を取り上げているが、外部プロバイダの評価にも適用可能) WS-Federation は、マイクロソフト、IBM、RSA、BEA、VeriSign をはじめとした複数のベンダによって採用されている、OASIS 規格のドラフトです。マイクロソフトでは、Windows Server 2003 R2 のコンポーネントである Active Directory Federation Services (ADFS) によって WS-Federation をサポートしています。 OASIS Active Directory Federation Services (ADFS)

著者について Kevin Sangwell : マイクロソフトの開発者プラットフォーム グループのインフラストラクチャ アーキテクト。マイクロソフト コンサルティング サービスでプリンシパル コンサルタントを 5 年間務めるなど、過去 16 年以上にわたって、IT 業界のさまざまなテクニカル/ リーダーシップ ポジションを歴任。英国の公共部門と民間部門の両方において、エンタープライズおよび e コマース向けインフラストラクチャのアーキテクチャ/ 設計プロジェクトを指揮する。その例として、ユーザー数 12 万人の組織を対象とした分散型マイクロソフト インフラストラクチャ、教育機関の 120 万ユーザー向けのエクストラネット アプリケーション プラットフォームなどが挙げられる。インフラストラクチャ アーキテクトとして、企業に対してアドバイスやコンサルティングを提供し、さまざまな国際イベントに参加。

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

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

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