BPMソリューションの構成要素

Mariano Benitez著
2007年2月20日（翻訳記事2007年8月22日）

要約

BPMソリューションを構築する方法は、従来のアプリケーションとは大きく異なります。したがって、BPMソリューションのアーキテクチャは、異なるアプローチで定義する必要があります。

ここでは、BPMソリューションに関連する概念と、BPMを使用して構築するソフトウェアソリューションを定めるアーキテクチャの主な構成要素について説明します。今後の記事では、要件を正しく評価し、それを適切なソリューションアーキテクチャに反映するためのアイデアやヒントをご紹介する予定です。

この記事は、アーキテクチャの定義を担当される方や、BPMの実装方法を理解したいと考えている方を対象としています。AquaLogic™ BPM Suiteに関する文書を読まれたか、BPMの概念について説明している筆者の以前の記事を読まれたことを前提としています。

はじめに

最初に例えを1つ。車を運転するだけなら、エンジンやトランスミッションの仕組みを理解している必要はありません。車に関するこうした2つの側面は、異なる点に焦点が当たっています。一方では、ギアチェンジ、右折や左折、ミラーの見方、速度について学びます。もう一方で、燃焼、変速、および電子回路や部品について学びます。

この記事では、アーキテクトが車の運転手、エンドユーザが同乗者、そしてBPMが車です。さあ、ドライブに出かけましょう。

定義

BPMソリューションのコンポーネントを順に見ていきます。最初にピラミッドの頂点となるBPMソリューションの定義を示します。

BPMソリューション

BPMソリューションとは、組織のインフラストラクチャ内で実行されるビジネスプロセスです。

BPMソリューションは、「動作」し、実際の作業を行うビジネスプロセスです。このソリューションには、ユーザやシステムと相互に作用し、ビジネスプロセスを「実行」するために必要なものがすべて揃っています。アーキテクトは、モジュールの仕様とレイアウトを定義することで、ソリューションが要件をすべて満たすようにする必要があります。この時点では、高レベルの位置に立って、主な概念的要素に注目します。各要素の実装方法や複雑さは意識せずに、コンポーネントのレイアウトを決定するだけです。

この形式的な定義が完了したら、ソリューションの内部要素を定義できます。

ビジネスプロセス

ビジネスプロセスとは、ビジネス目標を達成するための実際の作業プロセスを反映する一連のアクティビティです。

ここでは、ビジネスプロセスをプロセス駆動型アプリケーションとして考えることができます。モデルとすべての統合、プレゼンテーション、およびロジックが含まれます。

ビジネスプロセスは、AquaLogic BPM Studioを使用して作成し、BPMプロジェクトの形をとります。ビジネスプロセスの各要素は別個に実装されますが、Studioに統合され、BPMプロジェクトで使用されます。この時点では、ビジネスプロセスは単なる定義です。ソースであり、動作はしません。実行のためにはコンテナが必要であり、またすべての外部依存関係がオンラインかつ使用可能になっている必要があります。ビジネスプロセスのホストとして、インフラストラクチャが必要です。

インフラストラクチャ

ソリューションのインフラストラクチャとは、ビジネスプロセスの実行を可能にする一連のサービスとアプリケーションです。

ビジネスプロセスを実行するには、BPM実行エンジン、クライアントアプリケーション、管理ツールなどとの相互作用が必要です。これらのモジュールはすべてAquaLogic BPM Suiteに含まれます。必要なのはこれだけではありません。ビジネスプロセスからWebサービスを呼び出したり、カスタムデータベースからデータを読み取ったり、Enterprise JavaBeansを使用したりする場合は、これらのサービスが使用可能になっていなければ、プロセスは仕様どおりに動作しません。

これらのサービスは、ビジネスプロセスに必要なため、インフラストラクチャの一部になります。これらの依存関係はすべてBPMサーバ自体と同じくらいインフラストラクチャ内で重要です。

