データアーキテクチャの結果。さまざまなレベルでのモデル、定義、データフローが含まれます。これらは、多くの場合、データアーキテクチャのコンポーネントと呼ばれます。
データアーキテクチャの目標を形成、展開、達成するためのデータアーキテクチャアクティビティ
データアーキテクチャの動作(エンタープライズデータアーキテクチャに影響を与えるさまざまな役割間のコラボレーション、考え方、スキルなど)

データアーキテクチャはデータ管理の基礎です。ほとんどの組織は個人が理解できる以上のデータを保有しているため、データをより深く理解し、経営陣が意思決定を行えるようにするには、さまざまな抽象レベルで組織のデータを記述する必要があります。

データアーキテクチャのコンポーネント:

現状の説明
データ要件の定義
データ統合ガイドライン
データ資産管理仕様

最も詳細なデータアーキテクチャ設計ドキュメント:これは、データ名、データ属性とメタデータ定義、概念および論理エンティティ、関係、およびビジネスルールを含む正式なエンタープライズデータモデルです。物理データモデルもデータアーキテクチャドキュメントに属しますが、物理データモデルはデータモデリングと設計の成果物であり、データアーキテクチャの成果物ではありません。

1.1 ビジネスの推進要因

データアーキテクチャの目標 (ビジネスドライバー) : ビジネス戦略と技術実装の間にスムーズな橋渡しを確立することデータアーキテクチャはエンタープライズアーキテクチャの一部です。

データアーキテクチャの主な責任:

新しいテクノロジーによってもたらされるビジネス上の利点を活用して、組織が製品、サービス、データを迅速に変革できるように戦略的に支援します。
ビジネス要件をデータおよびアプリケーション要件に変換して、ビジネスプロセス処理に有効なデータを確実に提供できるようにします。
企業全体にわたって複雑なデータと情報を管理し、配信します。
ビジネスとITテクノロジーの連携を確保します。
企業の改革・変革・適応力向上を支援します。

1.2 データアーキテクチャの結果と実装

データアーキテクチャの主な結果:

データの保存と処理のニーズ。
現在および長期的なデータのニーズを満たす構造と計画を設計します。

データアーキテクト:アーキテクトは、組織に価値をもたらす方法で組織のデータアーキテクチャを設計しようとします。この価値は主に、適切なテクノロジーの適用、効果的な運用、プロジェクト効率の向上、データアプリケーション機能の強化を通じて反映されます。

データアーキテクトの主なタスクは次のとおりです。

データの現在の状態を定義します。
データとコンポーネントに関する標準的なビジネス語彙を提供します。
データアーキテクチャが企業戦略およびビジネスアーキテクチャと一致していることを確認します。
データ戦略のニーズについて説明します。
高レベルのデータ統合のアウトライン設計。
エンタープライズデータアーキテクチャのブループリントを統合します。

全体的なデータアーキテクチャの実装:

データアーキテクチャコンポーネント (マスターブループリント) を使用して、データ要件を定義し、データ統合をガイドし、データ資産を管理し、データプロジェクトへの投資が企業戦略と一致していることを確認します。
ビジネスや IT システム開発の改善に関わる関係者と協力し、関係者から学び、影響を与えます。
データアーキテクチャと共通のデータ語彙を通じてエンタープライズデータ言語を構築します。

1.3 基本概念

アーキテクチャフレームワーク: アーキテクチャのアーキテクチャ。建築に対する考え方と理解の方法。

エンタープライズアーキテクチャの種類:ビジネスアーキテクチャ、データアーキテクチャ、アプリケーションアーキテクチャ、技術アーキテクチャ

ザックマンのフレームワーク:

基本的な考え方
- 最も有名なエンタープライズアーキテクチャは Zachman フレームワークです。ザックマンフレームワークはオントロジー、つまり企業と企業間の関係を完全に説明できる一連のモデルを構成する 6x6 マトリックスです。これはモデルの作成方法を定義するものではなく、どのモデルが存在する必要があるかを示すだけです。

