EDSのフェローでSOAエキスパートのFred Cummins氏は先日、「Data Management for SOA」（SOAのためのデータ管理）という小論文(リンク)を書いた。再利用の達成と変化の実現という意味合いにおいて、サービス設計の重要な原理（「疎結合」と「自律性」）がどのようにエンタープライズデータと関わっているのかを考察している。
SOAの価値をもたらす上で、こうした原理の不可欠性を認めているCummins氏でさえも、次のように述べている。
SOAの価値とは、複数のビジネス環境で〔サービスを〕統合する能力や、ユーザーに対する影響を最小限に抑えながら〔サービスを〕最適化し、適応させる能力によってもたらされるものです。
氏はこうも言っている。
しかし、こうしたデカップリングや自律性は共有データベースの利用と矛盾します。
データ管理に重点的に取り組む人々は何十年にもわたって、緊密なカップリングの方が高い効率と一貫性をもたらすという哲学の下、データベースの統合に向かって業界を動かしてきました。
データのグル達は［エンタープライズ］データ管理(リンク)をSOAの疎結合と調和させようと苦闘しています。
Cummins氏はJill Dyché氏(リンク)に注意を向けているが、Dyché氏は以下のように勧めている。
［マスター］データから始めましょう。SOAは標準化したビジネスプロセスをサービスとして提供することなので、これは直感に反するように聞こえますが、１サービスとしてのデータの概念は、SOAを検討し始めたばかりの企業からすれば、実は実現の可能性が高いのです。
さらにDan Gardner氏は、「SOA and compute clouds point to rethinking data entirely: roles and permissions, not rows and tables」（SOAとコンピュート・クラウドは、データの抜本的な再検討を暗示している。列と表ではなく、役割と許可の再検討である）(リンク)という論文の中で、次のように述べている。
エンタープライズデータの大半を制御しているのは、もはやIT組織ではありません。
ところがCummins氏は、この２人の考察はほとんどSOAと関連性がないとして退けている。氏の提案は次のとおり。
SOAにおいて常に関心の中心に置いておかなければならないデータは、企業の過去、現在、未来の状態を象徴するビジネスシステムによって作成、消費、管理されたデータです。ビジネス的見地からすると、重要なのは分散型ストレージの問題ではなく、データを認証し、管理し、保護する方法です。
Cummins氏はSteve Karlovitz氏と意見が一致していると指摘している。
データサービス・レイヤーの実装は、企業の全データ・ストアへの単一エントリーポイントとして多数の利点をもたらします。
- これで中央管理されたやり方でデータへのアクセスが可能。
- データ媒体変換をどのように行うかについては、様々なビジネスルールを参照。
- 最適化や変換といった問題は、単一エントリーポイントで対処。
- データの整合性とセキュリティを確実化。
- 組織は新機能の商品化に要する時間を大幅に短縮。
しかし問題は、どうやってデータサービス・レイヤーを設計するかである。Cummins氏は3つの異なる可能性を考えている。
- データサービス・レイヤーはデータアクセス機構であり、この機構はオブジェクト・リレーショナルの変換機構と同様に、共有データベースの標準的なビューを使ってあらゆるアプリケーションからのデータベースへのアクセスをサポートしています。
- 異種のアプリケーションデータベースからのデータは、標準的なデータスキーマを用いて複製され、エンタープライズデータベースに統合されます。
- 異種データベースへのアクセスは、標準的な仮想データベース上のクエリとして表現したリクエストを通じて提供されます。
最初の可能性は本質的に、共有データベースの概念である。Cummins氏は次の理由をもって、実質的に現実性に乏しいとしている。
多くのサービスがレガシーシステムやCOTS(リンク)システムを使い続けるでしょうし、そうしたシステムは自身のデータベースを一体化しており、［また］サービスユニットを実装する技術の異種混交化は、SOAのアジリティにとって必須です。
2番目のアプローチは、エンタープライズデータ管理やビジネス・インテリジェンス(参考記事)のグループでは一般的になった「オペレーショナル・データ・ストア」の概念を活用している。Cummins氏はここでも問題を見つけている。
様々なソースからのアップデートには遅延があるでしょうから、完全に矛盾のないビューの達成はやはり難しいかもしれません。複製データはクエリにのみ使われるべきです--アップデートの管理は非常に難しいでしょう。 「真実の単一バージョン」であるところのマスターデータは、いまだソースのデータベースに存在しており、所有者が制御しなければなりません。
3番目のアプローチは企業内情報統合（EII）(リンク)の機能とうまく一致している。Cummins氏は次のように述べている。
数年前の導入時、EIIはあまり市場に受け入れられませんでしたが、SOAのお陰でEIIの時代がやってきました。
しかし氏は、次のように助言している。
EIIのツールの中には異種データベースへのアップデートをサポートしているものもありますが、それでも、アップデートはデータベースを所有するサービスユニットが制御すべきです。
この意見は、オブジェクト・ライフサイクル(参考記事)に従ってサービス・インターフェースを構築せよという提案と相互に関係しており、その提案がここ(参考記事)でも繰り返されている。
Cummins氏は次のように結論づけている。
SOAのためにデータを管理するには、エンタープライズ論理データモデルや、比較的自律的なサービスユニット間のデータ連合およびデータ共有のためのメカニズム、さらにはデータ管理計画を求めるところから取り掛かるべきです。データ管理計画とは、データの整合性と保護を目的として、責任やフロー、マスターデータ・ストア、アップデートの待ち時間、同期戦略と責任能力を定義することです。
BPMとSOAは「同じ硬貨の表裏をなす」とはしばしば言われてきた。しかし、SOA実装が新たな成熟のレベルに達すると、データとデータのリレーショナルな性質も検討する必要があるという理解が進み、ビジネスプロセスの検討よりもそちらの必要性の方が高いかもしれない。データを「確認し、管理し、保護する」サービスの作成は容易ではなく、たいていのIT組織にとっては経験のない技術や緻密な方法論の使用が必要となる。サービス指向アーキテクチャの中核に、とりわけエンタープライズデータ管理を据えることになる。オブジェクト・ライフサイクルの概念は究極的に、データ、サービス、ビジネスプロセスを統一する概念として台頭するように思われる。
EDMは貴社のサービス設計に重要だろうか？ 貴社では論理データモデルを活用しているのか？ データサービスの作成にはどのアプローチをとったのか？