■

業務フロー
あまり聞き慣れないものの、これまで要件定義の工程の中には業務フローに類似のフローを書くモノが多くあります。
たとえばDFD、データと処理の関連を書いているだけに見えて、よく見ると業務の流れの判る図です。最近だと、アクティビティー記述なども似た方向性を目指しています。
ところで、何故これまで類似のモノがあるのにわざわざ業務フローという別の名前でわざと呼ぶかというと、類似のモノは余計な情報が記述されていたり、処理しにくい構造だったり、エディタが無料でない為。（最後が最も重要）
業務フローを作る作業としてはマジカがおそらく最適。マジカについてはここではなるべく触れずに次へ・・・（笑）
BPELとの関係について
ハマチとよく似た方向へ行っているBPELと比較がこれからおそらく出てくると思うので先手を打つコーナー
BPELとハマチは両方とも発想の原点は全く同じだと考えてます。業務フローを実行可能にする事で業務が変化したときのプログラムへの影響を最小限にする。そのために業務フローを記述する方法と、それを実行する方法、そして編集する為のエディタ。これらすべてハマチとBPELに共通して存在します。
違いはといえば、BPELはかなり汎用的な記述を実現する為に、新しいプログラム言語としても見れるほど複雑になってます。それに比べハマチはS2＋XPDLの記述＋α程度です。そのため見た目にも判りやすく素直に実行出来ます。
ワークフローエンジンとの関係について
ハマチ登場以来、内外から比較され続けて困ったものに最終回答（笑）
ワークフローエンジンはプログラムの起動、データの管理、外部との通信など単体で業務フローを回すのに十分な機能を持っています。この為比較的大規模になりやすい特徴があり、学習曲線は非常に高くなってます。
ハマチはプログラムの一部として動作し、データの管理も、外部との通信もすべてはS2とその周辺プロダクトへお任せする仕組みを作り上げています。そのため軽量で学習曲線はワークフローエンジンと比較にならないほど平坦です。
ハマチの場合WfMCのワークフローエンジンの定義から見れば貧弱そのものなので、ワークフローエンジンではありませんとはっきり断りを入れています（笑）