このポストについて
DMBOK2 を読み進めていくシリーズ。
今回は第4章「データアーキテクチャ」について。
やや抽象度が高い内容となっており、理解が難しいと感じた。
以降、特に注釈のない引用は DMBOK2 第4章からの引用とする。
データアーキテクチャとは
データアーキテクチャの定義は以下のとおり。
企業の (組織構造に関係なく) データニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持する。マスターとなる青写真を使ってデータ統合を手引し、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う。
業務戦略と技術実装の間を橋渡しすることがデータアーキテクチャの目的。
以下が成果物、つまり前述の定義の「マスターとなる青写真」となる。
- データの保存と処理の要件
- 企業の現在のデータ要件と長期のデータ要件を満たす構造や計画の立案
これらを記述するためにエンタープライズ・データモデル (EDM) とデータフロー設計が必要となる。(後述)
エンタープライズアーキテクチャ
データアーキテクチャとビジネス、アプリケーション、テクニカルなど他の領域のアーキテクチャとの違いは下表のようになる。
それぞれが影響を及ぼし合う関係となっており、データアーキテクチャはビジネスアーキテクチャによって決められる。
| ドメイン | エンタープライズ・ビジネスアーキテクチャ | エンタープライズ・データアーキテクチャ | エンタープライズ・アプリケーションアーキテクチャ | エンタープライズ・テクニカルアーキテクチャ |
|---|---|---|---|---|
| 目的 | 企業が顧客や他のステークホルダに どのように価値提供しているかを 明らかにする | データがどのように整理・管理されるべきか記述する | 企業内アプリケーションの 構造と機能を記述する | システムを稼働して価値を 提供するために必要な 物理実装技術を記述する |
| 要素 | ビジネスモデル、業務プロセス、業務能力、サービス、イベント、戦略、語彙集 | データモデル、データ定義、データマッピング仕様、データフロー、構造化データの API | ビジネスシステム、ソフトウェアパッケージ、データベース | テクニカルプラットフォーム、ネットワーク、セキュリティ、統合ツール |
| 依存関係 | 他のドメインに対する要件を設定する | ビジネスアーキテクチャによって作られ、要求されるデータを管理する | ビジネス要件に基づいて特定されたデータに対応する | アプリケーションアーキテクチャを提供し実行する |
| 役割 | ビジネスアーキテクトとアナリスト、ビジネス・データスチュワード | データアーキテクトとモデラー、データスチュワード | アプリケーションアーキテクト | インフラストラクチャアーキテクト |
DMBOK2 表6 アーキテクチャ領域
web 系エンジニア的には「アーキテクチャ」という言葉だけ聞くとクラウドサービスのアイコンを使ってアーキテクチャ図をお絵描きするよくあるアレを想像しがちだが、データアーキテクチャはそれではないということ。
(DMBOK2 の分類ではそれはテクニカルアーキテクチャの領域)
エンタープライズ・データモデル (EDM)
EDM とは
全体的でエンタープライズレベルの実装に依存しない概念または論理モデルであり、企業全体にわたるデータに関して一貫した共通のビューを提供する。
次の図は概念・論理モデルと物理的なデータモデルとの関係を示す。
垂直方向には対象領域ごとに対応する異なるレベルのモデルが関係している。
水平方向には同じレベルのモデルがあり、対象領域をまたいでエンティティが関係し合う。
DMBOK2 図23 エンタープライズ・データモデル
これらはトップダウンまたはボトムアップのアプローチで構築される。
レベル別に段階的・反復的に構築するのがセオリーとのこと。
いきなりすべてを記述しようとするのは良くない。
データモデリングについて詳しくは第5章で見ていくことになる。
データフロー設計
データフロー設計はデータベース、アプリケーション、その他にまたがるデータの処理と格納の要件。
データリネージのドキュメントであり、データがビジネスプロセスやシステムをどのように移動するかを示したデータフロー図により記述される。
以下はデータフロー図の例。
DMBOK2 図26 データフロー図例
データと以下の関係をマッピングする。
- アプリケーション
- データベース
- ネットワークセグメント
- ビジネス上の役割
- 地域的祭が生じている拠点
データアーキテクチャの導入・推進
データアーキテクチャの導入には導入失敗のリスクアセスメント、および (他の多くの DMBOK 知識領域と同様) 組織と文化の変革が必要になる。
次のようにしてデータアーキテクチャの慣行を確立する。
- 既存のデータアーキテクチャ設計書の評価
- ロードマップの開発
- 各プロジェクトにおける全社要件の管理
- 開発プロジェクトはデータアーキテクチャによって確立された業務要件と標準に基づいて、データを取得・格納・配布するためのソリューションを実装するもの
データアーキテクチャは各プロジェクトのスコープ境界を決めるのに影響する。
- プロジェクトのデータ要件定義
- プロジェクトのデータ設計レビュー
- データリネージの影響判定
- データアプリケーションの制御
- データアーキテクチャ標準の徹底
- データテクノロジーと更新の意思決定ガイド
プロジェクトは一般的にプロジェクト固有のアーキテクチャの優先事項を重視するが、全社的なデータアーキテクチャには積極的に取り組むべきとされる。
まとめ
データアーキテクチャの概念は抽象度が高く、データ基盤を単に IT の一貫として捉えている組織では理解されにくいと感じた。
私自身、本章を読むまではデータ基盤まわりのシステムアーキテクチャのことだと思っていたが、異なるレベルの話だった。
逆に言うとデータマネジメント系の勉強会で発表するようなデータマネジメントが推進されている会社ではデータアーキテクチャについての考えが明確になっているような気がしている。
複数社で働いてきた自分の経験からだが、マネジメント層でも抽象度が高い仕事ができる人はそれほど多くない。
そのへんのケイパビリティが組織のデータマネジメントの成否に強く影響してくるのだろう。