ビジネス・プロセス管理（BPM）とSOA

SOAのおもなメリットの1つに、ITとビジネス・プロセスの整合性の確保があります。 ビジネス・プロセスは、どのようにビジネス・アクティビティが実行されるかを定義するものであり、非常に重要なものです。 企業が発展し、その事業運営を改善するにつれて、ビジネス・プロセスも変化します。 また、企業の競争力を高める目的でビジネス・プロセスが変更される場合もあります。

現在、ITは事業運営に不可欠であり、 ITサポートなしでは、企業は事業を継続できません。 しかし、このことにより、ITには大きな責任が課せられています。 この責任のうち、ITが迅速かつ効率的な方法で変化に対応できることが重要な部分を占めています。 理想をいえば、ITはビジネス・プロセスの変化に対して即座に対応する必要があります。

しかしながら、ほとんどの場合、ビジネス・プロセスの変化にアプリケーション・アーキテクチャを素早く適応させるほどの柔軟性は、ITに備わっていません。。 ソフトウェア開発者には、アプリケーションの動作を変更するための時間が必要です。 その間、企業は古いプロセスを実行し続けなければなりません。 競争の激しい市場において、このような遅れは危険なものです。また、従来型のソフトウェア開発に依存していると、複雑化する一方のITアーキテクチャに素早い変更を加える際に、この危険性がさらに高まります。

従来のソフトウェア開発アプローチに付随するおもな問題は、ITモデルとプロセス・モデルの間に、大きなセマンティック・ギャップが存在することにあります。 SOAは、IT開発とビジネス・プロセス・ライフ・サイクルの整合性を維持する開発モデルを導入することで、このセマンティック・ギャップを解消します。

さらに詳しく理解するために、SOAライフ・サイクルの4つのフェーズについて確認していきましょう。

• プロセス・モデリングは、プロセス・アナリストとプロセス所有者が協力し、ビジネス・プロセスを分析してプロセス・モデルを定義するフェーズです。 ここでは、アクティビティ・フロー、情報フロー、ロール、ビジネス・ドキュメントが定義されます。 また、ビジネス・ポリシーと制約、ビジネス・ルール、パフォーマンス指標が定義されます。 パフォーマンス指標は、多くの場合、キー・パフォーマンス・インディケータ（KPI）と呼ばれます。 KPIの例には、アクティビティ所要時間やアクティビティ・コストがあり、このフェーズでは通常、Business Process Modeling Notation（BPMN）で表されます。
  
• プロセス実装は、エンド・ツー・エンドのプロセス・サポートを提供するために、開発者とプロセス・アナリストが協力してビジネス・プロセスを実装するフェーズです。 SOAアプローチによるプロセス実装フェーズには、BPEL（Business Process Execution Language）を使用したプロセス実装とプロセスのサービスへの分解、サービスの実装または再利用、そして統合が含まれます。
  
• プロセスの実行と制御は、実際の実行フェーズであり、プロセスへの参加者によりさまざまなプロセス・アクティビティが実行されます。 エンド・ツー・エンドのビジネス・プロセス・サポートにおいては、ITがプロセスを進行させ、プロセス参加者にアクティビティを実行するよう指示することが重要であり、その逆であってはなりません。また、このプロセスを実際に進行させるのは従業員です。 SOAでは、プロセスはプロセス・サーバー上で実行されます。 プロセス制御は、このフェーズにおける重要部分であり、この過程で、プロセスのスーパーバイザーまたはマネージャーによって、プロセスが最適な状態で実行されているかどうかが制御されます。 遅延や例外の発生、リソースの利用不可、またはそのほかの問題が生じた場合、プロセスのスーパーバイザーまたはマネージャーは、修正措置を講じることができます。
• プロセスの監視と最適化フェーズでは、プロセス所有者がOracle Business Activity Monitoring（Oracle BAM）を使用して、キー・パフォーマンス・インディケータ（KPI）を監視します。
• プロセス・アナリスト、プロセス所有者、プロセス・スーパーバイザー、および主要ユーザーは、プロセスを調査したうえで、ビジネス状況の変化を考慮に入れてKPIを分析します。 さらに、ビジネス上の課題を調査し、ビジネス・プロセスを最適化します。

