開発プロセスと管理プロセスを区別しなければならない。そして、管理のために成果物を要求してはならない。つまり、開発成果物から管理プロセスは管理すべきである。このため、SOAでは、管理プロセスについては言及しない。
さらに、SOAにおいて、開発プロセスは規定しない。なぜならば、要件定義において、業務フローと業務ロジック（ルール）が明らかになればコード生成可能であるからである。明確にできない場合は、その不明確な度合いに応じて、プロセスをプログラムする。もちろん、このプログラムの手法にアジャイル手法が有効なのはいうまでもない。
問題はプロセスなり作業手順をプログラムできないとメンバがいることである。このようにメンバは往々にして杓子定規にプロセスを実施しがちで応用力に欠ける嫌いがあるので注意が必要である。そこでこれらのメンバには、ガイドラインとしてのプロセスを提示する。
ガイドラインとしてのプロセスは、以下の成果物を作成することであり、下に行くほど、抽象度が高く、明確さに欠ける。したがってどの成果物において、不明確であるかを抽象度を考慮した上で、識別し、詳細化する。つまり、要件定義から直接、クラス図を書いたり、ER図を書ける、さらにはコーディングできるメンバがいるならば、成果物は省略できる。
・ソースコード、実行可能ファイル
・データベーススキーマ(ERD、CRUD表、データ定義書兼画面項目定義書)
・業務ロジック定義書
・要件定義書兼検収要件書（ユースケース、業務フロー図）
クラス図はER図を作成する際の補助資料、シーケンス図は業務フローの整合性を確認するための補助資料なので必要がなければ作成しない。
これらの成果物を作成するためには、以下のプロセスを推奨する。
業務フロー図(IDEF0)
↓
ユースケース（図）
↓
ロバストネス図-------------------------
↓ ↓ ↓
シーケンス図←→クラス図←→ ER図
↓ ↓ ↓
画面遷移図 ↓ ↓
↓ ↓ ↓
画面項目定義書 業務ロジック定義書 データ項目定義書
(ルールマッピング) (ORマッピング)
↑ ↓
+------------------------------+
図がうまく表示できん