ザックマンフレームワーク - 問い合わせコミュニケーション:
- 内容: ディレクトリ列、スキーマを構築するエンティティ。
- How: Process 列は、実行されたアクティビティを表します。
- 場所、流通柱、事業所および技術的な場所。
- 誰: 責任の列、役割、組織。
- いつ: 間隔、イベント、サイクル、スケジュールを表す時間列。
- なぜ: 動機の欄、目標、戦略、手段の表
Zachman フレームワーク - 変換の再定義:
- 1) 経営陣の視点 (ビジネス背景): さまざまなモデル範囲のビジネス要素カタログを定義します。
- ２）経営管理の観点（事業概念）：経営者が定義したビジネスモデルに関わる異なる事業概念間の関係を明確にする。
- 3) アーキテクトの視点 (ビジネスロジック): アーキテクトはモデル設計者として、システム要件を絞り込み、システムロジックモデルを設計します。
- 4) エンジニアの視点 (事業体): エンジニアは、具体的なモデルの構築者として、特定の技術、人員、コスト、時間の制約内で特定のアプリケーション向けに設計された物理モデルを最適化して実装します。
- 5) 技術者の視点 (コンポーネントのアセンブリ): テクノロジー固有のコンテキストフリーの視点を使用して、モデルを構成する技術者が構成コンポーネントをどのように使用、組み立て、実装するかを説明します。
- 6) ユーザー視点（操作カテゴリー）：参加者が実際に使用した機能例。この観点にはモデルがありません。

エンタープライズデータアーキテクチャ

定義: 組織にとって重要な要素を定義する標準的な用語と設計。エンタープライズデータアーキテクチャの設計には、データの収集、保存、統合、移動、配布などのビジネスデータの記述が含まれます。
詳細は次のとおりです。
- 1) エンタープライズデータモデル (データ構造、データ仕様)。
- 2) データフローの設計。

エンタープライズデータアーキテクチャの概念は次のとおりです。

データ: セキュリティで保護、統合、保存、記録、分類、共有し、最終的には使用するために配信する必要があるレポートと分析。プロセス中に、データは、アーカイブまたはパージされるまで、検証、強化、リンク、認証、統合、感度解除が行われ、分析に使用される場合があります。

エンタープライズデータモデル: 全体的なエンタープライズレベルの独立して実装された概念または論理データモデルであり、企業に共通で一貫したデータビューを提供します。単純化された抽象化。これには、データエンティティ (ビジネス概念など)、データエンティティ間の関係、主要なビジネスルール、およびいくつかの主要な属性が含まれます。

データフロー設計: データベース、アプリケーション、プラットフォーム、ネットワーク (コンポーネント) 間の要件とマスターブループリントを定義します。ビジネスプロセス、さまざまな保管場所、ビジネスの役割、およびテクノロジーコンポーネント間のデータフローを示します。

エンタープライズデータモデル:業界標準モデルを採用すると、エンタープライズデータモデルの開発を迅速化できます。企業のニーズが変化するにつれて、エンタープライズデータモデルの各レベルの範囲と内容も拡大し、さまざまなレベルで増分的かつ反復的な方法で構築できます。各エンタープライズデータモデル内のエンティティは 1 つのサブジェクト領域にのみ属する必要がありますが、他のサブジェクト領域に関連付けることもできます。企業概念データモデルは、サブジェクトドメインモデルを組み合わせて構築され、トップダウンまたはボトムアップで構築できます。

サブジェクト領域の識別基準は、エンタープライズモデル全体で一貫している必要があります。一般的に使用されるサブジェクト領域の識別基準: 正規化ルールを使用して、システムポートフォリオからサブジェクト領域を分離し、トップレベルのプロセス (ビジネスバリューチェーン) またはビジネス能力 (エンタープライズ) に基づいて、データガバナンス構造とデータ所有権 (または組織) からサブジェクト領域を形成します。アーキテクチャ）。サブジェクト領域の構造は、正規化ルールを使用して形成されている場合、通常、データアーキテクチャ作業に最も効果的です。正規化プロセスでは、各サブジェクト領域をホスト/構成する主要なエンティティを確立します。