図1に、プロセスが循環に取り込まれ、各種段階を経過していく様子を示します。

図1

いったん最適化が特定および選択されると、プロセスはモデリングフェーズへ戻り、その最適化が適用されます。 次に、プロセスは再実装され、ライフ・サイクル全体が繰り返されます。 このプロセスは、各段階で改善されるため、反復型ライフ・サイクルと呼ばれています。

組織的側面から見たSOA開発

前述の項で説明したとおり、SOA開発は従来型の開発とは大幅に異なります。 SOA開発はプロセス中心の開発であり、モデリングおよび開発の焦点がビジネス・プロセスおよびエンド・ツー・エンドのプロセス・サポートに合わせられているため、ビジネスとITのギャップが効率的に軽減されます。

SOA開発サイクルの成功を左右するのは、プロセスの正しいモデリングです。 有効なエンド・ツー・エンド・サポートを開発できるのは、プロセスが細部にわたってモデリングされている場合に限られます。 また、例外プロセス・フローについても考慮に入れる必要があります。 これは、IT部門の対応範囲を逸脱した困難なタスクとなる場合があります（従来的な視点から見た場合は、とくにこのことが顕著です）。

プロセス中心のSOAプロジェクトを成功させるには、組織的な変更が必要になります。 プロセスを十分に理解したビジネス・ユーザーを、プロセス・モデリングに積極的に参加させる必要があります。 これらのユーザーが積極的に参加するのは当然だと思い込んではいけません。とくに、プロセス・モデリングに付加価値を見出せない場合など、ビジネス・ユーザーは、ほかの作業が"より実用的である"と感じるかもしれません。 したがって、プロセス・モデリングに意味があることを簡潔に説明することが、きわめて有益な時間的投資となります。

優れた戦略として挙げられるのは、経営陣による支援を得ることです。 次の2つの要素を経営陣に説明することは、非常に大きな意味があります。はじめに、なぜ、プロセス中心アプローチとエンド・ツー・エンドのプロセス・サポートが重要であるのか、そして2番目に、なぜ、ビジネス・ユーザーの参加なしでは、IT部門はこのタスクを無事に完了できないのか。 通常、経営陣は素早く事態を理解して、ビジネス・ユーザーに参加するよう指示を出してくれるでしょう。

また、いうまでもないことですが、このプロセス中心の開発アプローチを継続的な活動にする必要があります。 このため、特定の組織構造を正式なものにしておく必要があります。 そうでない場合、それぞれのプロジェクトごとに承認を求める必要が発生するでしょう。 この提案されたアプローチが、IT部門の組織的境界を越えることは既述のとおりです。 多くの組織では、BPM/SOAコンピテンシー・センターが設立され、ビジネス・ユーザーに加えて、プロセス・アナリストや、プロセス実装、サービス開発、プレゼンテーション・レイヤー、SOAガバナンスを担当するグループなど、SOA開発に必要なすべての人材が配置されます。

ことによると、SOA開発がになうもっとも重要な責務は、上記のグループが共通の目標に向かって進めるよう、彼らを適切にとりまとめることかもしれません。 これはプロジェクト・マネージャーに課された責任であり、プロジェクト・マネージャーは、ガバナンス・グループと緊密に協力する必要があります。 このようにしてのみ、短期的（エンド・ツー・エンドのビジネス・プロセス・アプリケーションの開発）および長期的（ビジネス・ニーズに合った、柔軟性と機動性を備えたITアーキテクチャの開発）なSOA開発を成功に導くことができるのです。

技術的側面から見たSOA開発

SOAでは、SOA開発アプローチを実現するテクノロジーと言語を導入します。 とくに重要なのは、ビジネス・プロセス・モデリングに使用されるBPMN（Business Process Modeling Notation）と、ビジネス・プロセス実行に使用されるBPEL（Business Process Execution Language）です。

