昨日、3回目となるBPP研の勉強会を行ないました。大型連休明けすぐということもあり、仕事の都合で欠席の人が多かったのですが、かなり突っ込んだ議論ができたように思います。

この日のテーマは、「柔軟なプラットフォームをつくる」と題して、業務アプリケーションをどういったプラットフォームで動かしたらいいのかという話である。

前回に業務の階層化を行い、そこでマクロとミクロの2段ワークフローという概念を提示した。さらに、その業務の階層化に対応して、プラットフォームも構造化する必要があるということを提起した。その時のベースになる考え方は、機能とプロセスとデータを分離した3層構造を採用することである。その構造に、業務の階層レベルを当て込むのである。

重要なのは、その機能・プロセス・データの分離と疎結合ということである。ここがミクロSOAの肝のところである。ミクロSOAというのは、勝手につけた名前だが、要するにサービスの粒度が小さいSOAである。その小さい粒度のサービスをプロセスでつないで業務システムを作るという考え方である。

ではマクロSOAというのは、サービス単位が大きい、例えば、SFA、CRMなどをサービスの単位としていることで、コンポジットアプリケーションなどとも呼ばれている。BPMはミクロSOAの基盤で動かす仕組みであると考えている。

また、話はそれますが、今言った３層構造というのがこれからの大事な考えかたになるわけですが、従来はこれができなかったのです。システムの成り立ちのそもそもは全部一緒くたになっていました。機能もプロセスもデータも一つのプログラムという形で埋め込まれていました。

そして、RDBMSの登場により、データは分離されましたが、機能とプロセスはそのまま密になっていました。それが、BPMSが出てくると機能とプロセスを分離することができるようになったのです。

ただし、実際にはBPMSはそんな意識がなくて作られて、ほとんどのBPMSベンダーはここに気がついていません。BPM on SOAのポイントはこの３層構造なのですから、単純にBPMSを使っただけのシステムを構築したところで、柔軟なシステム構造にはならないのです。

さて、こうした3層構造と業務階層の対応はどうなっているのでしょうか。まずは機能のところですが、前回議論したように単位意思決定機能をもったミクロワークフローを実現するところにあたります。

それは少しはしょった言い方かもしれませんが、ユーザインターフェースということになります。実は、このユーザインターフェースということもよく検討する必要があると思います。ユーザインターフェースというとすぐに従来型の画面を思い出すと思いますが、プロセスを分離して、単位意思決定の場としてUIをもってきたのですから、そこをちゃんと機能させるために従来の画面はふさわしいのでしょうか。

昨日も議論になったのですが、こうした意思決定には多くの参照すべき情報や守るべきルールなどがあって、それを見ながら処理するわけで、そう考えただけでもこれまでのデータ登録を主体にした画面では限界があるのがわかると思います。

この観点で見ると、いまのBPMSの画面も使い物にならないことがわかります。実際にもBPMSの画面ではなく別箇に画面を作る例が多いという話が昨日も出ていました。

次にプロセスはもちろんBPMSというプラットフォームを使いますが、ここでの考え方はBPMSベンダーが言っていることとだいぶ違うように思えます。先ほどの画面もそうですが、プロセスの稼動管理なんかも単にタスク一覧にその時点のステータスがでるだけでいいのでしょうか。

また、モニタリングなども成熟度の低い企業ではすぐにできやしないわけで、そうなるとBPMSは一体何なのかと思ってしまうのである。プロセスエンジンとワークフローがまずあればそれでいいというのは言いすぎだろうか。

データについては、以前から言っている“プロセス志向におけるデータベース設計のありかた”をよく検討していく必要があると思っている。

結局、プロセス志向で考えた場合のプラットフォームが、従来型とはずいぶんと違っていたり、ツールベンダーの言う売り込み機能とも違っていたりということをきちんと理解しないと利点を生かせないことになる。

従って、新たな視点で捉えたプラットフォームを再設計する必要があると思っている。幸い、スクラッチで作る必要はなく、ウエッブ系にある技術やサービスをうまくモディファイして、それらをアセンブルすることで実現できると考えている。そこには一旦ゼロベースにして考える柔らかな頭が要るわけで、若い人たちがぜひ挑んでほしいと願っている。
　
次回はいよいよプロセスパターンについての議論になる。