今日のSOAに関する文献や実装の大部分は、ビジネスに寄ったサービスを定義することに集中しており、SOAの文脈において企業データが持つ役割や影響について議論したものは、ほとんど無い。 David Linthicum氏によると、
SOAに対するこのような動きは、SOA内でのデータの使用によって少々混乱しているように思えます。大方の人は、データは単にデータだと考えていますが、内情に通じている人は、SOAがプロジェクトとして、あるいは全体のアーキテクチャ上の戦略として、成功するためには、データは、SOAの戦略的な部分である必要がある、と理解しています。SOAの"S"すなわちサービスばかりに注目すると、問題が生じるわけです。アーキテクチャやシステムの構築に責任のある人達は、サービスを、機能を配送するものとしてのみ捉え、根底のデータを管理する必要性を無視しています。多くの場合、データの質や一貫性の問題がすぐに持ち上がってきます、根底のデータが変わった直後に、サービスを変える必要があるため、SOAが本来提供するはずの機敏性も限られてしまいます。
SOAの土台として、データ統合の重要性についてのDavid氏の意見は、Ash Parikh氏により、最近のブログの記事で詳しく説明されている。
インフラをサービス指向にする努力は、データ統合に注目することから始めなくてはならないことが、ますます明らかになってきました。スピードと機敏性を重要視するインフラを構築したいなら"データ統合"を第一に考える必要があります。もしあなたがインフラをサービス指向にしたいなら、土台が次の能力をもっているかどうか確認するために、５つのチェックを行い、あなたは、まずデータ指向になることを勧めます:
- すべての関連するデータに簡単にアクセスできる。新規の、あるいはすぐ変化するデータソースに対しても。
- バッチであるいはリアルタイムにデータ処理できる。大ボリュームの大きなデータセットも処理できる。
- 不正確なデータや一貫性を欠いたデータを積極的に特定し、解決する。
- 複雑なデータ変換ができるアプリケーション。
- 標準に基づいたデータサービスとして、必要な時、即時にデータが配送される。
Ash氏は、 続きの記事で、サービス指向のインフラをデータ指向にする実際的な手法について述べている。氏は、企業にとってデータ統合の問題を全体的に解決するいくつかの模範的な推奨項目を概説している:
- まずデータ統合のプラットフォームは、企業の組織（構造化されたものであれ、されていないものであれ）とアクセス方法（SQL、API、webサービスなど）に関わらず、すべての企業のデータソースに"標準化された"アクセスが可能になるべきである。このプラットフォームの拡張性すなわち、即座に新しいデータソースを加えたり、既存のものを修正したりできることを保証しなければならない。
- しかるべきプラットフォームは、効率的に、データ処理の待ち時間をサポートし、バッチ処理で、ほとんどリアルタイムにあるいは、データ収集を変更してリアルタイムに処理できることを確認する。
- 様々なデータアクセスのパターンを理解する必要がある。比較的小さなデータセットの大量のデータ、大きなデータセットの大量データ、非常に大きな（メガ）のデータセットなど、そしてこれらすべてが選んだプラットフォームによりサポートされてなくてはならない。必要であるなら、他の技術によって補わなければならない。
- サービスによって消費されるデータと生成されるデータは、サービス間で一貫性が保たれていることを確認する。多くのデータ プラットフォームは、どんなに複雑でも、積極的に問題を見極め、そして解決するために、統合したデータ プロファイリングを提供している。
- データ アクセスに加えて、データ プラットフォームは、典型的には、データ変換を行う中心である。単純な形式であれば、昨今のデータ統合プラットフォームは、サポートすることができる。しかし、もしもっと複雑な変換が必要な場合、例えば、アグレゲーション（集約）、ジョイン（結合）、ルックアップ、構造変換などの場合、おそらくもっと複雑なものが必要になる。
- 典型的なデータ統合のプラットフォームは、サービスの実装で必要となる、複数のアクセス方法をサポートする必要がある。例えば、SQLベースのアクセス、webサービス、RESTサービスなどである。
- データ統合のプラットフォームは、サービス実装が、根底にあるデータソースから独立したものでなければならない。要するに、抽象的な層を持ち込み、データ層における変更が、サービス実装に全く影響しないか、あるいは、最小限の影響で済むようにしなければならない。
まとめると、データプラットフォームは、
... これまでに概略したすべての能力を提供できる、単独の統合されたプラットフォームである必要がある。これらのすべての推奨事項は、時間とコストを考慮して、実現されるならば、意味がある。これらの個々の能力のために別々の技術が使われたとしたら、単純性と柔軟性によって機敏性を生み出す、サービス指向の手法を採用するという、まさにその根底が妥協したものになってしまうだろう。[この]プラットフォームは、データ統合するロジックの再利用をサポートし、後押ししなければならない。
SOA実装の範囲が、限られた部門向けソリューションから企業全体に拡大していくと、企業データへのアクセスの課題が、直ちに、最も重要な実装上の課題の一つとなり始める。本当に最初から正しくアーキテクチャ設計がされていないと、企業データへのアクセスがやがて重要問題になり得る。