読書メモ: DMBOK2 第4章 データアーキテクチャ
このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第4章「データアーキテクチャ」について。 やや抽象度が高い内容となっており、理解が難しいと感じた。 以降、特に注釈のない引用は DMBOK2 第4章からの引用とする。 データアーキテクチャとは データアーキテクチャの定義は以下のとおり。 企業の (組織構造に関係なく) データニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持する。マスターとなる青写真を使ってデータ統合を手引し、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う。 業務戦略と技術実装の間を橋渡しすることがデータアーキテクチャの目的。 以下が成果物、つまり前述の定義の「マスターとなる青写真」となる。 データの保存と処理の要件 企業の現在のデータ要件と長期のデータ要件を満たす構造や計画の立案 これらを記述するためにエンタープライズ・データモデル (EDM) とデータフロー設計が必要となる。(後述) エンタープライズアーキテクチャ データアーキテクチャとビジネス、アプリケーション、テクニカルなど他の領域のアーキテクチャとの違いは下表のようになる。 それぞれが影響を及ぼし合う関係となっており、データアーキテクチャはビジネスアーキテクチャによって決められる。 ドメイン エンタープライズ・ビジネスアーキテクチャ エンタープライズ・データアーキテクチャ エンタープライズ・アプリケーションアーキテクチャ エンタープライズ・テクニカルアーキテクチャ 目的 企業が顧客や他のステークホルダに どのように価値提供しているかを 明らかにする データがどのように整理・管理されるべきか記述する 企業内アプリケーションの 構造と機能を記述する システムを稼働して価値を 提供するために必要な 物理実装技術を記述する 要素 ビジネスモデル、業務プロセス、業務能力、サービス、イベント、戦略、語彙集 データモデル、データ定義、データマッピング仕様、データフロー、構造化データの API ビジネスシステム、ソフトウェアパッケージ、データベース テクニカルプラットフォーム、ネットワーク、セキュリティ、統合ツール 依存関係 他のドメインに対する要件を設定する ビジネスアーキテクチャによって作られ、要求されるデータを管理する ビジネス要件に基づいて特定されたデータに対応する アプリケーションアーキテクチャを提供し実行する 役割 ビジネスアーキテクトとアナリスト、ビジネス・データスチュワード データアーキテクトとモデラー、データスチュワード アプリケーションアーキテクト インフラストラクチャアーキテクト DMBOK2 表6 アーキテクチャ領域 web 系エンジニア的には「アーキテクチャ」という言葉だけ聞くとクラウドサービスのアイコンを使ってアーキテクチャ図をお絵描きするよくあるアレを想像しがちだが、データアーキテクチャはそれではないということ。 (DMBOK2 の分類ではそれはテクニカルアーキテクチャの領域) エンタープライズ・データモデル (EDM) EDM とは 全体的でエンタープライズレベルの実装に依存しない概念または論理モデルであり、企業全体にわたるデータに関して一貫した共通のビューを提供する。 次の図は概念・論理モデルと物理的なデータモデルとの関係を示す。 垂直方向には対象領域ごとに対応する異なるレベルのモデルが関係している。 水平方向には同じレベルのモデルがあり、対象領域をまたいでエンティティが関係し合う。 DMBOK2 図23 エンタープライズ・データモデル...