データフロー: データの発信元を記録し、ビジネスプロセスおよびシステム内でデータがどのように流れるかを記述するために使用されるデータ処理プロセス。データがどこから来て、どこに保存され、どのように変換されるかというデータ系統分析は、データフローの特定の時点でのデータの状態を分析して説明するのに役立ちます。

データフローマッピングは、データと以下の関係を記録します。

ビジネスプロセスへの応用。
環境内のデータストアまたはデータベース。
ネットワークセグメント (安全なマッピングに役立ちます)。
ビジネスロール (データの作成、更新、削除を担当するロールを説明します)。
地域的な差異が発生する場所。

データフローを使用すると、サブジェクト領域、ビジネスエンティティ、さらには属性レベルでのマッピング関係など、さまざまなレベルでモデルのマッピング関係を記述することができます。2 次元マトリックスまたはデータフロー図として表示されます。

2. 活動内容

データとエンタープライズアーキテクチャを簡素化する 2 つの方法:

品質重視（伝統と一致）。
(網羅的ではなく) イノベーションを目指してください。

2.1 エンタープライズデータアーキテクチャの確立

エンタープライズアーキテクチャの確立に含まれる作業: (並列または逐次実行できます)

戦略。フレームワークを選択し、方法論を開発し、ロードマップを作成します。
コミュニケーションと文化。
整理する。責任と責任を明確にする。
仕事のやり方。エンタープライズアーキテクチャに合わせます。
結果。全体的なロードマップにおける出力。

エンタープライズデータアーキテクチャは、プロジェクトとシステム開発の範囲の境界に影響を与えます。

プロジェクトのデータ要件を定義します。データアーキテクチャを通じて各プロジェクトのデータ要件を企業に提供
プロジェクトのデータ設計を確認します。設計レビューを実施して、概念的、論理的、物理的なデータモデルとアーキテクチャが一貫性があり、組織の長期戦略と一致していることを確認します。
データのトレーサビリティの影響を判断します。アプリケーション内のデータフローのビジネスルールに一貫性があり、追跡可能であることを確認します。
データ複製制御。レプリケーションは、アプリケーションのパフォーマンスを向上させ、データの取得を容易にする一般的な方法ですが、データの不整合を引き起こす可能性もあります。データアーキテクチャガバナンスは、必要な一貫性を実現するために適切なレプリケーション制御 (方法とメカニズム) を保証します (すべてのアプリケーションが同じ厳密性を必要とするわけではありません)。
データアーキテクチャ標準を実装します。エンタープライズデータアーキテクチャのライフサイクルの標準を開発および実装します。標準は原則、プロセス、ガイドライン、青写真として表現できます。
データテクノロジーを導き、意思決定を更新します。データアーキテクチャはエンタープライズアーキテクチャと連携して、各アプリケーションのデータテクノロジリリース、パッチ、データテクノロジロードマップポリシーを管理します。

エンタープライズアーキテクチャを確立する手順:

1 既存のデータアーキテクチャ仕様の評価
2 開発ロードマップ: 3 ～ 5 年間の開発パスについて説明します。ロードマップはデータ管理の成熟度評価に基づいて作成される必要があります。
- ロードマップには以下が含まれます。
  - 1) 高レベルのマイルストーンイベント。
  - 2) 必要なリソース。
  - 3) コスト評価。
  - 4) ビジネス機能ワークフロー部門。
- 開発ステップ: ビジネスデータ駆動型のロードマップは、最も独立したビジネス機能から開発でき、その後、より高度な相互依存関係を持つビジネス機能に対処できます。
3 プロジェクトでのエンタープライズ要件の管理
- 実行する手順: プロジェクトレベルでは、データモデルを通じて要件を定義するプロセスは、ビジネス要件のレビューから始まります。通常、これらの要件はプロジェクトの目標に固有のものであり、ビジネスには影響しません。このプロセスには、用語の定義の開発や、データの使用をサポートするその他の活動も含まれる必要があります。

