第二に、サービスはビジネスプロセスの一部（サブプロセス）を表現していることが多い。例えば、「顧客情報の照会をするサービス」「請求書を発行するサービス」などだ。オブジェクトやコンポーネントがどちらかと言えばシステム側の都合で構成されるのと対照的に、サービスは「業務の視点」で構成されることが多い。ただし、業務と直接関係のないシステム的なサービス（例えば、「データのバックアップを取るサービス」など）が構築されることもある。
このことから、SOAとBPMの相性は極めて良いということが言える。SOAにより、ビジネスプロセス（を実装するソフトウェア）を部品化し、BPMでそれを組み合わせ、ワークフロー管理することで自由度の高い業務システムを構築することができる。業務に新しい手続きが追加されたり、一部の手続きが変更された場合にも、アプリケーションを全面的に更改する必要はなく、一部のサービスを取り替えたり、ワークフローの定義を変更するだけで対応できることが多いというわけだ。「ビジネスコンポーネント指向ソフトウェア構築手法」とでも言えば、SOAをより適切に表現できるかもしれない。もちろん、既に定着したSOAという言葉をやめろと言っているわけではない。SOAという言葉を聞いたときに、頭の中で翻訳して考えればよいということである。
SOAを適用するメリットと課題
では、SOAにはどのようなメリットがあるのだろうか。この答は簡単だ。SOAを使用しない一枚岩型の情報システムがどのようなデメリットをもたらすかを考えてみればよい。共通機能を部品として切り出すことなく開発すれば、企業内の全システムのいたるところで同じような機能が開発される「多重開発」の状況が生まれる。これは、生産性を悪化させるだけではなく、情報システムの柔軟性を大きく損なうことになる。ひとつの要件変更に対してシステムの複数箇所を修正しなければならなくなるし、修正の影響を把握するのが困難になるからだ。サブルーチンを全く使わずにコーディングをすれば、どれほどひどいプログラムができてしまうかを考えれば、SOAを全く使わずに企業情報システムを構築することがどのような問題を引き起こすかを理解することは容易だろう。
このようにSOAの考え方自体は単純なものであり、その価値も明確だ。しかし、現実にSOAを情報システムに適用するには、さまざまな課題がある。代表的なものとしては、トランザクション（データの整合性）、性能への影響（遅延の問題）、データの意味（セマンティクス）の非統一の問題などがある。
上記の問題はSOAが登場したことによって生まれた問題ではない。SOAが存在するより前から情報システム構築の課題として存在していたものだ。ここで重要なのは、SOAがこれらの課題を自動的に解決してくれる魔法の杖ではないという事実だ。
SOAの基本的概念はある意味当たり前のものであり、オブジェクト指向プログラミングがそうであったように、今後、企業内情報システムの中に段階的に普及していくだろう。その意味では、SOAを単なる流行語と考えることは適切ではない。ひょっとすると、数年後にはSOAという言葉をIT業界で聞かなくなっているかもしれない。もし、そうなっていたとしたら、その理由は、SOAが重要でなくなったためではない。SOAがあまりに当然の存在になり、あえて名前を呼ぶ必要もなくなったということなのである。
