産業アナリストのNeil Ward-Dutton氏が書いた記事によると、ビジネスプロセス管理（BPM）とサービス指向アーキテクチャ（SOA）を組み合わせることは、理論的にいって相互補完的なものだという。この2つのコンセプトをどう組み合わせるかは意見が分かれるとこではあるが、いずれにしてもビジネスバリューを増大させるだけのシナジー（相乗効果）が両者の間にはあると氏は主張している。
BPMとSOAを一緒にすることがなぜ業界で相互補完的なものになるのかと考えられるようになったのか、氏はその理由を考察している。
1. 主要なソフトウェア製品でのBPELの採用。2004年から2005年にかけて、SOAの導入を望む顧客をターゲットにした新しいミドルウェア製品を売る企業は･･･（略）･･･複数の外部サービスも絡む何段階ものステップがあるロジックフローを処理し、Business Process Execution Language（BPEL）と呼ばれる標準を実装したフローエンジンを売り出しはじめました。そして「ビジネスプロセス」という言葉が濫用されたことで、多くの解説者がSOAの話とBPMの話を混ぜたり混同したりました。
2. 技術屋に製品をアピールし、業務リーダに売り込む方法を探し求めているソフトウェア会社。新しい技術に「BPM」という言葉をかぶせるのは、従来の技術屋に加えビジネス系のユーザにも製品を売るのにもってこいの策に思えたのです。
3. ウェブサービスを利用するBPM関連製品。スタートアップのソフトウェア企業のグループも新しいタイプのソフトウェアプラットフォームを売り出しました。それらのプラットフォームはBPMの導入に特化したもので、Business Process Management System（BPMS：ビジネス管理システム）と知られるようになりました。･･･（略）･･･SOAに対する関心は急激に広がりました。そして、既にあるバックエンドのアプリケーションやシステムやデータソースと新しい自動プロセスを統合する製品を顧客へ「オープン」にする方法として、新しい各種ウェブサービスプロトコルに便乗するのはこれらベンダーにとって自然なことだったのです。
氏は2つのコンセプトが見方の違いにすぎないと断じている。SOAはボトムアップ型の主にITによって推進される方法で、BPMはトップダウン型のビジネスによって推進される方法だという。そしてこの2つの方法のシナジーを活かすのに失敗する原因を、それぞれの推進役間で利害のすり合わせが行われないためだとする。
- BPMの実施において「統合サービス」を効果的に活用できないこと
- プロセスの再利用の可能性について十分考慮しないこと
- 情報アーキテクチャのもつ価値を活用できないこと。異なる環境にあるサービスを組み合わせる時には情報フローの変換がおこなわれます。SOA実装においては「共通情報モデル」を定義することはこの変換の量を最小限にする上できわめて重要なことです。
氏が推奨するのは、ビジネスプロセスやサービスをデザインするだけでなく、ビジネスアーキテクチャと技術アーキテクチャの両方について「サービスコンテキスト」を作成する方法だ。ビジネス側によってのみデザインされるサービスは、リソースや情報の再利用や効果的な利用において最適とはならないだろう。IT側によってのみデザインされるサービスも同様で、特にビジネスプロセスが組み合わさった状況に対してはあまり良くデザインされたものにはなってないだろう。
ビジネスアーキテクチャが推進役となるSOAにおいては、既存のアプリケーションやリソースをどうすれば効果的に再利用できるかを考えるだけではサービスのポートフォリオはできません。また、外部に対して配慮された高度なビジネスサービスも同じくらい重要です。さまざまな大きさ・抽象化レベルをカバーするサービスモデルは、このようなトップレベルのビジネスサービスの要件を噛み砕いて、組織やそのシステムのさまざまなレベルにおいて必要となるサービスの要件を気付かせてくれます。
氏は以前「結果がありきで、サービスやプロセスはふさわしい結果を成し遂げる上で表裏一体のものです」と書いている。同じように、BPMとSOAの推進役も見方を広げ、ITとビジネスの両方の要求を満たすように全体的なシステムデザインをすべきだと主張する。
BPMとSOAをどう組み合わせるかを考える時には、統合実現可能性の面だけを考えるようではいけません。BPMとSOAを見る視点をビジネスアーキテクチャという見方にまで広げるなら、より深い関係性とより大きな可能性が明らかになるでしょう。