BPMについて知りたいが、尋ねることを恐れていたすべて

BPM（ビジネスプロセス管理）を会社に実装する価値がある理由については、ネットワーク上に多くの出版物があります。 通常、BPM実装がビジネスに提供する利点は定式化されています。

1. ビジネスプロセスの視覚的なモデリングと実行。
2. 柔軟なビジネスプロセスを構築するための市販のコンポーネントのセット。
3. 手動アクションを実行するためのユーザー操作。
4. ビジネスプロセスの構成における柔軟性。
5. ビジネスプロセスのバージョン管理のサポート。

言及できるのはこれだけではありませんが、プラットフォームの利点のかなり典型的なセットです。



すべてが本当にクラウドレスですか？ 皆が古いツールを捨てて、新しいプラットフォームに完全に切り替える時ではないでしょうか？



実装プロセスの間、または実際のアプリケーションを開発するときに、どのような問題があなたを待っているかについてお話したいと思います。 私の印象は、バージョン7.5から8.5までのIBM Websphere BPMプラットフォームでの明確な経験に基づいています。



上記の項目を順番に検討してください。

視覚モデリング

私たちは何を達成しようとしていますか？ そのため、アナリスト、またはビジネスユーザーもプロセスのダイアグラムを作成でき、サーバーによってまったく同じ形式で実行されます。 あるいは、少なくとも他の誰かが描いた図を見ることで、プロセスの本質を理解できました。



私たちは達成したいものを手に入れていますか？ 可能性が高いはい。



問題の根本は何ですか？ 私はそれらの2つがあると言うでしょう：

1. 提案されているプロセスモデリング言語は、実際のタスクにはあまりにも原始的であり、実際のワークフローを作成するには他の言語が必要です。
2. BPMNのようなダイアグラム言語は、一般的なソフトウェア開発サイクルにうまく適合しません。

実際、BPMシステムのフレームワーク内で実行されるプロセスは、ビジネスユーザーまたはアナリストが見る図に至ることはほとんどありません。 多くの詳細が添付されており、さまざまな詳細レベルにあり、何らかの方法でプロセスの動作を決定します。 これは、たとえば、プロセスのインスタンスに付随するデータ、またはプロセスと他の既存のシステムとの統合。 これらの詳細はすべて、通常、別のプログラミング言語のコードにまとめられます。



これらのコンポーネントがなければ、プロセスは実際には役に立たず、同時に典型的なBPMNダイアグラムには表示されないことを実践が示しています。



一方、ビジネスプロセスはソフトウェアですが、やや珍しいものです。 プロセスにはかなり長い開発およびメンテナンスサイクルがあり、メンテナンスの利便性はすぐに重要になります。 また、一般にアプリケーションの変更を管理し、いわゆる問題追跡システム（JIRAなど）と密接に関連して変更を管理することが非常に重要です。 つまり、プロセスを変更したのは誰で、いつ、正確に、そしてなぜで、どのタスク内で変更したかを知る必要があります。



したがって、一方で、ビジネスユーザーはプロセスのロジックを理解しているという誤った印象を受ける可能性が高く、その一部はコード内で隠されています。 開発者の観点から見ると、主に図が変更管理を含む開発ライフサイクルとよく一致しないため、図形式のプレゼンテーションは開発を複雑にします。

ツールキット

次に、開発者向けの方法とツールについて説明します。



従来の開発ツールの場合、多かれ少なかれ発明されたツール（リファクタリングなど）、プロジェクトのサイズ（通常はコード行）を評価できるメトリックと測定方法、テスト範囲、コード単位あたりの潜在的なエラー数、複雑さなどの要因コードなど、BPMに移行するときにこのことの多くを忘れることができます。 いずれにせよ、私はこの方向での仕事を知りません。 ある意味では、これは開発を何年もさかのぼります。 開発を正しく計画するには、再度リファクタリングすることを学び、プロジェクトの統計を収集し、プロジェクトの複雑さとサイズを評価することを学ぶ必要があります。



したがって、コード分析と自動リファクタリングのためのツールは実際には存在しません。 最悪の場合、そのようなツールの作成そのものが大きな問題です。 より伝統的なプラットフォームでのかなり典型的な開発シナリオを想像してください。 SVNやGitなどのバージョン管理システムがあり、開発環境（IDE）があり、他のツールがあります。 そのため、お気に入りのIDEが何かを知らない場合は、通常、その拡張機能を開発するか、サードパーティツールを直接使用してコードを操作できます。 たとえば、コピーアンドペースト検出器、またはその他のツール。これらのツールの多くの例は、UNIXの登場以来知られています。 これは、プログラムコードが伝統的に単なるテキストであるために可能になります。 任意のツールを使用して、変更したコードをGitに戻すか、単に必要な統計を収集してコードを分析するなどの方法があります。



