ワークフローツールの価値は何ですか？
私はワークフロー開発に不慣れで、本当に「全体像」をつかんでいるとは思いません。あるいは別の言い方をすれば、これらのツールは現在私の頭の中では「クリック」していません。
したがって、企業はプロセスを説明するためにビジネス図面を作成することを好むようであり、ある時点で、プログラムのようなステートマシンを使用して、図のようなラインやボックスからプロセスを実際に制御できると決めました。 10年後、これらのツールは巨大で非常に複雑になります（私の会社は現在WebSphereで遊んでおり、私はトレーニングに参加しました。その怪物です。Activitiのようなこれらのワークフローツールのいわゆる「ミニマリスト」バージョンでさえ、巨大で複雑ですが、WebSphereの獣であるほど複雑ではありません）。
このようにすることの大きな利点は何ですか？単純な線とボックスの図が役立つことは理解できますが、これらのことは、私が知る限り、現時点では条件付きプログラミングとループを備えたビジュアルプログラミング言語です。ここのプログラマーは、行とボックスのレイヤーでかなりの量の仕事をしているように見えます。
ここまで進んでいくのであれば、なんらかのスクリプト言語を使用してみませんか？人々はこれに風呂水で赤ちゃんを捨てましたか？ラインとボックスのことは不合理なレベルになっていますか、それともこのすべての価値を理解していないのですか？
私は本当に、このテクノロジーを使った経験のある人々がこれを擁護する議論を見て、なぜこのテクノロジーが役立つのかを理解したいと思っています。値はわかりませんが、これも初めてであり、まだ十分に理解していない可能性があります。
開発者の観点から見ると、これらの「ビジュアル」環境は扱いが難しいと言って間違いありません。私が使用しているSharePoint 2010ワークフローは、優れたエンタープライズソフトウェアの作成に関するすべてのベストプラクティスを破棄します。自動テスト、コードの再利用、読み取り不可能なソフトウェアなどはありません。標準のテンプレートよりも複雑なものは、維持するのが面倒です。 、あなたが経験しているように。
しかし、ビジネスの観点からすると、ワークフローには、少なくとも理論的には、大きなメリットがあります。 このホワイトペーパー から引用すると、自動化ワークフローの効率、説明責任、制御、および使いやすさにより、生産性が大幅に向上します。この自動化がないと、単純な承認またはオンボーディングプロセスがどれほど非効率になるかを想像してみてください。また、ワークフローを定義するという行為自体が、ビジネスプロセスを制御しようとする組織にとって貴重です。
ワークフローソフトウェアの現在の状態は、ビジネスの責任ではありません。彼らは自分たちの生活をより簡単にしたいだけであり、ワークフローはそれに最適です。私は主にIT部門を非難します。
- システムが実際にどれほど複雑で壊れやすいかについて、ビジネスに対してより透明性がないため。すべての複雑さを隠します。
- 直感的でシンプルなワークフローソリューションで「かゆみを掻く」ことができないため。これはおそらく、SharePointやSAPのような大規模なエンタープライズパッケージに対しては不当なものですが、そこにあるカスタムソリューションよりも優れています。
本当のメリットは1つだけですが、それでも大きなメリットがあります：懸念の分離。
したがって、プロセスオーケストレーションロジックがシステムに組み込まれる代わりに、外部構成になります。基本的には地図。これを（さらに）独立して変更でき、複数のプロセス、複数のバージョンのプロセス、複数のプロセスの複数のバージョンを同時に実行できます。これは、適切なソリューションではすぐに使用できます。
歴史的に、SoCの概念は何度も成功してきました-Unixの原則「1つのことをやって、それをうまくやる」から始まり、何度も何度も適用されます-ESBのような専用のサーバーコンポーネント、異なる永続化システム、キャッシング、負荷分散、監視、HTMLからCSSを分割するなど.
多くの場合、ビジネスプロセスとそのフロールールは、データ、UI「画面」、またはユーザー「階層」に直交しています。したがって、システムの他の側面とは別に開発および変更することは完全に理にかなっています。それが [〜＃〜] bpm [〜＃〜] が1990年代初頭に登場した前提でした。
それ以来、この概念をサポートするために多くのツールと言語が作成され、最もよく知られているのは [〜＃〜] bpmn [〜＃〜] -直接マッピングする「フローチャート」を作成するためのグラフィカル言語プロセスに。人々はその大規模で扱いにくい（語彙に100を超える記号がある）、そして S-BPM （5つの基本記号しかない）などの現代的なアプローチを推奨していると不平を言う一方で、現在の業界の慣習はBPMNまたはその派生物、サブセットまたは兄弟。
あなたはBPMNに満足していないようです：
ここのプログラマーは、行とボックスのレイヤーでかなりの量の仕事をしているように見えます。
しかし、それはそれほど悪いことではありません）その背後に理論があります。そして、バージョン2.0は1.0の欠点からいくつかの良い洞察を得ました。
ここまで進んでいくのであれば、なんらかのスクリプト言語を使用してみませんか？
命令型パラダイムとスクリプト言語が常に最良の答えであるとは限りません。おそらく宣言型言語（HTML、CSS、SQL、Drools、またはNginx、Graddle、Maven、Puppetなどの内部言語）で見たように、結果のコードは、「JavaまたはC++ "のような適切な言語。
あなたの他の点については：
私の知る限り、現時点ではビジュアルプログラミング言語であり、条件文とループを備えています。
イベントとトリガー を調べましたか？ BPMNは言語であり、使用する前に学習するか、少なくとも慣れる必要があります。
内部的には、BPMNはXMLであるため、手動で編集または生成できます。 XMLはテキストベースであるため、バージョン管理が可能です。しかし、フローチャートに変換できるXMLを用意するだけで、そのgoonaがあなたを助けているように聞こえません。それは正しいです。独自のパーサーまたはエディターを作成することは、困難で費用のかかる作業であり、疑問の余地があります。
幸いなことに、市場にはすでにそのためのツールがあります。
Activitiは無料であり、初期価格が（zero）、情報と謙虚さの可用性。最後のポイントは本当にユニークです。Activiは、パッケージ全体のソリューションに縛られることなく、ビジネスプロセスの管理にのみ焦点を当てているからです。また、そのオープン-JavaとRESTを起動して実行するには、知っておく必要があります。欠点は、クライアント側、統合、アプリケーション/ビジネスロジックとアーキテクチャ全体は開発者に任されているので、開発チームが弱い場合-失敗に備えます。freeツールの総所有コストは驚くほど高くなる可能性があります;）
スペクトルの反対側にはPega（Pega PRPC）があり、Bartシステムの支配的な王（GartnerとForesterによる）は驚くほど良いように見えますその年齢。このキッチンシンクの巨人は、CRM、OCR、および（誤解しない限り）音声認識機能、予測分析、ビジネスルール管理、およびWYSIWYG UIエディターにも対応しています。しかし、それは深刻な値札が付いています。コストがかかるだけでなく、すべての開発はWebアプリ内で行われます。つまり、IE8であるブラウザーを使用する必要があります（さらに、いくつかのプラグインと、データテーブルの編集にExcelを使用するような醜いハック）。また、Java、Javascript、またはHTML/CSSの編集もWebブラウザーを使用して行われています。ユニットテスト、IDEコードの強調表示、リファクタリング、そして好きなプログラミングおもちゃすべてに別れを告げてください。 。
それの良い面は？複雑なシステムをウィークインで実装できます[ [〜＃〜] pdf [〜＃〜] 、22ページを参照]。そして、はい、結果は保証されません。
[〜＃〜] ibm [〜＃〜]は、最近（企業のタイムペースに応じて）ロンバルディを購入し、非常に競争力のあるサービスを提供しています解決策（ただしの場合を購入する必要がありますすべてibm、ご存知です）。 Appianは、興味深い洞察と肯定的なフィードバックを持つ若いベンダーですが、それらの記述方法（視覚的な言語に加えて2つの追加のDSL言語）はありません。私にアピールします。
他のプレイヤーとその解決策があります。 それらのほとんどはひどいものです。同様に、あなたの目、脳、心臓は、単にそれらを見ただけで、文字通り出血します。だから、あなたの内臓を信頼し、あなたの開発者やユーザーがあなたを嫌うようにしないでください。
結びの注記：
BPMシステムは、Photoshopが画像を処理するプロセスと同じです。そのビジュアルを恐れないでください。それに適さない仕事をさせないでください（Photoshopで完全に作成されたWebサイトを覚えておいてください。シンプルに保ち、バグを作成しないでください;）
数年前、私たちのほとんどが生まれる前に、ソフトウェア開発者はデータを格納するために独自のコードを書かなければなりませんでした。プログラムの状態を保存する必要がある場合、それはコードの機能の一部と見なされていたため、多くのソフトウェア開発者がデータを整理し、保存して読み取るためのコードを作成してしまいました。
そして、誰かがこれが頻繁に起こったことであることに気づきました-つまり、データを保存、整理、読み取り、検索するロジックは、実際には非常に一般的に使用されるコンポーネントであり、それ自体がコンポーネントであるはずです。そして、データベースを取得しました。
過去10〜15年間で、IT部門は、ビジネスプロセスのコレオグラフやオーケストレーションを行うロジックが非常に一般的であるため、独自のコンポーネントである必要があることを認識しており、さまざまなワークフローツールにつながりました。
ワークフローツールには、主に3つの利点があります。
- 変更を加えてデプロイするのに必要な時間：コードの一部を変更する場合と同じ技術的リスクなしに、ワークフローのロジックを開発および変更できます。
- 透過性：BPMベースのシステムのビジネスロジックは、ビジネスアナリストがすぐに利用でき、読み取り可能ですが、「コードベース」のシステムでビジネスロジックを読み取ることができるのは開発者だけです。
- 技術コンポーネントの再利用：BPMツールは、サービス指向アーキテクチャを持つシステムと組み合わせて使用されることがよくあります。ビジネスロジックを技術コンポーネントから分離することで（特に数百または数千の異なるビジネスプロセスを実装する必要があるエンタープライズシステムの場合）、ビジネスロジックの開発に比較的少ない時間を費やしながら（ワークフローを使用して）技術コンポーネントを再利用できます。ツール）。
ただし、ワークフローとBPMツールの使用で私が遭遇する最も一般的な問題の1つは、開発者が非透過的なコードにビジネスロジックを「埋め込もう」とすることです。
私が見ているのは、常に、開発者が可能な限り最も透過的な方法ではなく、可能な限り最も技術的な方法でビジネスロジックを追加しようとしていることです。開発者は本来、ワークフローツールよりもコードにはるかに慣れているため、これは自然なことです。さらに、技術的な方法で保持するロジックが多ければ多いほど、開発者として必要になるものも多くなります。残念ながら、これは開発者がBPMシステムに対して行うことができる最悪のことです。なぜなら、彼または彼女はBPMを使用することの主要な利点を下回っているからです。
最後に、ほとんどのBPMツールは、ビジネスアナリストがワークフローを自分で開発するには十分ではありません。しかし、それが目標です。理想的には、ビジネスアナリストはワークフロー/ビジネスプロセスダイアグラムを開発し、開発者はワークフローエンジンによって呼び出される技術コンポーネントのみに取り組みます。
以下の説明は、ワークフローツール、特にOracle BPM Suite（10.3G＆11G）を使用した私の個人的な体験です。まず最初に、あなたの質問は実行可能なプロセスモデルのモデリングを可能にするワークフローツールに焦点を当てています。これらのツールはビジネスプロセス管理システム（BPMS）の一部です。この特定のプロセスモデリングは確実に発展しており、ビジュアルプログラミング言語と呼ぶことができます。
主な利点は、プロセスロジックの理解と変更の俊敏性です。
ビジネスプロセスモデルでは、プロセスロジックの視覚的な説明と、同時に実行可能な統合コンポーネントをカバーします。開発の一部であるため、ドキュメント化する必要のある遷移、条件（ゲートウェイまたはビジネスルール）およびプロセスフローに関するドキュメントが少ないため、これにより、プログラマーのオンボードおよびオフボーディングがより高速になります。
さらに、ほとんどのBPMSでカバーされる、アプリケーションごとに個別に開発する必要があるレポート/監視機能をアタッチしました。
さらに、ほとんどのBPM開発環境では、サービスアダプターが事前に構築されており（JMS、Webサービス、JDBCなど）、ミドルウェアソリューションをより速く開発することができます。インタラクティブな統合をステップし、コーディングにおける人的エラーを減らします。
以下のワークフロープラットフォームは、上記の多くの利点を実現します- ワークフローの自動化のためのプラットフォームベースのアプローチ
値
価値ある提案は、ビジネスの変化する性質に合わせてワークフローをすばやく簡単に作成または変更できることです。この価値命題を実現する上で重要なのは、ビジネスプロセス自体がシステム内のリソースの単位であることです。
リソースの単位としてのワークフローは、ビジネスプロセスが単一の「単位」として定義されることを意味します。これが私が何を意味するのかを理解するために、企業向けに作成されたコンピュータープログラムを検討してください。確かにビジネスプロセスを実装していますが、そのプロセスのロジックはある程度ソースコードの周りに広がっている可能性があります。ワークフローツールは、プロセスを1つの適切な場所に定義できるようにする必要があります。単一の構成ファイルに含まれていたり、1つのビジュアルダイアグラムから抽出されていたり、ワークフローがプラグイン可能な単一のコードモジュールにあることを意味している可能性があります。
なぜ価値が実現されないのか
この価値命題は、Vanilla以外のケースをカバーすることの難しさ、非常に急速に変化するUIテクノロジーとの統合、ワークフローツールをラッパーとしてのみ使用する、実際のロジックをとにかくコード化するなどの悪い習慣によって損なわれる可能性があります。
ツール自体の設計の悪さが制限要因になる可能性があります。例としては、プロセス間で渡されるすべてのパラメーターがJavaマップ内にあることを必要とするツールです。単純な古いメソッドパラメーターではなく、実際にマップに配置できる値に制限があります（私はこれを行う特に人気のあるツールの1つを考えています。
IBMは、大規模なテクノロジーエコシステムを備えたビッグプレーヤーとして、他のものよりも公平であると言っても、おそらく公平だと思います。 UIテクノロジー、データベース、およびワークフローツールと組み合わせて使用されるSOAテクノロジーも制御している場合、うまく統合できるエコシステムを思い付く可能性が高くなります。このアイデアを実際に利用する機会を作ります。
ワークフローツールとシステムの他の部分との間のインターフェイスを作成する努力が、価値提案全体を完全に打ち消す可能性があることは間違いなく真実です。物事を行うためのより良い方法があるかどうかは常に検討する価値があります。
プログラミングはワークフローです
真実は、プログラミング（少なくとも命令型言語で）IS WORKFLOWです。システムテクノロジーの処理、ファイルへのアクセス、SQLクエリの実行などに関連するワークフローを実装するコードがあるかもしれません。たとえば、ビジネスワークフローを実装するコードがあり、ドキュメントの状態を設定し、それをたとえばレビュー担当者に渡すとします。
これを認識して、これらの個別の懸念を明確に分割するようにコードを設計することは、完全に取り除くことは困難ですが、それだけで確実に長い道のりを歩むことができます。
私もあなたに同意します。他の誰かがそれを良いアイデアだと判断したため、これらのツールを使用することもあり、それらは複雑すぎて私たちの仕事を難しくしています。いつもそうだとは思いませんが、それが価値があるかどうかを判断するには、慎重な検討が必要です。