10

ビジネス プロセスを実装する場合、(開発者の観点から) どちらを優先しますか?

ビジネス プロセス管理システム (BPMS) ですか、それとも必要なツールとフレームワーク (レポート ツールなど) を備えたお気に入りの IDE ですか?

個人的なツールやフレームワークを備えた IDE と比較して、BPMS の最大の利点は何ですか?

わかった。もっと具体的に言う必要があるかもしれません...ルールを構成することでビジネスプロセスを簡単に実装できる特定のBPMSを知ることができました。しかし、開発者としての私にとって、システムを操作するのは難しいことです。リファクタリングできるテキスト ファイルで作業したいと考えています。また、自分がしなければならない仕事に適したテクノロジまたはフレームワークを選択できるようにしたいと考えています。代わりに、システムは私に構成を強制します。

Java を使用できるルールはありますが、それでもインテリセンスなどを使用せずにシステム エディターに固執する必要があります。

したがって、これは私自身の質問の答えにつながります-BPMS（少なくとも私が知っているもの）の操作方法を学ぶ必要があるのではなく、慣れ親しんだツールを使用したいと思います。 . 私が知っている BPMS は、抜け出すのが難しいフレームワークです。現時点では、私が知っているどの BPMS よりも、Grail のようなフレームワークを好みます。

より具体的な質問は、あなたも同じように感じていますか、それとも開発者であることをサポートし、開発者のように考える BPMS がありますか、それともほとんどの場合、別の方法で仕事をするように強制されますか?

4

4 に答える 4

13

私の経験では、BPMS システムが提供する開発環境は三流で非生産的であり、(制限があるため) 保守が難しく、設計が不十分なコードを書くことを実際に強いられます。私がよく知っている BPMS システム (データベースにちなんで名付けられたその会社によって販売されているもの) によって提供されるほとんどすべての「機能」 (UI、統合など) は、私たちが支払ったお金の価値がありませんでした。

開発者として BPMS を使用せざるを得ない場合、私のアドバイスは、Java や .Net などの従来の開発環境でできるだけ多くのアプリケーションを構築し、BPMS 環境自体で構築するものをできるだけ少なくし、統合することです。二つ。BPMS に入れる必要があるのは、ビジネス プロセスを機能させるための最低限のことだけです。

于 2011-08-04T04:12:41.130 に答える
8

私は過去に Biztalk と仕事をし、最近では JBPM と仕事をしました。私の意見は、次の理由で BPM に対して偏っています。

  1. 急な学習曲線: プロセスを機能させるには、システムとエディターがどのように機能するかを理解する必要があります。ビジネス ユーザーはもちろん、開発者がシステムを理解するのは非常に困難です。ドラッグ アンド ドロップと視覚的な表現は、優れたデモ ツールです。確かにマネージャー (最終的にはお金を払う) は感銘を受けますが、開発者の生産性は低下するだけです。

  2. ワークフローを変更する非開発者: 1 つの BPM ソリューションが完璧にそれを行うのを見たことがありません。コードのようには見えませんが、ボックスを右クリックしてコードを入力する必要があります。そうしないと機能しません。したがって、それを行うには間違いなく開発者が必要です。最良の部分は、開発者向けでもビジネス ユーザー向けでもなく、デモ ユーザー向けであるということです。

  3. テスト可能性とリファクタリング: BPMS をテストすることは事実上不可能です。「単体テスト フレームワーク」が宣伝されていますが、それらのほとんどはハックであり、使いにくいものです。最近、JBPM を試しました。それを機能させるために、多くのグルー コードと偽のワークフロー ハンドラーを作成することになりました。ただし、私にとっての取引ブレーカーはリファクタリングです。ビジネスが根本的に変化する場合は、ビジネス プロセスがどのように見えるべきかを考えなければなりません。ボックスを再配置するだけではうまくいかないため、ボックスにバインドされているすべての変数も再配置する必要があります。ビジネス プロセスをリファクタリングするために、IDE とテストの機能を活用したいと考えています。

アプリケーションにワークフローがある場合は、ワークフロー ライブラリを試すことができます (永続状態の有無にかかわらず)。BPM に伴うすべての肥大化なしにワークフローを管理します。ビジネス ユーザーがコードを理解する必要がある場合は、ビジネス ユーザーに適切なプロセス フローチャートを準備させ、それを適切なドメイン駆動型コードに変換してもらいます。きゅうりスタイルの受け入れテストを使用して、開発者とビジネスを結び付けます。BPM とは、あまりにも多くのことをしようとして、それらすべてをうまく実行できなくなってしまうものです。

于 2012-12-08T18:45:33.883 に答える
7

何を尋ねているのか正確にはわかりませんが、BPM とプレーン プログラミングのどちらを選択するかは、要件によって異なります。「ビジネス プロセス」は、ソフトウェア エンジニアリングでは比較的あいまいな用語です。

ニーズを評価するためのいくつかの基準を次に示します。

  • ルールの複雑さ- プロセスに具体化された決定/ルールは、シンプル、複雑、構成可能、ハードコーディングされていますか?
  • プロセスの変動性- プロセスはどのくらいの頻度で変更されますか? 誰が変更を行うことができますか?
  • 統合の必要性- プロセスは複数の異種サービスを使用して実現されていますか、それともすべてが同じ言語で実装されていますか?
  • 同期/非同期- 非同期アクションを処理する必要があるプロセスが「長時間実行」されていますか?
  • ヒューマン タスク- あなたのプロセスは、役割/責任に応じてタスクが人に割り当て/ルーティングされ、人とのやり取りを伴いますか?
  • プロセスの監視- 実行中の既存のプロセス インスタンスに対して必要な制御のレベルは? アクションなどを監査する必要がありますか?
  • エラー処理- これまでのポイントに応じて、エラーにどのように対処するか、または失敗したプロセスの実行を再試行する予定ですか?

これらの質問への回答に応じて、プロセスがいくつかのアクションと決定を連続して実行できる単純な状態図に近いことに気付くかもしれません。自分ですべてを再実装したくありません。

単純なプログラミングと本格的な BPM ソリューション( BPELやルール エンジンなどを含むOracle BPM スイートなど) の間には、jBPMやWindows Workflow Foundationなどの中間的なソリューションや、おそらく他にも多くのソリューションがあります。これらの中間ソリューションは、多くの場合、適切なトレードオフです。

于 2009-12-22T15:41:35.063 に答える
5

BPMS -- 多くの一般的なビジネス ケース、ユース ケースが既に実装されています。したがって、その使用方法を知る必要があります。一般的なワークフローの場合、コードを 1 行も記述する必要はありませんが、ほとんどの場合、まだ実装されていないものをカバーするためにいくつかのスクリプトを記述する必要があります。

単純なプログラミング -- IDE を使用してコードをハックするだけです。良い面: より多くのコントロール。ネガティブ？定型コードの書き直しには多くの時間が費やされます。そして、あなたはそれらを維持しなければなりません。

一言で言えば、私はビジネスプロセス管理システムを好みます。私がお勧めするのはProcessMakerです。ドラッグ アンド ドロップでワークフローを設計できる直感的なプロセス デザイナーを備えています。また、プロセス機能を拡張するトリガーをいつでも作成できます。こちらもオープンソースです。

于 2009-12-22T15:25:53.923 に答える