データアーキテクチャ：DMBOK 2nd editionを読んで その６
冒頭でお断りしておくが、ここに記述した内容は筆者のバイアスがかかったDMBOK 2nd editionの理解である。忠実な翻訳ではないので、留意いただきたい。
データアーキテクチャ（以下DA）は、エンタープライズアーキテクチャ（以下EA）の一部となっている。最初にEAという言葉を使ったとされるザックマン氏が、DAMAインターナショナルの後見人にもなっていることから、2nd editionでも彼のフレームワークが２ページほど紹介されている。（本ブログではその解説はしない。）
とは言え、ザックマン氏がカンファレンス等で強調している 「EAの目的はエンタープライズをエンジニアリングで設計・構築すること」 といった文言は登場せず、ごく一般的なDAの意義やアクティビティの紹介に止まっている。
データアーキテクチャの最重要ポイントを先に言っておくと、次の２点に集約される。
- 全社的な視点でデータ要件を定義し、データ統合の方向性をガイドし、データ資産を管理し、データへの投資をビジネス戦略と整合させること。
- EA（その一部のDA）の策定は、情報システム構成要素の冗長性を見つけスリム化することとビジネスイノベーションの推進に役立つ。
一般にEA（その一部のDA）の策定は、 ①Asisモデルの作成、②Tobeモデルの作成、③移行計画の３つからなる。DMBOK 2nd editionでは、Asis・Tobeという言葉は使っていないが、ほぼ同様の内容が記述されている。current state・target stateという言葉を使っている。
また、DA策定の中で、データアーキテクトは以下を実施するとしている。
- データの現状を定義する（通常Asisデータモデルなどを作成する）
- データとシステムの構成要素のためのビジネス語彙を提供する（EA策定の初期では、関係者間で意識を合わせる必要があり、語彙の標準化は避けられない）
- エンタープライズ戦略・ビジネスアーキテクチャとDAを整合させる（一般にアラインメントと言われる。ビジネス戦略と違ったことをしては意味がないため。）
- 戦略的データ要件の明示（すべてのデータを同じ位置づけで管理しきれないので、濃淡つけるために必要）
- これらの要件を満たすハイレベルな統合された姿を描く（通常Tobeデータモデルを作成する）
- 全体的なEAのロードマップと整合性を保つ（上記 1.～5.のカッコ内は筆者の意見）
データアーキテクチャ（DMBOK 2nd editionでは途中からエンタープライズデータアーキテクチャという言葉になっている）を表現するためには、エンタープライズデータモデルとデータフローデザインが必要である。
エンタープライズデータモデルは、次の４つから成り立つ。
- サブジェクトエリアの概観
- サブジェクトエリア別の概要データモデル
- サブジェクトエリア別の論理データモデル
- アプリケーションまたはプロジェクト別の論理データモデルと物理データモデル
もちろんEA策定時にこれらのデータモデルすべてを準備するのは不可能だと思う。筆者のEA策定の経験では、
- サブジェクトエリアの概観
- サブジェクトエリア別の概要データモデル
があれば良いと考える。
データフローデザインは、データと業務プロセスのCRUD表である。どのデータが、どの業務で発生し、どの業務で使われるかを概観するのに便利である。
まとめ（筆者の意見）
データアーキテクトは、エンタープライズ全体のデータを理解し、ビジネス戦略を反映させたデータモデルを作成しなければならない。
エンタープライズ全体を理解する際、対象となるエンティティの数が膨大で、何らかの工夫が必要になる。１つのやり方として全体構造に関係する事項と個別事項を切り分ける方法がある。
全体構造に関係する事項に注力して、個別事項は切り捨てるのである。
膨大で複雑なものをそのまま扱うことは不可能である。関係者が認識を合わせることができるフレームやモデル図が、そのときの助けになる。
データアーキテクチャの章は、その際の道具と概略の実施内容を紹介している。
一方で、ビジネス戦略を反映させる方法は、残念ながら記述されていない。ビジネス戦略がエンタープライズデータモデルのどの部分に影響し、どういったエンティティ構造が望ましいかについてはナレッジが蓄積されていないからであろう。
SCMの最適化パターン、類似商品を次々と開発する業界のBOMパターン、複数事業を持つ会社のサブジェクトエリア最適化など、まだまだ研究の余地がある。
このあたりは、今後に期待しよう。
