【 ここから本文 】
Microsoftウォッチ
ソーシャルブックマークに登録 ：
印刷用ページの表示
【解説】
SOA導入の「阻害要因」とそれを踏まえた「現実解」
課題を解決しうる「設計図の参照」や「ミドルアウト型アプローチ」
（2008年04月28日）
SOA導入の新しいアプローチ
それでは、企業がSOAの導入を成し遂げるための現実的なアプローチとは、いったいどのようなものなのか。以下では、導入プロジェクトを成功させるうえで押さえておくべきポイントを、最近、販売されたSOA関連製品を取り上げつつ説明していく。
ポイント1：ビジネス・ロジック視点からの導入を心がける
インターネットの進展のように、技術革新がビジネスの方法そのものを変革してしまうケースもあるが、SOAにおいて主となるのはビジネスの方法、すなわちビジネス・ロジックであり、技術はビジネス・ロジックをIT化するための道具でしかない。
一方、SOAにおいて重要となる技術的視点は、社内外での接続性を考慮した標準への準拠と、ミドルウェアだけでなく、サーバやストレージといったITインフラ層、DBMSを中心としたデータ層、人間との接点となるプレゼンテーション層といったアプリケーションの実行を支えるシステム全体の整合性と運用性にある。
ポイント2：疎結合のメリットとデメリットを正しく知る
SOAのメリットとして疎結合が挙げられることが多いが、疎結合型のシステムが密結合型のシステムに比べて、すべての面ですぐれているわけではない。疎結合でのシステム連携は、確かにシステムの柔軟性を向上させるが、プロセスの厳密性は密結合でのシステム連携に比べて劣ることが多い。複数のシステムで協調的に更新処理を行い、障害発生時でのデータの厳密な整合性を必要とするようなシステムの場合は、密結合によるシステム連携の手法を採用することも選択肢となりうる。
ポイント3：メリットが発揮しやすい領域から導入する
確かに、欧米そして国内においても一部のグローバル企業では、トップダウン型の理想的なアプローチを採用し、大規模なSOAプロジェクトを成し遂げている。すなわち、EAを制定し、ビジネス・プロセスの分析を行い、UMLなどによる文書化を行い、サービスを定義して、ESBによって全社レベルでサービスを結合するという手法だ。
しかしながら、SOAやEAという概念が登場する以前から、トップダウンによる統合化したシステム構築が提唱されてきたものの、大半の企業ではそれを実現できていないというのが現実である。そこで、比較的導入が容易であり、効果が発揮しやすい分野から着手するという方針は、傑出した技術力やガバナンス能力を持っているわけではない、大多数の企業にとってかなり有効と考えられる。例えば、アプリケーション間の連携や、基幹系システムと情報系システムの連携、与信審査のようなバックエンド処理とオンライン・バンキングのようなフロントエンド処理との連携といったケースである。
ポイント4：プロセスだけでなくデータにも注目する
SOAによるシステム構築を考えるうえで、もう1つ、課題となるのがデータ統合の問題である。従来型のアプリケーションの場合、各アプリケーションとデータは個別に連携しており、基本的にデータの変更に対する影響はアプリケーションごとに完結している。あるアプリケーションで別のアプリケーションのデータを利用して、データの変更を行う際には、データのコピーを持つケースが多く見受けられる。
一方、SOAに基づくアプリケーションでは、アプリケーションがデータの格納場所やデータ・タイプを意識することはなく、呼び出されるサービスがデータのアクセスを行うことになる。もし、アプリケーションごとにアクセスするデータを個別に持たなければならない場合は、サービスを共有することが難しくなり、サービスの再利用性というSOAの利点が生かされないのである。
これまで、SOAに関する説明では、ビジネス・プロセスに着目されることが多かったが、SOAによるアプリケーション構築においては、データの整備と統合はより重要な課題となることに留意されたい。
ポイント5：用意された“設計図”を参考にする
近年、SAPやOracleなどのERPベンダーは、自社ERP製品のサービス化対応を推進してきた。これらのベンダーは、業務別・業種別のサービスをあらかじめ定義したモジュールとして提供し始めている。そこで筆者が提案したいのが、ERPベンダーによって各種サービスがあらかじめ定義されたモジュールを“設計図”として利用してSOAを導入するという方法だ。
| 写真1：汎用のブロック・ピースから説明書なしで組み立てるよりも、目標とする完成物に近い、説明書つきのキットを利用したほうが効率的かつ確実にプロジェクトを遂行できる |
 |
例えば、レゴ・ブロックで「塔」を組み立てるときに、さまざまな形と大きさの、汎用のブロック・ピースで組み立てるよりも、あらかじめブロックとブロックの組み合わせ方が図示された説明書入りの「エッフェル塔キット」を買ってきて、それを参考にしつつ独自のアイデアも取り入れて組み立てたほうがはるかに簡単である。このように、出来合いの“設計図”を活用するというわけである（写真1）。
設計図になりそうなSAPとOracleの製品を挙げて説明しよう。SAPの「Enterprise Service Repository（ESR）」は、1,000種以上のサービス定義情報と20種以上の複数サービス定義の組み合わせ例を含んでおり、提供される情報には、プロセスとサービスの定義、サービスのメタデータ、ビジネス・オブジェクトとサービスなどのビジネス視点の情報と、技術視点の情報の両方を含んでいる。
一方、Oracleが商品として提供を始めている「Oracle Application Integration Architecture（AIA）」は、同社による事前定義済みのSOAであり、同社の複数のアプリケーション・パッケージ製品をサービスとして連携させる「Process Integration Pack（PIP）」と業種別のビジネス・プロセス情報を提供する「Industry Reference Models」で構成される。PIPには、共通オブジェクト／メッセージ（XSD）、アプリケーション・ビジネス接続サービス（ABCS）、エンタープライズ・ビジネス・サービス（EBS）がビジネス・サービス・リポジトリに格納されている。さらに同社では、SAPなどの他社アプリケーション・パッケージ製品や独自開発アプリケーションとの連携を可能にする「AIA Foundation Pack」の提供を開始している。
また、ERPベンダーではないが、IBMでもSOAでのシステム構築を促進するためのコンサルティングやフレームワークの提供を強化している。同社は2008年1月、小売業向けの「Retail Integration Framework（RIF）」を発表した。RIFは、同社が提供する小売業向けのビジネス・プロセスに対するソリューション・パターンと他社のアプリケーション・パッケージをSOAによって連携させるフレームワークである。
これらのような、SOAによるシステム構築の設計図として活用可能な製品やフレームワークを理解し、利用の可能性を調べることは、業務アプリケーション・パッケージを利用する場合はもちろん、利用しない場合においても有効である。アプリケーションをどのようにモジュール化してサービスを切り出すのか、ビジネス・プロセスをどのようにサービス化してソフトウェアとして組み込むのかといった、システム構築の際に直面する問題点を解決するうえで参考になると考える。