インフラストラクチャは、これらすべてのコンポーネントが通信する方法、コンポーネントの場所、およびその構成を定めます。インフラストラクチャでは、BPMを最も高いレベルから見ています。ここから、任意のコンポーネントにドリルダウンしてそれぞれの詳細を確認できます。ここからのビューは、ソリューション内で動きのある大きな要素を示すので重要です。ビジネスプロセスも、組織も、インフラストラクチャがホストとなります。インフラストラクチャは、通常は多数のビジネスプロセスのホストとなるので、多数のBPMソリューションの一部になります。インフラストラクチャは、その中で実行されるすべてのソリューションを適切に処理するように計画する必要があるので、この点は重要です。その長所は、完全に新しいインフラストラクチャを作成する必要がなく、多くのリソースを節約して、多くのインフラストラクチャの管理を軽減できるということです。

アーキテクチャの定義を開始するとき、すぐに2点の問題が浮かび上がります。

• 何がインフラストラクチャの要件を定義するのか？

  例えばビジネスプロセスが依存する外部システムなど、インフラストラクチャの要件の多くはビジネスプロセスで決まります。そして、ビジネスプロセスの接続方法は、外部システムで決まります。
  
  ビジネスプロセスには予測される利用傾向があり、その傾向を予測することで負荷が決まります。その予測される利用傾向の範囲内で、ビジネスプロセスを使用する参加者の使用プロファイルを考えることになります。負荷の要件を収集する方法とインフラストラクチャへの影響を理解することは非常に重要です。これらを理解することで、インフラストラクチャの規模を適切に決定できます。
  
  ただし、IT、経営者、および規制によって、主にセキュリティ、SLA、およびサーバを実行するプラットフォームに関する要件が生じる可能性もあります。インフラストラクチャを設計するときは、これらの要件をすべて検討する必要があります。どれもアーキテクチャのコンポーネントが相互に作用する方法に確実に影響するためです。

ここで、開発のライフサイクルにおいて非常に重要な手順について説明します。この手順で、アーキテクチャに関する多くの決定を行う必要があります。

• どのようにビジネスプロセスをインフラストラクチャに導入するのか？

  ビジネスプロセスをデプロイする作業には、組織とインフラストラクチャへのマッピングが含まれます。これをデプロイメントトポロジと呼びます。
  
  デプロイメントは、プロセスのホストとなるエンタープライズサーバを定めます。このプロセスのインスタンスはこのサーバに保持され、プロセスを使用するクライアントはこのサーバに接続します。自動実行もこのサーバで行われます。したがって、インフラストラクチャをうまく利用するには、ビジネスプロセスのデプロイメントトポロジを慎重に計画する必要があります。デプロイメントトポロジでは、複数のサーバにプロセスを分散し、水平方向の拡張を可能にします。例えば、ユーザが最も集中するプロセスを1つのエンジンにデプロイし、バッチプロセスを別のエンジンにデプロイして、それぞれをニーズに合わせて設定できます。
  
  デプロイメントは、プロセスを配置する組織単位（OU）も定めます。したがって、同じプロセスを複数のOUにデプロイできます。各OUには同じプロセスの異なるバージョンを配置できるので、柔軟性が向上します。

インフラストラクチャは、Workspaceのようなエンドユーザ向けツールを提供することで、ユーザをビジネスプロセスに組み入れる手段にもなります。ただし、各ユーザが何を表示できるのか、またビジネスプロセスに対する各ユーザのパーミッションを定義する必要があります。組織のマッピングが必要となります。

組織

組織は、エンタープライズに実在し、ビジネスプロセスを操作するユーザを反映したものです。

組織は、実際のグループと、各グループや個人のパーミッションを反映します。また、組織の階層構造も定めます。簡潔に言えば、各ビジネスプロセスに対して、誰が何をすることができるのかを定義する必要があります。そのためには、可視性とパーミッションの2つの側面を考慮する必要があります。

可視性は、表示できるプロセスを定め、パーミッションは、プロセス内でできることを定めます。プロセスを操作するには、可視性とパーミッションの両方が必要です。これらは、組織がプロセスを操作する方法を定義するので、プロセスのデプロイメントトポロジを計画するときに重要な要素です。

これらの定義をさらに詳しく見ていきます。