BPMNは、プロセス・モデリングの鍵を握るテクノロジーです。 プロセス・アナリスト・グループには、BPMNとプロセス・モデリングの概念に関する深い知識が必要です。 SOA向けのプロセスをモデリングする場合、細部にわたってモデリングする必要があります。 実行の観点から見て、これ以上分解できないレベルで個別アクティビティを特定する必要があります。 また、例外シナリオについてもモデリングをおこないます。 例外シナリオでは、何か不具合があった場合のプロセス動作を定義します。現実社会では、ビジネス・プロセスがうまくいかないことが実際にあります。 ここでモデリングする必要があるのは、例外状況に対してどのように対応し、適切に回復するかという点です。

次に、プロセスを自動化します。 これには、BPMNプロセス・モデルから実行可能なBPEL表現へのマッピングが必要になります。 この作業を担当するのは、プロセス実装グループです。 BPMNからBPELへの変換および逆方向の変換は、ほとんど自動的に実行されます。これにより、プロセス・マップと実行可能コードの同期が常に保証されます。 ただし、実行可能なBPELプロセスは、さらにビジネス･サービスに関連づける必要があります。 それぞれのプロセス・アクティビティは、対応するビジネス・サービスに関連づけられます。 ビジネス･サービスは、個別のプロセス・アクティビティを実行します。

SOA開発の効率がもっとも高くなるのは、再利用可能なビジネス・サービスと、低レベルの仲介サービスおよびテクニカル・サービスのポートフォリオを有する場合です。 ビジネス・サービスは、ゼロから開発することが可能であり、既存のシステムまたはアウトソーシングされたシステムから公開できます。 この作業を担当するのは、サービス開発グループです。 理論上は、はじめにサービス開発グループがすべてのビジネス・サービスを開発する方法が理にかなっています。 次に、プロセス実装グループがこれらのサービスを組み立ててプロセスを作成します。 しかし、現実にはそのとおりにはいきません。 したがって、両方のグループが並行して作業を進める必要がありますが、これはきわめて困難な作業です。 SOAガバナンス・グループとプロジェクト・マネージャーにより厳密かつ簡潔に監督されない限り、2つのグループ（プロセス実装グループとサービス開発グループ）の成果に矛盾が生じるでしょう。

プロセスの実装が完了したら、プロセス・サーバーにこれをデプロイします。 プロセス・サーバーは、プロセスを実行するだけでなく、プロセス監査証跡、正常終了したプロセス・リスト、停止、または失敗したプロセス・リストなどの有用な情報を提供します。 この情報は、プロセス実行を制御し、必要な修正措置を講ずるために役立ちます。 ここで、サービスとプロセスの通信には、ESB（エンタープライズ・サービス・バス）が使用されます。 また、サービスとプロセスは、UDDIに準拠したサービス・レジストリに登録されています。 そのほかのアーキテクチャにはルール・エンジンがあります。これはビジネス・ルールの中央保管場所としての役割を果たします。 ヒューマン・タスクを含むプロセスでは、当然のことながらユーザー・インタラクションが重要であり、ID管理と関連づけられています。

SOAプラットフォームは、Oracle BAM機能も提供します。 Oracle BAMは、プロセスのキー・パフォーマンス・インディケータを測定し、プロセスを最適化するために有用なデータを提供します。 各Oracle BAMユーザーの最終的な目標は、プロセス実行を最適化し、プロセス効率を高め、重要なイベントを検知してそれに対応することにあります。

Oracle BAMにより、もっとも有効な場所でプロセスの最適化を開始することが可能になります。 従来、プロセスの最適化はシミュレーション結果に基づいておこなわれるか、またはもっと悪い場合は、ボトルネックの場所を推測しておこなわれてきました。 これに反して、Oracle BAMが提供するデータはより信頼性が高く正確であるため、最適化を開始する場所について、よりよい意思決定を実現できます。

図2に、SOAアーキテクチャ・レイヤーを図解します。

図2

ケース・スタディ

プロセス・モデリング

ここまでは、理論上の説明をしてきました。 ここからは、Elektro Slovenijaによるエンド・ツー・エンドの調達プロセスに関するケース・スタディを確認していきましょう。Elektro Slovenijaは、スロベニアの国営配電企業です。 調達プロセスは、次のOracleツール一式を使用して実装されました。 図3に示すとおり、モデリングにはOracle Business Process Analysis Suite（Oracle BPA Suite）が使用され、実装にはOracle SOA Suite（Oracle BPEL Process Manager、Oracle Enterprise Service Bus、Oracle Business Rules、Oracle Web Services Manager、Oracle Application Server）、Oracle JDeveloper、およびOracle Service Registryが使用され、ビジネス・アクティビティ監視にはOracle Business Activity Monitoringが使用されました。