BPMの場合、このアプローチは利用できないか、非常に限られています。 多くの日常的な操作を自動化することはできません。また、サードパーティの自動化ツールを開発するためのアクセスが常にあるわけではありません。 プロセスコードへのアクセスは可能ですが、理論的にはより可能性が高くなります-プロセスを一連のBPMNスキームとしてエクスポートし、コード分析用のさまざまなツールを使用できます。



その結果、プロセスダイアグラムの多くの要素のプロパティの均一な変更などの従来のプラットフォームでの些細なタスクは、Find＆Replaceのようなものではなく、手でしか実行できず、5分でこのツールを嫌う退屈なルーチンに変換されます。



さて、最後ですが、まったく重要ではありません。 より伝統的なプロジェクトの場合、作成されたアプリケーションのサイズを（たとえばコード行で）非公式に、またはCoCoMoなどのモデルに従って推定できる場合、BPMの場合は理解できない状況に陥ります。 少なくとも2種類のコード-ダイアグラムと、おそらく1つではない「通常の」プログラミング言語があります。 プロセス図を描くのにどれくらい時間がかかりますか？ 何に依存していますか？ 図の「サイズ」と複雑さを測定する方法は？ そして、通常のコードの場合、既知のモデルを使用して複雑さを評価できる場合、類似のモデルはダイアグラム用に構築されず、質問には答えがありません。

事前に構築されたコンポーネントと再利用のセット

プロセスを構築するために必要ないくつかのコンポーネント：条件、並列ブランチ、期待、イベントはもちろん存在します。 ようやく、そのレベルは非常に低く、組み合わせて、結果として完成したコンポーネントを再利用する可能性には、多くの要望が残されています。



開発ツールとプログラミング言語の進化の過程で、再利用可能なコンポーネントを作成する方法が長い間開発されており、多かれ少なかれ確立されています。 基本的には、これらのデータ型とこれらの型の機能、およびこれらの基本要素を完成したアプリケーションに構成する方法になります。



たとえば、標準のツールセットのみを使用して、プロセスのサイクルを整理してみてください。 まるで、プログラミングの本でブロック図を描いていた時代、つまり40年前にさかのぼるようなものです。 別の非常に典型的な、しかし些細なケースではないが、外部サービスとの非同期相互作用を整理する必要がある場合、つまり、彼にリクエストを送信してから回答を待つ場合です。 必要なロジックを実装できる場合でも、再利用されたコンポーネントを選択できないように実装がアプリケーション全体に散らばるので、別の同様のプロセスで再び使用できる可能性は低いです。 さらに、この場合の悪の根源は些細で表面にあります。BPMNには、FPの観点から「高次関数」と呼ばれるものが含まれていません。 またはジェネリック、OOPとJavaを思い出す場合。 リスト項目のタイプから抽象化して、リストをソートするなどの汎用コンポーネントを作成することはできません。 関数（アクティブコンポーネント）をパラメーターとして渡すことはできません。 それを呼び出す余裕がある場合、メタコンポーネントを記述する方法はありません。



今日、関数型プログラミングとOOPの形式の2つのパラダイムが優勢であると考えることができます。 BPMの場合、そのような進展はなく、理論の現状は率直に言って嘆かわしい。 実際、パラダイム自体すらありません。制限付きでの使用にのみ推奨できるいくつかのプラクティスしかありません。 さらに、関数型プログラミングは数学に基づいていると言い、場合によってはプログラムの正しさを正式に証明できます。また、OOPや手続き型プログラミングの場合は、BPMの場合はそのような作品について聞いたことがない場合でも、少なくとも部分的に正しさを証明できる場合があります。



プロセスのリファクタリングとテストのアプローチも定義されていません。 リファクタリングの概念さえありません。 ツールの開発者は、プロセスが完全に構築されており、決して開発されていないと信じているように見えます。 また、エラー、技術的負債、臭いなどはありません。



同時に、プロセスは多くの場合並列処理のセットであり、BPMシステムの外部で実行できないため、テストの作成も未解決のタスクです。 今日利用できるのはサービスのみをテストできるという事実にもかかわらず、これに使用できるツールは適切とはいえません。 プロセスの同期コンポーネント、プロセス自体をBPMNダイアグラムとしてテストするため（特に並列処理を使用）、作成者はツールを知りません（開発できますが、利用可能なAPIで十分ですが、これは簡単な作業ではありません）。