エンタープライズデータアーキテクチャプロジェクトに関連するアクティビティ:

スコープを定義します。スコープとインターフェイスがエンタープライズデータモデルと一致していることを確認してください。
ビジネスニーズを理解する。エンティティ、リソース、可用性、品質と問題点、ビジネス価値などのデータ関連の要件を取得します。
デザイン。詳細な目標仕様を作成します。
実装 (いつ購入するか、いつデータを再利用するか、いつ構築するか)

2.2 他のエンタープライズアーキテクチャの統合

アーキテクチャ活動は、次のような方法でプロジェクトプロセスに組み込まれます。

滝道。
反復的な方法。
アジャイルアプローチ (DevOps)

3. ツール

データアーキテクチャツール:

データモデリングツール。
資産管理ソフトウェア。(データリソースディレクトリを管理し、その内容を記述し、それらの間の関係を追跡するために使用されます)
グラフィックデザインアプリケーション。

4. 方法

4.1 ライフサイクル予測

建築設計の対象:

現在。
導入サイクル。
戦略サイクル。
退職しました。
優先されます。
限定。
出現中。
審査。

4.2 アイコンの使用ガイドライン

アイコン使用ガイドライン:

明確で一貫した指示。
すべてのチャートオブジェクトが説明と一致します。
明確で一貫したライン方向。
一貫したクロスハッチ表示方法。
一貫したオブジェクトのプロパティ。
線対称。

5. 導入ガイド

データアーキテクチャには、コンポーネント、アクティビティ、および動作が含まれます。

データアーキテクチャ実装作業内容：

エンタープライズデータアーキテクチャチームを設立し、問題セッションを実施します。
データスキーマのバージョンを生成します。
開発プロジェクトにおけるデータアーキテクチャの作業方法を形成および確立します。
データアーキテクチャの取り組みの価値に対する組織の認識を高めます。

5.1 準備状況評価とリスク評価

準備状況評価とリスク評価:

経営陣のサポートが不足している。
成功の証拠は不足しています。
経営者からの信頼の欠如。
経営陣による誤った決定。
文化衝撃。
経験豊富なプロジェクトマネージャーが不足している。
一次元の視点。

5.2 組織と文化

組織的および文化的な依存関係 (データフレームワークの受け入れは以下に依存します):

建築的アプローチの受け入れ。
データは単なる IT 部門の仕事ではなく、組織のビジネス資産であることを確認します。
ローカルなデータの観点を放棄し、企業全体のデータの観点を受け入れる機能。
アーキテクチャの成果物をプロジェクトの実装に統合する能力。
データガバナンスの受け入れを標準化します。
企業のレイアウトに基づいており、プロジェクトの成果物や IT ソリューションの能力に限定されません。

6. データアーキテクチャのガバナンス

6.1 データアーキテクチャガバナンス活動

データアーキテクチャガバナンス活動:

プロジェクト監修。
アーキテクチャの設計、ライフサイクル、ツールを管理します。
標準を定義します。
データ関連のアーティファクトを作成します。

6.2 指標

データアーキテクチャのメトリクス:

1. アーキテクチャ標準の受け入れ率: 確立されたデータアーキテクチャに対するプロジェクトの近さ、およびプロジェクトとエンタープライズアーキテクチャの参加プロセスへの準拠度を測定します。
2. トレンドを理解する。
- 1) 測定値を使用/再利用/交換/廃棄します。
- 2) プロジェクト遂行効率測定
3. ビジネス価値測定指標。
- 1) ビジネスの機敏性の向上。
- 2) ビジネスの品質。
- 3) 業務運営の品質。
- 4）事業環境の改善

DAMA-DMBOK2 の重要な知識の編集 CDGA/CDGP - 第 4 章データアーキテクチャ

1. スコア配分

2. 重要な知識のまとめ