図3

国営企業であるElektro Slovenijaには、調達に関する厳密な法令を遵守する義務があります。 調達プロセスは、注文要求フォームから始まります。 はじめに、似たような注文と併せて共同購入にするのか（例：オフィス用品）、または個別注文をおこなうのかを決定する必要があります。 また、注文価格によってプロセスも異なります。 4,200ユーロ未満の注文はもっとも単純であり、申し出が3つ集まれば発注書が発行されます。 12,000ユーロまでの注文は、交渉プロセスが実行されたあとで契約書が発行されます。 それ以上の場合、注文プロセスを進めるには特別委員会が形成されます。これは、注文の種類（製品、サービス、または不動産）によって異なります。 このプロセスには、発注者、契約責任者、調達部門長、高額注文のための委員会メンバーなど、複数のロールが関与します。

プロセス・モデリングは、プロジェクトにとって最初の難関でした。 Elektro Slovenijaでは、すでにSOAコンピテンシー・センターが設立されており、経営陣はBPMおよびSOAに関して十分に理解していました。 このため、ビジネス・ユーザーの参加を促すことは、それほど難しいことではありませんでした。 私たちの経験からいうと、プロセスをモデリングするグループには以下のロールをもつ人々を含める必要があります。

• プロセス所有者：プロセス・フローを検証し、プロセスへ適用できる変更に関する意思決定をおこないます。
• プロセス所有者のアシスタント（1～2名）：プロセスについて確実に理解している必要があります。 実際のモデリングを担当します。
• モデレータ：質問をして、会議を進行させます。
• プロセス・モデラー：SOAでの詳細なモデリングに精通しています。

このプロセスは、Oracle BPA Suiteを使って6つのレベルでモデリングされました。 また、24のサブプロセスを含み、230のアクティビティから構成されており、そのうちの100以上がヒューマン・タスクです。 このプロセスには25種類のロールが関与しており、40以上のビジネス・ルールが実装され、7個のキー・パフォーマンス・インディケータが定義されています。 図4に、Oracle BPA Suiteアプリケーションに表示されたトップレベルのプロセス・ダイアグラムを示します。

図4

特筆すべきは、Oracle BPA Suiteがヒューマン・タスクを含むプロセス（上述のプロセスなど）に充実したサポートを提供していることです。 また、Oracle BPA SuiteのOracle Business Process Publisherを使用すると、そのほかの関係者とプロセス定義を共有できるため、コラボレーションが推進されます。

プロセスの設計が完了したら、図5に示すとおり、Oracle BPA Suiteでセマンティック・チェックを実行して妥当性を検証できます。これにより、誤ってモデリングされた可能性がある個所が特定されます。

図5

プロセスの実装

エンド・ツー・エンド・サポートを実現する複合アプリケーションを開発するために、次の3つの開発アクティビティが並行して開始されました。

• BPEL実行可能プロセスの開発
• ビジネス・サービスの開発
• プレゼンテーション・レイヤー（ユーザー・インタフェース）の開発

このケースでは、2名の開発者からなる1つのチームにより、BPEL実行可能プロセスとビジネス・サービスが開発されました。 そのうち1名の開発者は、プロセス・モデラーでもありました。 このため、組織的な側面が簡素化され、コミュニケーションのオーバーヘッドが軽減されました。

ここからは、BPEL実行可能プロセスとビジネス・サービスの開発について簡単に説明します。 ユーザー・インタフェースはSOAに固有の開発ではないため、ここでは触れません。

BPEL実行可能プロセスの開発

図6

BPEL実行可能プロセスは、手動で開発することも、BPMNモデルから自動的に変換することもできます。 ここでは、後者の手法が使用されました。 シームレスな変換を実現するには、BPMN設計においていくつかのガイドラインに従う必要があります（BPMNからBPELへのマッピングに関するガイドラインを参照）。 BPMNからBPELへの変換は非常に複雑であり、同じBPMN構造を異なる方法でBPELにマッピングすることもできます。