プロセスのバージョン管理のサポート

すべてのプログラムが開発中です。 プログラムが開発されない場合、おそらく不必要なプログラムです。 例外もありますが、非常にまれです。 これは、BPMプロセスがいくつかのバージョンを進化させて通過できることを意味します。 これらの変更を追跡する必要があります。 バージョン1のバグ修正と新しいバージョン2など、アプリケーションの2つのブランチを開発する場合があります。場合によっては、それらの変更を1つのバージョンにマージする必要があります。



なぜこれがすべてBPMに悪いのですか？



第一に、変更はほとんど見えません。 図の最初のビューはテキストではなく、写真です。 正方形、矢印、ひし形。 そして、通常は1次元であり、diff / merge / patchなどのあらゆる種類の操作が長い間定義されているテキスト形式の通常のコードと比較して、いくつかの新しい次元がここに追加されます。 たとえば、正方形の色の色、またはシート上の相対的な位置。 ダイアグラムの変更の一部がその動作に絶対に影響しないため、かなりのレベルの情報ノイズが発生します。



その結果、unixの時代から通常diffという単語と呼ばれるような、単純で明白な機能はありません。 プロセスの2つの異なるバージョンを異なる詳細レベル（つまり、アプリケーション、プロセス図、コンポーネント、図の一部、任意の言語のコード行）で簡単かつ自動的に比較することはできません。



せいぜい、あなたはそのようなそのような数、そのようなそのようなユーザーが特定の図を変更したことを知っています。 何が正確に、なぜ、そして実際に変更が何から成ったのか、あなたはそれを見つけることができません、またはそれは困難です。 使用できるのは、開いて（読み取り用）、特定のバージョンがどのように見えるかを確認する機能だけです。 ただし、このプロセスはまったく高速ではありません。 そして最も重要なこと-違いは見えず、どちらかのバージョンのコードが見えます。 違いのある場所を比較して理解することはあなたの仕事であり、それは完全に自明ではないことが判明しました。



そして、2番目のよく知られた機能はマージ、または少なくともパッチです。 彼女は事実上の欠落もしている。 変更をあるブランチから別のブランチに、あるバージョンから別のバージョンに転送することはできません。これには、選択的に、両方のブランチで行われた変更の保存が含まれます。 実際には、これはブランチからあらゆる意味を奪います。



したがって、ビジネスプロセスの柔軟性について話すときは、常に考慮したばかりの問題に留意する必要があります。 プロセスは自由に変更できますが、変更点を正確に知ることはほとんどありません。 そして、何かが故障した場合-原因の検索は、コードの長い発掘につながる可能性があります。



そのため、いくつかの問題をもう一度簡単に要約します。

• 視覚的モデリングとビジネスプロセスの実行-一部。 このモデルはアナリストにとって現実を反映しておらず、開発者にとっては不便です。
• 柔軟なビジネスプロセスを構築するための既製のコンポーネントのセット-いいえ。 コンポーネント作成ツールは不十分です。
• ビジネスプロセスのバージョン管理のサポート-一部。 手段が不十分です。

言い換えれば、BPMNダイアグラム形式のビジネスプロセスは非常に柔軟で理解しやすいとアナリストにとっては言えますが、ダイアグラムは開発ツールとして非常に限られています。

他の人はどうですか？

そのため、現在のプロジェクトでは、非常によく似た製品に出くわす必要がありました。 これはMS Business Intelligence Development Studioであり、開発しているのはSQL Server Integration Servicesです。 そしてこれは非常に特徴的です-他のタスクのために別の会社によって作られたこの完全に異なる製品は、何らかの方法で同じ目標を達成しようとし、まったく同じ問題に直面します。

• ETLプロセスの視覚的モデリングは、ゼロから作成するときに比較的うまく機能します。 バージョンを切り替えようとすると、見慣れた問題はBPMNの問題と同じです。
• また、プロジェクト内の検索とナビゲーションにも問題があります。
• 同じ初期状態で再利用可能なコンポーネントを作成します。 再利用はゼロに近い。
• また、プロジェクトで作業するためにサードパーティのツールを使用するリファクタリングでは、すべてが悪いです。

私は自分自身のためにどんな結論を出しました-それはかなり理解できると思います。 可能な限り、そのようなツールには近づかない。 BPMを使用した実践的な作業、またはSSISについて他の印象がある場合は、コメントでそれらについて話すことをお勧めします。議論がすべて役に立つことを願っています。