arclamp.jp アークランプ

「SAPコンポジットアプリケーション 成功のための次世代企業アプリケーション像」と「SAPエンタープライズサービスアーキテクチャ 変革の時代を勝ち抜く最新IT戦略」を読了。
結論から言えば、非実現的なことが書かれているものの、やはりこの方向性にチャレンジする価値はあるだろうと感じだ。また、SOAに対する概念レベルの理解方法、CIOの説得方法、既存アプリケーションからの移行概念、など学ぶ点はあった。サマリというより、僕なりに理解・整理した内容を書くので、正確なところは原文をあたっていただきたい。

SOAを2層で理解する
SAPの提唱するSOAの概念は、ESA（エンタープライズ・サービス・アーキテクチャ）とPCA（パッケージド・コンポジット・アプリケーション）の2つに集約される。
ESAの役割は、標準的な仕様（Webサービス）の世界に、システムを引きずり出し、サービス化・コンポーネント化することにある。一方、PCAは、ESAによって提供されるサービスやコンポーネントを合成（コンポジション）し、１つのアプリケーションとして（パッケージ化して）提供する。

もう少し詳しく説明しよう。従来型のEAIが提供していたのは、2点間統合、あるいはハブ＆スポーク型（車輪のように１つの中心に対して軸が集まること）統合である。そのため、各システム同士のデータ交換という視点が強い。ユーザーは、それぞれの業務範囲で各システムを利用し、その際に必要な情報を、他のシステムから集めてくる。
一方、ESAでは、一度、1つの箱の中に全てを持ってくる。そのため、企業全体から見た業務という視点で、各システムを協調動作させることができる。このESAを前提にすることで、PCAは、従来のポータルとは異なることが可能になる。ポータルは各システムから直接情報を集めて表示を行う。そのため、統合的に参照するには向くが、入力になると個別のシステムを利用せざるを得ない。しかし、ESAがあれば、入力も統合的に行うことになる。

データ交換から、ビジネスプロセス管理へ
たとえば、ある商品に関する発注、納品、支払いという業務で、かつ、それぞれ発注サーバ、納品サーバ、経理（支払い）サーバとばらばらの場合を考えてみる。
従来型EAIでは、各システムがデータ交換を行うことで業務が進んでいる。そのため、ビジネスプロセスを把握するためには、3つのサーバの状態を知らなくてはいけない。発注者が納品状況を確認しようとすれば、納品システムを利用しなくてはいけない。また、なんらかのフィードバック（納品されたことを発注サーバに自動でお知らせ）が必要であれば、コストがかかることになるし、キャンセルの場合などを考慮すると、複雑なデータ交換を想定しなくてはいけない。
一方、ESAであれば、発注、納品、支払いというビジネスプロセスはESAが管理する。発注があれば次に何をすべきか、キャンセルされれば各システムになにを通知すべきか、というのはESAが知っている。このため、各システム間の無駄なデータ交換が必要なくなる。そして、なによりPCAを通じて、ビジネスプロセスがどんな状態にあるのかを一元的に見ることが出来る。

つまり、EAIが、ただのデータ交換手法に過ぎなかったのに対して、ESAは、ビジネスプロセスの統合的な管理という、まったく別次元のものなのだ。ちなみに、このビジネスプロセスの定義方法として注目されているのがBPEL（びーぺる）である。

CIOへのアピール
本においても、ビジネスプロセスの一元的な管理という点がもっとも協調されている。CIOには、システム間にまたがるビジネスプロセスを一元的に把握したいというニーズが強いはずだ。これが可能になることで、無駄なビジネスの発見や、効率化が可能になるからだ。また、新しい業務の組み込みなども、ESAの設定を変更するだけでよく、各サーバには影響も与えない。この点が、CIOへの売り込みポイントだろう。