ガイドラインに従うと、BPMNからBPEL（Oracle BPA SuiteからOracle JDeveloperのブループリント）への変換はわかりやすいものになります。 テクノロジーは比較的新しいものですが、上記の調達プロセスのような複雑なプロセスに対しても、本番使用に耐える十分な機能を発揮します。 プロジェクトにおいて、変換に関する問題はあまり発生しませんでした。 図6に、Oracle JDeveloperのBPELブループリントのスクリーンショットを示します。

BPELコードは、Oracle JDeveloperで修正する必要があります。 ここでのもっとも重要なタスクは、BPELプロセスを実際のビジネス・サービスに関連づけることです。 現在、Oracle BPA Suiteでビジネス・サービスのWSDLインタフェースを使用できますが（BPEL開発が簡素化されます）、この場合プロセス・モデラーに付加的なスキルが要求されることに注意してください。

BPELとサービスを関連づけることに加えて、このフェーズでの重要なアクティビティには、ESB仲介の開発、Oracle Service Registryへのサービス登録、Oracle Business Rulesへのビジネス・ルールの入力、プロセスのデプロイ、BAMダッシュボードの開発（後述）があります。

ビジネス・サービスの開発

BPMNからBPELへのラウンドトリップ

SOA開発、とくに実際のプロジェクトにおいて重要となるのが、Oracle BPA SuiteのBPMNモデルとOracle JDeveloperブループリント表現のBPELとの間で、変更をラウンドトリップする機能です。 ラウンドトリップには次の2つの重要な側面があります。

• どのようにして、BPELに加えられた実装上の変更を損なうことなく、BPMNモデルの変更をBPELに反映するか
  
• どのようにして、BPELでの変更をBPMNモデルに再反映し、双方の同期を保つか

Oracleツールの完成度の高さは、私たちにとってうれしい驚きでした。 以下の両方のシナリオにおいて、ラウンドトリップはうまくいきました。

• BPAプロセス・モデルを更新した際、以前におこなわれたBPELの実装上の変更を失うことなく、Oracle JDeveloperブループリントに変更を反映することができました。
  
• Oracle JDeveloperでBPELを更新した際、BPAモデルに変更を再反映することができました。このとき、ビジネス・ユーザーは、この変更を容認するか、拒否するかを選択できます。 次に、（Oracle JDeveloperの）BPELに注文要求の保存アクティビティが追加され、この変更がOracle BPA SuiteのBPMNモデルに反映される様子を示します。

図7

図8

ラウンドトリップは反復的SOA開発の鍵となるため、実際の開発において非常に重要です。これにより、短期の開発サイクルが実現されるとともに、既存のコンポジット・アプリケーションの変更が容易になります。 また、ラウンドトリップにより、モデル（BPMN）と実行可能コード（BPEL）の同期が確保されます。 Oracleツールを使用した開発においては、フォルト・ハンドラがOracle BPAとOracle JDeveloperとの間で正しく同期されなかったというようなささいな問題しか発生しませんでした。 私たちの意見では、モデリングと実装で別々のツールを使用するというオラクルのアプローチは、単一ツールで両方に対応するアプローチよりも優れています。

BPMNからBPELへのマッピングに関するガイドライン

ここで、BPMNからBPELへのマッピングについて再確認してみましょう。 Oracle BPA Suiteでは、すべてのBPMN構造が同じように適切にBPELにマッピングされるわけではないことは説明したとおりです。したがって、もっとも効率的なモデルを作成するため、プロセス・モデラーがBPMNからBPELへのマッピングに関する特性を認識しておく必要があります。

基本的なマッピング・ルール

• すべてのBPMNアクティビティは、BPELスコープにマッピングされます。
• 開始イベントは、トリガーの種類によってReceiveまたはPickのいずれかのアクティビティにマッピングされます。
• 終了イベントは、種類によって、Reply、Invoke、Throw、またはそのほかのアクティビティのいずれかにマッピングされます。
• ゲートウェイは、Pick、Switch、Flowなど、さまざまなBPELアクティビティに変換されます。
• ビジネス・データは、変数にマッピングされます。
• サブプロセスは、Invokeアクティビティにマッピングされます。
• それぞれのBPMNサブプロセスは、別々のBPELプロセスになります。

