一般の業務アプリケーションにはビジネスプロセスが組み込まれていない。

 ワークフローをベースとしたシステム構築を行っていると、必ずと言っていいほど、既存の業務アプリケーションの画面をワークフローから呼び出せないかとか、業務アプリケーションからワークフローをコントロールできないかという要望が出てくる。ワークフローで定義する業務(ビジネスプロセスの中の一つのアクティビティ)は一般的には業務アプリケーションにおける○○画面の操作ということがよくある。例えば注文書の受理というアクティビティは、業務アプリケーションの注文情報入力画面の操作ということになる。わざわざワークフローで画面を作成してプログラムを作って、業務アプリケーションのデータベースに必要なデータを書き込んでいたのでは、重複開発をしていくことになる。
 なぜ、このようなことが起きてくるのであろうか。ほとんどの業務アプリケーションがきちんとしたDOAで設計されることなく、データを蓄積する容器としてデータベース設計を行っているからである。プログラムは○○情報の入力・更新・参照機能といったデータベースへのアクセスプログラムとして設計されている。注文情報の入力機能ということになってしまう。それでは業務であるところのビジネスプロセスはどのように実装されているかといえば、ユーザがどのプログラム(たいていは画面である)を選択して、どの順番で操作するかを考えて行うことで実装されているのである。つまりビジネスプロセスは実装されていないのである。プログラム(画面)やデータへのアクセス制御をしている程度である。
 大半のSE、設計者は業務流れ図やDFDを書くことができない、というよりも経験がほとんどない。そんなことはないと思いたいのであるが、EA(Enterprise Architecture)でBA部分の業務を記述できるSEが極めて少ないし、内部統制で業務流れ図を書けるSEもほぼいない。データベース設計とそのアクセスプログラムしか設計してこなかったのであるから当然と言えば当然である。
 冒頭の話に戻ると、ユーザが求めているものはビジネスプロセスが実装されたシステムである。しかしながら業務アプリケーションに実装されていないので、これをポータルに求めた時もあった。ユーザがログインすると、行うべき画面に導いてくれるというものである。しかしそのようなポータルができることはなかった。そもそもビジネスプロセスを管理できていない業務アプリケーションをコントロールすることはできない。現実解としては、既存の業務アプリケーションはできるだけ手をいれないで、外部にワークフローシステムでビジネスプロセスを実装して、そこから業務アプリケーションの画面を呼び出し、必要なデータの受け渡しを行うことである。