
なぜSOAのセミナーには業務フローの話が出てくるの?
SOAといえば、業務フローや業務改革といったキーワードも関係するようです。でも、そもそもシステムの設計の話ですよね。オブジェクト指向だとか、構造化技法だとか、そういうものと同じ次元であるにもかかわらず、業務という用語が顔を出すのはなぜでしょう?

まぁ、これはSOAに限った話じゃないよね。どんなアーキテクチャを採用するにせよ、業務的な視点を抜きに設計を行なうことはできません。本来の目的にそってシステムを作ることを考えれば、業務をどうやって分割するかという話に行き着くんですよ。
業務を分ける?
情報システムってのはつまるところ現実世界の写像なわけです。現実に行なわれている業務のある部分を、システム上にマップしてやる関係です。アーキテクチャ的な視点で素晴らしいシステムを作っても、実際の業務にそぐわないものだったら意味がないよね。

それはそうですよね。実際の業務あってのシステムですからね。では、SOAに特有の事情というのはあるのでしょうか?
たしかにそれもあります。SOAの構成要素であるサービスコンシューマは、実装としてはワークフローのような形になると説明しましたよね。在庫確認のあと引当をする。在庫が無い場合は入荷日を確認する。細かい業務に対応するサービスを組み合わせて業務のプロセスを形づくるわけです。
これって、まさに業務フローのことでしょう。サービスコンシューマを設計するってことは、業務フローを設計することなんですよ。だから、SOAには絶対に業務フローの話が出てくる。

なるほど、既存システムを組み替える場合なら、そのロジックを汲み取ってコンシューマに反映させれば良いかもしれませんが、SOAにのっとって新たなシステムを作ろうとすれば、業務フローの作成は当然のことになるわけですね。
そういうことです。サービスはできるだけ普遍的な形に切り出すべきです。現実のオペレーションをそのままシステムに反映させてしまうと、汎用性が低く再利用に堪えないものになってしまうことは前回説明したとおりです。
それに比べて、コンシューマはいかに業務のオペレーションフローに合わせるかが大切なんですよね。そこに価値がある。サービスコンシューマの設計とは、業務フローをシステム的に記述することだから、その対象が分からないとどうにもならないわけです。
それで、セミナーなどで業務フローの話が出てくるわけですね。(次のページに続く)