SOA を導入すれば、今までのビジネスとIT の課題はすべて解決できるとか、ESB を導入しさえすればSOA は構築できるというような、極端な議論は少なくなりつつある。これはSOA に対する過度の期待が収まり、実像をとらえた地道な取り組みがされ始めてきた証左と言える。本論では本来のSOA の考え方と意味を解説した上で、アーキテクチャの視点からSOA の意義について述べていく。
なぜ今、SOAなのか？
SOA（サービス指向アーキテクチャ）が注目されている背景の中心には、経営（ビジネス）側と情報システム部門（IT）側の、情報システムに対する不満や課題がある。SOAを導入することによって、これらの課題が解消されるのではないかという期待からである。
経営側は、「ビジネス環境の変化のスピードに情報システムは適応できていない。新しいことをやろうとしても、IT部門は『金がかかる』、『時間がかかる』とばかり言って、経営の方向性・必要性を理解しようとしない。場合によっては、IT部門は経営の阻害要因になっている」と考える。
それに対して、IT部門側は、「そうは言っても、経営側のニーズに精一杯対応して努力してきた。十分な時間がもらえない中で、なんとか時間に間に合わせようとすれば、その場限りの対応にならざるをえない。しかしそれらの対応が、結果的には情報システムを複雑化させ、変化に適合しにくい構造をもたらしている。経営側はそれらの努力をまったく評価しないで、不信感ばかりあらわしている」ということになる。
このような状況を打破する手段として、変化に継続的に対応できる柔軟性を持ち、旧システムの機能を生かしながら、新たなビジネスプロセスに適合できそうな概念（技術）だという期待から、SOA に対しての関心が高くなってきた（図1）。
詳しくは後述するが、SOAの特徴は、アプリケーションの機能をサービスコンポーネント化することにある。図中の「柔軟性」とは、サービスコンポーネント単位で組み合わせることによって、必要なアプリケーション機能を実現することを意味する。「再利用性」は、サービスコンポーネントを必要とするアプリケーションで共用すること。「拡張性・統合性」は、ネットワークで接続されている環境内であれば、呼び出すサービスはどことでもデータ連携を実現できることを意味する。
