情シスは何度でも甦るさ。

OracleDB/Ruby好きの情シス部員がお送りします

サービスの粒度を考える

SOAをやる際に一番悩ましいのは、サービスの粒度である。

  • 細かすぎると、サービス間の連携が複雑に
  • 大きすぎると、再利用性できない


とうところで、ベンダーの方々は、こういう説明をする。

  業務上の処理 = サービス

この説明を聞いた瞬間、担当者としては、自分の会社の業務を思い浮かべて、

 『あぁ、じゃぁ、大体こういう単位なのかなぁ』

と、一瞬納得した気分になる。

が、そうやって、思い浮かべるサービスの粒度は、同じ社内の担当者でも異なる(経験談)

ましてや、業務の担当者が考える粒度はもっと細かいに違いない。

なので、私としては、

  業務上の処理 = サービス

は、こう言い換えられると思う。

  サービスの粒度に法則なんて無い → お前の会社のサービスの単位なんてわかんねーから、そっちで考えてね

最近は、Oracle のAIA みたいにテンプレートを用意するなど、過去のノウハウから、ある程度の法則、テンプレートを作成するなどの動きもあるが、それも有料だし、それでも結局そのまま自社に適用することはできない。

ということから、最近、私が思うのは、サービスの粒度を決定するのには、

業務上の処理なんて考慮する必要が無いんじゃないだろうか。

システム側の都合だけでSOAを導入する方法というのもある気がするのですよ。

ただ、将来的にBPMの分野まで踏み込む方法は、ちょっとは頭の片隅にあった方が良いけど、それによって導入が遅れるくらいなら、考えない方がよくないか。

SOAの導入にスモールスタートを忘れてはいけないんだぜ。