既存システムをESAに適合させていく
では、実際に既存システムを含む場合には、どのように移行していくべきか。どのシステムも、すぐにWebサービスの世界に登場できるわけではない。しかし、ESAの利点を生かすことで、段階的に移行することが可能になる。なぜ、ESAとPCAという2層分けていたのだろうか。ESAで提供されているのはインターフェースに過ぎない。実際の動作は、既存システムなり新規システムなり、実際のシステムが行うことだ。だからこそ、一定のインターフェースが提供されていてば、裏側の仕組みが変更されても、PCAには一切影響を与えないわけだ。ということで、既存システムを段階的にESAに適合させていくことが可能になるわけだ。（これで、ぴーんと来たエンジニアは正解である。そう、これってまさに、インターフェースベース開発のことなのだ）

第1段階は、当然アダプタによる開発である。ごりごりの作りこみで、ESA上のせてしまう。この場合、データの検索といった基本機能だけが提供されるだろう。PCAからは1つに見えても、ESA経由では、それぞれのシステムに対して、それぞれアクセスすることになる。たとえば、システムをまたがるようなデータであっても、そのたびに各システムに適合するように変換をおこないながらやり取りをおこなう。
第2段階は、データモデルとサービスの共通化である。各システムをまたがるような共通概念に対して、共通のデータモデルや共通のサービスを定義し、すべてのシステムがそれを対象に動作する。
第3段階は、プロセスの共通化である。各システムをまたがるような汎用的なプロセスを共通化する。発注のキャンセルというプロセスを共有し、各システムが動作するわけだ。
第4段階は、これまで得た共通のプロセス、データモデル、サービスを利用し、ビジネスプロセスをESA側から制御するのだ。ビジネスプロセスは、モデリングされメタデータ（設定ファイル）として管理される。この段階では、各システムはESAに対して、完全に受動的に動くようになっているだろう。

ESAの問題点
とまぁ、話は美しいが、現実はそうでもないだろう。
まず、既存システムをESAの世界に出られるようにするコストは、かなりなものではないだろうか。プロトコル的にWebサービスに対応するのも大変だろうし、コンポーネントやサービスとして分離できるかも疑問だ。さらに、全システムをまたいでデータベースレベルのトランザクション管理を正確におこなうのは不可能に近い気がする。あまり”既存アプリケーションの統合”を標榜しすぎると、仕事は取れても現場は苦労することになる。ここ数年のまともなシステムや、これからの新規システムに採用していくぐらいが、とりあえず安全圏ではないだろうか。
そして、ESAでは、パフォーマンスに問題を抱えやすい。サービスを細分化しすぎると、システム内で完結すべきことですら、ESAを経由しないと動作しなくなる。毎回、XMLに変換してネットーワーク越しにやりとりするとなると、どうしても無駄が多くなる。ただし、ESAで制御できていれば、一元的にパフォーマンスコストを測定することが可能になるため、チューニング戦略は立てやすくなるだろう。また、ビジネスプロセスという長期のトランザクションに価値があれば、小さなレベルのパフォーマンス劣化は許容できるかもしれない。ともあれ、ビジネスプロセスのトランザクション動作特性にあわせて常識的な判断をするという、当たり前のことがあいかわらず重要なのだ。

まとめ
ベンダーの言うことを鵜呑みする必要性はないが、SOAという方向性は、CIOからエンジニアまで、それほどぶれることなく納得できるのではないだろうか。特に、段階的な移行を可能とするという考え方は、リスクを低減させるよい手法であり、すでにソフトウェア開発でも実証されている。しかし、そのアーキテクチャは、これまでの考え方とは一線を画すものとなるため、従来どおりの体制では移行できない。
情報システム部門にしてみれば、当然、企業全体で統合化された考え方が必要になるため、従来のようなベンダーの関係では、うまくいかないのはわかりきっている。
エンジニアにしても、ESAを前提とする場合では、どう設計し、実装すべきかというのは判断が難しくなる。また、インターフェースのきり方が悪ければ、大きな影響を与えてしまうことになる。

であれば、小さく進んで、微調整をしながら試してみるしかない。今年の大きな課題である。

SAPコンポジットアプリケーション―成功のための次世代企業アプリケーション像 ダン ウッズ Dan Woods 木下 哲也 福龍興業 Amazonで詳しく見る by G-Tools

SAPエンタープライズサービスアーキテクチャ―変革の時代を勝ち抜く最新IT戦略 ダン ウッズ Dan Woods 木下 哲也 福龍興業 Amazonで詳しく見る by G-Tools