SOA は、バズワード（もったいぶっていて、意味があまりない単語）のタグクラウドにおける大物だった。しかし、BPMはどんどんその存在感を増してきている。「IT投資から利益を得るためには、プロセスを飼いならす必要がある」と組織が気づくにつれ、BPMの重要性は高まり、IT内外での意識共有が広まっている。（BPMは）あなたのアーキテクチャにとって、より重要なものなのだろうか？SOAプラットフォームとしてのBPMから、SOAを達成するための論拠としてBPMを使うようになり、これら二つのコンセプトは緊密にかかわり合うようになってきている。
BEAのDain Hansen(source)は、"成功するSOA統合のための青写真"(source)を最近公表し、「組織内でSOAを動かす為には何をすべきなのか」について詳しくアドバイスしている。その文中で、HansenはBPMとSOAを統合することの重要性を指摘した。
私たちはITによるERPシステムの統合について、その統合が業務アナリストや営業部門 - 自分たちの業務プロセスのために、データやサービスを真に必要としている人たち - とどう関わるか、それを考慮する事を抜きにしては語れません。しばしば矛盾するこれら二つの要素は、完全に統合されたソリューションの一部分として、協調動作する必要があります。SOAとBPMがともに良く動作するとき、巨大な利益が生み出されるのを私たちは見てきました。ITと営業部門における、様々な役割の間で調整が行われるだけではありません。ITと営業部門の両方を良く管理しうる、最適化された方法でプロセスが実装されるのです...同じくBEA社員のQuinton Wallが最近語ったのは、ビジネスの素早さを最大化するために、BPMとSOAを組み合わせることについてである(source)。Wallは、BPMツールをSOAとともに活用することにより、ITとビジネスの一致協力を達成できる事について述べた。"ITへの依存を減らしつつ、統制された方法で、業務サイドに変化をもたらすためのコツです。" つまりBPMツールは、ITへの関連を減らしつつ、営業部門の人間がサービスとサービス・コンポジションの利点を享受する事を可能にするのである。
一度業務プロセスのモデルが実装され、SOAとの統合によって自動化されると、業務アナリストに対して実行時のフィードバックがBAM（business activity monitoring）を通じて戻ってきた際に、最適化が発生します。これによりビジネスユーザは、改善する必要のあるプロセスがどこにあるかをリアルタイムに見る事ができるのです。改善の必要性が一度認識されると、業務アナリストはモデルとビジネスの両方を更新する事ができ、開発サイクルが新しく開始されます。こうした業務統合サイクルの繰り返しを通じて、真の業務変革と最適化が実現できるのです。
この種の利益を得るためには、SOAとBPMが統合される必要があります。その方法は例えば、統合された共通のツールを与える事でメタデータや統治／管理情報を組織内のユーザで共有したり、業務プロセス間の相互運用性や、バックエンドの統合システムに対してこれらのプロセスが変換される方法を凄まじく最適化したり、などです。
BEAのアドバイスは、組織が既にサービスの提供が可能だと仮定した"SOAファースト"な視点から来ている。他のいくらかの人たちは、BPMとSOAの統合に関して業務プロセス中心の視点をとっている。
Rich Seeleyは、Delaware電気協同組合におけるSOAのイニシアチブ(source)と、IT部門の最高責任者であるGary Crippsが、それらを成功に導いた方法について語った。Crippsは、業務プロセスを分解するアプローチが大いに役立ったと言う。
" 私は全てをプロセスに落とし込むことから始めました" Crippsはそう説明しました、"私が発見したのは、この規模のSOA統合になると、我々は55パーセントの時間をプロセスの定義に費やしたと言うことです。55パーセントというのは、私にとってはかなりの驚きでした。20パーセントはコーディングに費やしました。残りの25パーセントは、テストと実装に費やしました。"またSeeleyは、SOAによって、業務アナリストの役割がどのように変わってきたか(source)を指摘した。iTKOのチーフサイエンティスト、John Michelsenの文章を引用しながら、コンポーネントの開発がITの責務であるのとは対照的に、要件に対して業務アナリストは責任を負うべきであり、それがSOAのイニシアチブに最も影響を与える、とSeeleyは指摘した。
これは、SOAの採用を検討している中小規模のビジネスにとっては良いニュースだ、とCrippsは言いました。業務プロセスの識別とモデリングはコアとなるチーム - 部門別のステークホルダを含む - によって行う事ができます。しかし、プロジェクトの20パーセントを占めるコーディングは、アウトソースが可能なのです。
社内では、SOAのチームメンバーは、業務プロセスの観点からアプリケーションを考えるように変化したとCrippsは言います。"サービス指向になったとき、関心事におけるチームメンバーの知識が本当に向上しました。あるトランザクションに関連する、複数の部門における業務プロセスと業務ルールを理解するため、かなりの努力を費やしたからです"と彼は言いました。
" コードを書いている個々の開発者にはほとんど影響がない、と言うのが正しいのではないかと私は考えています。なぜなら彼もしくは彼女は、要求を受けてコンポーネントを構築し、コンポーネントをテストし、より大きなシステムにそれを組み込んでいます, "と、彼は言います。 "それ自体は、5年前と変わりません。そう、皮肉な事に、開発者はSOAによる影響をほとんど受けないでしょう。"
どちらの場合においても、システムの構築とSOAの扱いにおいては、業務プロセスの管理と分析の重要性をSeeleyは挙げた。
Dennis Byronは、BPMは現在ソフトウェアスタックにおける第一級の地位に値する(source)、と指摘した。Byronが指摘したのは、ITの視点から見た統合レイヤの一部、と言う役割を超えて、BPMはスタックのトップに位置づけられると言うものである。こうしたビジネス的な観点からソフトウェアスタックを捉える事で、ITはBPMの事を"サービス指向アーキテクチャ(SOA)の方法論に根ざした'新しい開発パラダイム'"と見なすことができると言う。
Neil MacehiterとNeil Ward-Duttonは、"BPMか、SOAか？"と言う質問の答を得るために、二つのコンセプトが現代の組織内でどのように働いているか(source)を語った。"BPMはトップダウン／ビジネスドリブンなイニチアチブであり、SOAはボトムアップ／技術ドリブンなイニチアチブである"と言う伝統的なアプローチをとる代わりに、MacehiterとWard-Duttonは"サービス指向「と」プロセス指向における、トップダウン「と」ボトムアップの観点が、より統括的なビジネスとテクノロジーのアーキテクチャの視点から、どうやったらうまく一緒にやっていける"かについて語った。こうした文章に続いて MacehiterとWard-Duttonは、プロセスとサービスのコンセプトが、成果を通じてどうやって一つになるかを説明した(source)。
成果とは、望まれる結果です。高いレベルにおける成果とは、組織の核となる価値や、財務上の業績と何らかの関係があるものです。このレベルでは、結果はミッションステートメントと直接リンクするでしょう。低いレベルにおける成果は、オペレーションの結果と関係します - 例えば、"製品が届いた"などです。サービスは、成果を達成するためのコミットメントです。プロセスは、どの成果が達成されるかに応じた手続きです。
二人のNeilは、BPM/SOAの展望をこのようにまとめた。"「成果」が第一である、と言うのが真実です。サービスとプロセスは同じコインの表と裏であり、正しい「成果」を達成するために存在します。"