循環を取り扱う場合、特別な注意を払う必要があります。 BPMNは任意の循環をサポートしていますが、BPELはサポートしていません。 したがって、すべての循環をWhileループ（構造化された循環）に変換する必要があります。 しかし、これにより、プロセス・モデルが大幅に変更される場合があり、少なくとも見た目は変わることになります（適切に変換された場合、プロセス動作は変わりません）。 結果的に、ビジネス・ユーザーは変換済みモデルを正しく理解できない可能性があります。 また、任意の循環がサポートされていないため、プロセス中に多くのヒューマン・タスクが挿入されている場合、問題となる場合があります。

比較的単純なシナリオの場合、構造化された循環を回避するため、複数の出力を伴う決定についてリファクタリングをおこなうことができます。 このような決定を、複数の決定に分解します。 たとえば、次のシナリオでは、BPELへのマッピングが適切におこなわれません。

したがって、次のように、問題となっている決定を2つの決定に分解します。

循環に含まれ、繰り返し実行されるアクティビティは、生成されたBPELにおいて複製されます。 これを防止するには、繰り返しアクティビティをグループ化し、サブプロセスとしてモデリングします。 そうすることで、生成されたBPELでは、サブプロセスを呼び出すInvokeアクティビティのみが繰り返されます。

また、終了イベントにも注意を払う必要があります。終了イベントは、実際、期待したとおりにはBPELプロセスを終了しません。 BPMN決定では、生成されたBPELでswitchをどのように生成するかということに影響を及ぼすことができます。 条件に対するデフォルト・フローが定義されていない場合、BPELのswitchアクティビティ内でotherwiseが生成されます。 これは、とくに、BPELプロセスでヒューマン・タスクのさまざまな結果をチェックする必要がある場合などに役立ちます。

プロセスの実行

開発が完了したら、コンポジット・アプリケーションをプロセス・サーバーにデプロイします。 Oracle SOA SuiteおよびOracle BPEL Process Managerでは、プロセス実行の制御および管理に適したツールが提供されています。 とくに、10.1.3.4で追加されたフォルト・ポリシーでは、プロセス内でフォルトが発生した場合にシステム管理者が介入できるため、本番で使用すると非常に有効です。 調達プロセスは長時間実行プロセスであり、複数のヒューマン・タスクを含んでいます。 したがって、フォルトが発生した場合も、このプロセスを終了してはなりません。 フォルト・ポリシーはこのようなケースをサポートしており、システム・フォルト処理をプロセス実装から分離できます。 Oracle Web Services Managerは、プロセス実行フェーズにおいて実用的なツールです。 Oracle Web Services Managerは、プロセスおよびサービスの監督を簡素化し、使用状況の監視とSLA遵守に対する制御を実現します。

また、ヒューマン・タスクを含むプロセスには、プロセスに参加するすべてのロールおよびユーザーを管理するID管理システムが必要です。 この例では、Active Directoryが使用されており、Oracle SOA Suiteに統合できます。 かわりに、Oracle Identity Managementを使用する選択肢もあります。

Oracle BAMを使用したプロセス監視と最適化

過去の法規制の変更により、調達プロセスにいくつかの変更を加える必要が生じました。 また、効率を上げるために、プロセスのボトルネックをシステム的に特定する機能に重点を置いたため、プロセスを変更する必要性がさらに高まりました。

以上をサポートするため、Oracle BAMサポートが実装されました。 実装内容には、プロセス実行を監視するセンサーの定義とBAMダッシュボードの開発が含まれます。 次の図に、このプロセスのために開発されたダッシュボードの例を示します。

図11

Oracle BAMは、とくにプロセス所有者にとって重要であることが明らかになりました。プロセス所有者は、リアルタイムでプロセス実行を監視できるようになりました。 私たちの経験では、単純なKPIのみを監視する場合、BAMダッシュボードの開発は非常に簡単です。

