大部分のSOA設計テクニックは企業のIT資産を機能的に分解することに集中しており、SOAの情報面については後からの思いつきとして取り扱うことが多い。情報へのスケーラブルで、矛盾のない、再利用可能なアクセスを完全にサポートするためには、実は、SOAソリューションには情報アーキテクチャのベストプラクティスを反映させた、より広範囲にわたった設計上の懸念事項一式を入れる必要がある。Brian Byrne、David McCarty、Guenter Sauter、Peter Worcester、John Klingは発表したばかりの論文の中で(リンク)、SOAの設計における情報の考え方を説明するパターンと機能一式を紹介している。この5人のアプローチにより、SOAソリューションの技術上、ビジネス上の目的を最適に支援する以下のようなやり方で、情報が活用されることが確実になる。
- 企業全体にわたって、サービスの再利用が可能。
- 消費者に公開されたビジネスデータは正確、完全、タイムリー。
- ビジネス領域と技術レイヤの全域で共有されているデータの構造と意味には、全関係者共通の解釈がある。
- 企業のビジネス領域をリンクしている中核的なデータエンティティは、すべてのビジネス分野全域にわたって一貫しており、信頼できる。
- 企業はそのデータとデータシステムから最大のビジネス価値を得る。
この論文はSOAに関連した3つの主要パターンを定義している。
- ビジネス用語集を通じてデータセマンティクスを定義
成功するSOAならどのようなものでも、その土台には、プロセスやサービス、データに関連した用語を定義した、容易にアクセスできる共通のビジネス用語集の確立があります。組織内で受け入れられているビジネス言語や省略語を学ぼうとする際、SOA実践者はたびたび専門用語に矛盾を発見します。顧客やチャンネル、収入などといった重要用語の定義に意見の一致がないとなると、こうした用語に関係したサービスの実装は不可能になります。サービスのパラメータの意味の解釈が関係者間で食い違っていたら、あるいは実際にそのサービスが取り出すデータセットが違っていたら、サービスの実装が成功する見込みはありません。ビジネスアナリストと技術者コミュニティがSOA領域のあらゆる側面で使われる専門用語について、共通の解釈をしていることが非常に重要であり、その中にはプロセス、サービス、データが含まれます。中核的なビジネス概念にまつわる言語のあいまいさは、さもなければデータ要件の誤解につながる可能性がありますが、ビジネス用語集があれば、このあいまいさが排除されます。用語の定義を制御する共通した語彙を確立することにより、ビジネス用語集は誤解を解消します。各用語は記述と他のメタデータを使って定義された後、タクソノミーに配置されます。スチュワードは割り当てられた用語に責任をもち、定義を援助し、こうした用語のガバナンスをサポートします。
- 標準的なモデリングを通じてデータ構造を定義
矛盾のない専門用語はサービスを設計する出発点としては望ましいものですが、それだけでは不十分です。ビジネス情報がどのような構造になっているかについても、明確に理解されていなければなりません。サービスの入出力パラメータ、すなわちメッセージは、単純なデータ型に比べてはるかに複雑です。エンティティやエンティティ間の関係の複雑な定義を示しています。SOAアーキテクトがサービスモデルの公開データフォーマットを設計する際、標準モデルを活用すれば、SOAプロジェクトの開発時間と品質を大いに改善できます。その結果、プロセスやサービス/メッセージ、データモデルに連携がもたらされることになり、設計が加速され、データモデリングに標準の指針が利用され、不要な変換が回避され…、結果として、幅広いサービス消費者のニーズを満たすサービス定義がもたらされることになるので、重複サービスの削減につながります。標準的なデータモデルはデータレイヤ上にこの共通フォーマットを確立しますが、一方、標準的なメッセージモデルはサービスレイヤ上でこの一律フォーマットを定義します。サービスアーキテクチャの分析と設計を進める上で利用可能なプロセス、サービス、データモデルの統合セットがIndustry Modelによって提供されますが、これによりモデリング領域全域におけるデータ定義の緊密な連携が保証されます。Industry Modelは特定の産業領域のモデリングについてベストプラクティスを定義し、拡張可能なフレームワークを提供するので、さらに多数のサービスを加えていく際にも、SOAを繰り返し再設計する必要はありません。
- データ品質を分析
前述の概念を考慮したSOA実践者は、モデルならびにメタデータアーチファクトの全域にわたって高度に一貫性のとれたサービス設計を提供することができます。しかし、サービスが返すデータ品質が満足できるものであるという保証にはなりません。データが元々のリポジトリやアプリケーションの規則と制約を満たしていても、企業レベルの必要条件は満たさない可能性があります…。元々の単一アプリケーションではさして重要でなかった品質の問題が、SOAを通じて企業レベルで公開されるようになると、深刻な問題を引き起こすかもしれません…。ですから問題は、公開されるデータの品質がSOAプロジェクトの必要条件を満たすか否か、またいかにして効果的にその決定を下すかです。サービス分析とサービス設計の間にデータの品質査定を行う、というソリューションを提案します。サービスをサポートするソースシステムのカタログ化を済ませたら、そのソースシステムのデータ品質問題について調査を開始できます…。データ重複がないか確認し、データの突き合わせと集約を行う間にいかにして重複を解消できるかを確かめればいいでしょう。選択したサービスの実装が、サービスの潜在消費者のコンテキストにおいて要求されるレベルのデータの正確性とデータの意味を必ず満たすように、この種の分析を基にして適切な行動をとることができます。
SOAが成熟するにつれて、SOAの情報設計の問題がいっそう重要になってくる。スパゲッティコードのようなマッピング仲介物を構築することなく、再利用も組み立ても可能なサービスを築くためには、標準的なデータ（EAIにおける標準的なデータに匹敵）の使用が必須の要件(リンク)であることに、SOA実践者は気づき始めている。