• 可視性は、組織内でユーザやプロセスがどのような階層構造になっているかで決まります。

  参加者は必ず組織単位（OU）に割り当てられます。OUは、組織をルートとするツリー構造で定義されます。プロセスもOUごとにデプロイされるので、参加者は、各自が割り当てられているOUと、プロセスのデプロイ先のOUに基づいてプロセスを表示できます。これが、参加者に対するプロセスの可視性を定めます。

• パーミッションは、参加者に割り当てられているロールと、ビジネスプロセス内で定義されているロールで決まります。

  参加者には、直接、または参加者が属するグループに組織のロールが割り当てられます。ビジネスプロセスの定義では、プロセスの発行時に組織のロールにマップされるプロセス（抽象）ロールも定義します。ユーザがプロセスを操作するには、まずプロセスの可視性が必要ですが、その後は、プロセスにマップされているロールが割り当てられている必要があります。参加者は、割り当てられているロールとパーミッションに基づいてプロセスに対する操作が許可されます。

まとめ

これまでに概念を定義したので、ここでは、この概念を実世界に関連付けます。ビジネスと組織の要件を正しく理解し、リソースを最大限に活用して、要件を満たすことができるアーキテクチャに変えることが重要です。これを実行した結果得られるのは、項目やロール、参加者の詳細なリストではなく、むしろインフラストラクチャ、組織、およびプロセスを構築するときに使用する必要がある一連のルール、ガイドライン、またはポリシーです。

それでは、アーキテクチャを構築するために必要な定義は何でしょうか？

1. 組織をBPM空間にマップするルール

   実際の組織をBPMに反映するための基準を設定する必要があります。このとき、次の項目を定義します。

   • 組織単位のパターン
   • 組織のロールのパターン
   • グループのパターン
   • OUへの参加者の割り当て
   • グループへの参加者の割り当て
   • 参加者やグループへの組織のロールの割り当て

2. インフラストラクチャのコンポーネント

   アプリケーションやサービスの分布、およびその通信方法は、アーキテクチャの重要な部分です。実際、これがソリューションの技術アーキテクチャになります。次に、含める必要があるアプリケーションと必要な構成のタイプのリストを示します。

   • BPM Enterprise Server
     • タイプ（スタンドアロン、WebLogic）
     • 構成（クラスタリング、場所）
     • データベース構成
   • HiPer Workspace for BPM
     • 構成（クラスタリング、場所）
   • その他のモジュール
     • ビジネスプロセスの依存関係

3. プロセスのデプロイメントトポロジ

   ビジネスプロセスは、インフラストラクチャと組織に挿入する必要があります。これがデプロイメントトポロジです。トポロジは、インフラストラクチャと、ユーザがプロセスを使用する方法に直接影響します。定義は簡単ですが、組織とインフラストラクチャに基づいて慎重に行う必要があります。

   • 組織へのマッピング
     • プロセスをデプロイするOU
     • 組織のロールへのプロセスのロールのマッピング
   • インフラストラクチャへのマッピング
     • プロセスを実行するエンタープライズサーバ
     • プロセスに必要な外部リソース

最後に

アーキテクトは、何がBPMソリューションを定めるのかを理解し、インフラストラクチャのレイアウトを適切に決定し、ビジネスプロセスが従う必要があるルールを定義することが非常に重要です。この定義は導入の開始前に完了する必要はありません。また、ビジネスプロセスを構築する間に発展し、組織が求める要件が増えます。これらの側面をすべて定義するプロセスは、すべてのニーズを満たすアーキテクチャの完成に向けた、ビジネスユーザ、開発者、およびITとの長期にわたる交渉です。

アーキテクトの役割は、これらの関係者の間で調整を行い、さまざまな分野に対する要件の影響を理解することです。

ここでの筆者の役割は、BPMアーキテクトに、それぞれの仕事に役立つツールを提供することです。この記事がお役に立てれば幸いです。ご意見・ご要望などがありましたら、下のコメントのリンクからお送りください。

Mariano Benitezは、AquaLogic BPM Suiteのインテグレーションアーキテクトです。この製品と他のBEA製品やサードパーティ製品の統合の技術アーキテクチャを担当しています。