最後の課題は、BAMデータをBPAモデリング・ツールにインポートし直すことでした。 これは、カスタムJavaScriptを使用して実現できますが、多大な時間を要する作業です。 Oracle BPA Suiteの将来のバージョンでは、この点が改善され、作業が簡素化される予定です。

BAMデータは、プロセスを最適化する際の効果的な出発点です。 この時点で、調達プロセスは1回目の反復段階にあり、最適化はまだおこなわれていません。 ただし、最適化できる可能性のあるポイントを特定するために、すでにBAMデータが使用されています。 最初の反復においても、調達プロセスはすでにいくつかのメリットを示しました。 一部のプロセス・アクティビティが自動化されたことで、従業員の作業量が25～35%削減され、プロセスの可視性も大幅に向上しました。 プロセス・インスタンスの実行を追跡し、選択したプロセス・インスタンス内でどのアクティビティが実行されているかを把握することが可能です。 これにより、空白となる時間が削減され、実行の高速化につながります。 次の反復では、さらに多くのプロセス・ステップが自動化されるため、より多くのメリットが得られるでしょう。

教訓

実際の例であるケース・スタディから、プロセス中心のSOAアプローチがもたらすもっとも重要なメリットが明らかになりました。 それは、ビジネスとITの整合性の強化であり、開発サイクルの短縮であり、エラーの削減です。そして、もっとも重要な点は、大幅に迅速化された開発サイクルにより、ビジネス要件を実現するために必要な時間が大いに短縮されることです。

ビジネスとITの整合性の強化に関連して、次の重要なメリットがプロセス中心の開発によりもたらされました。

• ビジネス要件に対する深い理解
• ビジネス・プロセスに対するエンド・ツー・エンド・サポート
• プロセス監視と実行制御による、有益なビジネス・パフォーマンス・インジケータの提供

これらのメリットをSOAアプローチなしで実現することは、非常に困難でした。

また、プロセス中心のSOA開発アプローチは、技術的にも組織的にも課題があることがわかりました。 プロセス・モデリング、プロセス実装、サービスのデプロイ、そしてユーザー・インタフェースを開発するためには、コンピテンシー・グループを形成する必要があります。 また、SOAガバナンス・チームとプロジェクト・マネージャーによる監督が不可欠です。 小規模プロジェクトの場合、少人数の開発グループが複数のロールを受けもつことができます。 さらに、SOA開発を成功させるには、新たなスキルが必要です。

モデリングから実装、実行、監視、および最適化におよぶSOAプロセスの完全なライフ・サイクルには数多くのメリットがあり、必要な知識および製品に対する投資に見合う十分な価値があります。 プロセスのライフ・サイクル全体を転換することでSOAの真価が発揮され、プロセスの変更、修正、そして最適化が実施されると、さらにその価値が明らかになるでしょう。

このケース・スタディが伝える一番のメッセージは、実社会における複雑なプロセスに対しても、完全なエンド・ツー・エンド・プロセスの開発が可能であるということです。 プロセス中心のSOA開発アプローチに完全なライフ・サイクル・サポートを組み合わせれば、企業は、プロセスの自動化を通じて、ITサポートだけでなく経営効率を改善および最適化する大きなチャンスを得られます。

参考資料

1. Matjaz Juric、Kapil Pant、 Business Process Driven SOA using BPMN and BPEL、Packt Publishing（2008年8月）
2. Matjaz Juric、Poornachandra Sarang、Benny Mathew、 Business Process Execution Language for Web Services 2nd Edition、Packt Publishing（2006年1月）
3. Business Process Modeling Notation, V1.1（pdf）

Harish Gaurの貢献に感謝します。

Matjaz B. Juricは、コンピュータおよび情報科学の博士号を取得しています。 また、『 Business Process Driven SOA using BPMN and BPEL』、『 Business Process Execution Language for Web Services』（英語版およびフランス語版）、『BPEL Cookbook』、『SOAによる統合アプローチ』など、SOAに関する書籍の著者または共著者でもあります。 Juricは、複数の大規模SOAプロジェクトにおいて、コンサルティングに従事した経験をもちます。