なぜビジネスコンポーネントなのか
コンポーネントという場合、どうしても部品とか、クラスライブラリーとかいったイメージで語られることが多い。これは、システムを作るうえでのシステム機能を指している。そういうものであると、しょっちゅう使う機能や、共通的な機能をまとめて外だしにする、いわゆるフレームワーク化することで、それらの再利用性を高め開発効率をあげることを目的としている。従来のコンポーネント開発といわれるものは、こうしたシステム機能寄りの発想が主なものになっているような気がする。
そうした業務非依存のアプリケーションフレームワークのレベルのものは、いまやStrutsや.NETFramworkあるいはWebの各種フレームワークなどがあり、こうしたフレームワークにあるシステム機能コンポーネントを活用すればいいことになる。問題は、業務に密着したその上層のドメインフレームワークがなかなか難しいのである。再利用性が高いドメインフレームワークはあまり見たことがない。
さて、フレームワークといってもよく分からないが、要はビジネスコンポーネントをどういう粒度で分類するかが肝になるところである。「ユーザ目線のBPM」にも書いてあるので重複するが、もう一度整理する。
言葉の使いかたはともかくとして、このくらいの階層構造になるのではないかと思う。
これらを分類・定義していくわけだが、業務分類から入るビジネスモデリングからのアプローチだとレベルが高いうちはいいが、詳細に落とし込んでいくとその固有性や例外、特殊性などの罠にはまり、モデル化が困難になるのではないだろうか。
そこで、いい業務プロセスを作るには、業務コンポーネント主体の開発でないといけないと考えた。より普遍的な粒度で業務コンポーネントを規定し、細かい機能的なぶれはそこで吸収し、業務サービス・業務プロセスでは、差別化のための差異を表現するというアプローチだ。
いい業務プロセスを引き出す方法論、道具の提供を目指すビジネスコンポーネント指向開発こそがBPMの正しい活かし方であると考えている。
次回はこの業務コンポーネントの粒度についてさらに具体的にみていく。