SOAのバリューをITの側面から眺めてみましょう。
ここでは「時間」「空間」「リソース」の3つの軸を用いて整理してみたいと思います。
まずは「時間」から。

• リアルタイム性向上
  SOAでは，Webサービスのような標準プロトコルを用いてシステム間の連携を行います。これにより，マニュアル入力による連携やファイル転送を用いたバッチ連携が必要であった箇所を，リアルタイムで連携させられるようになります。
  リアルタイムで連携できるようになれば，一連の処理を完了するまでにかかる時間を短縮できます。例えば，物品の購入プロセスにSOAを適用した場合，与信チェック，在庫確認，納期回答，会計処理，出荷指示…といった一連の処理をその場で完了する，ということも可能になるわけです。
  また，リアルタイムで更新される最新のデータを参照しながら，迅速にビジネスの状況を判断し，対応できるようになります。このときBAM（Business Activity Monitoring）ツールを有効に活用できます。
• ビジネス・サービスの改善
  SOAでは，ビジネス・サービスの組み合わせによってビジネス・プロセスを実現できます。ここで「疎結合」というSOAの原則に従ってビジネス・サービスを構成しておけば，もし時間とともに状況が変化して，あるビジネス・サービスに対する要件が変化しても，他のビジネス・サービスに影響を与えることなく，そのビジネス・サービスを変更，改善できるようになります。例えば，上述の購入プロセスで，与信チェックに人間が関与していたものを，自動チェックに変更するような場合でも，その他の一連の処理には全く影響を与えずに済みます。
• ビジネス・プロセスの改善
  SOAのBPM（Business Process Management）機能を用いれば，ビジネス・プロセスをBPELのようなビジネス・プロセス実行言語で定義し，そのまま実行できます。
  ビジネスの状況変化などに従って，ビジネス・プロセスがビジネス実行上のボトルネックになってしまった場合，BPM機能を用いると，ビジネス・サービスの組み換えによってビジネス・プロセスを改善させることが可能になります。
  例えば，上述の購入プロセスで，全ての与信チェックに常に3段階の承認が必要だったものを，一定金額以下であれば1段階の承認で済ませる，というような変更も，BPMツールを用いて容易に行えるようになります。
• ライフサイクルの異なるシステム群の共存
  企業のシステム全体を考えた場合，通常，そこには複数のシステムが存在します。そうするとシステム毎に稼動開始時期や稼動期間が異なってきます。例えば，10年前から稼動しており2年後には稼動終了が予定されているレガシーシステムと，今後5年間使用する予定の新たなシステムを連携させなければならない，というような状況が当然発生します。
  SunのSOAでは「wrap and reuse（隠蔽して再利用）」を大原則としています。このような場合には，レガシーシステムを隠蔽してビジネス・サービスとして機能，インタフェースを公開するようにして，新規システムと連携させます。そして，2年後にレガシーシステムが引退する際には，ビジネス・サービスのインタフェースはそのままで，実現手段をレガシーシステムから最新システムに（あるいは外部のサービスに）変更する，ということで対応します。

ここで一つ注意ですが，SOAは（SOAに限らずどんなテクノロジーでも）万能ではありませんし，SOAで言われている全ての機能を使用する必要もありません。例えば「SOAではBPELによるビジネス・プロセス実行という処理が余分に増えるから性能が劣化する」というような声も聞かれますが，それは正しくないと考えています。というのも，BPM/BPELを使用しないSOAも可能だからです。この辺りは，機能要件やサービスレベル要件のトレードオフになります。ビジネス・プロセスの変更がそれほど頻繁ではなく，性能がクリティカルな場合にはビジネス・プロセスのロジックをプログラムで作り込めば良いのです。正にアーキテクトの真価の発揮しどころですね。