エンタープライズデータアーキテクチャは、企業全体で扱うデータの意味・関係・配置・流れを設計したものです。中心となるのがエンタープライズデータモデルで、主要な業務領域をサブジェクトエリア（顧客、商品、受注など）として整理し、実装方式に依存しない概念データモデルで企業横断の管理対象と意味上の関係を表現します（科目B 1-3）。

あわせて、システム間のデータフローを可視化し、データの重複・冗長を把握・管理します。どのシステムがどのデータを生成（C）・参照（R）・更新（U）・削除（D）するかを表にするCRUD分析は、正本の所在や責任の所在を確認する基本的な手法です。システム間連携で共通に使うデータ形式をカノニカルデータモデルとして定めておくと、変換ロジックの乱立を防げます。設計は現状（As-Is）と目標（To-Be）のアーキテクチャ及び移行計画の形でまとめます。

科目B 1-3では、指標・分析軸・計算ロジックを一貫して使えるようにするセマンティックレイヤー、非構造化データを検索・関連付けるためのオントロジー・ナレッジグラフ・ベクトル検索、判断基準や例外を管理する判断モデル・ルール・デシジョンテーブルの設計も挙げられています。人だけでなくAIがデータを正しく解釈できる構造を用意する、という視点がポイントです。

データ基盤には集中型（全社データを一つの基盤に集約）と分散型（各部門・ドメインが持つ）があります。分散型の代表的な考え方がデータメッシュで、シラバスでは次の4要素が挙げられています。

データ連携の方式にはポイントツーポイント型とハブアンドスポーク型があります。ポイントツーポイント型は必要なシステム同士を個別に接続するため、少数なら簡単ですが、n個のシステムが相互に連携すると最大 n(n−1)/2 本のインタフェースが必要になり、保守が難しくなります。ハブアンドスポーク型は中央のハブを経由するため、インタフェースは各システムとハブの n 本で済み、変換や監視を集約できますが、ハブが性能・可用性のボトルネックになり得ます。

メタデータは「データについてのデータ」です。シラバスでは次の3種類に分類されています。

メタデータを使う仕組みには、ビジネス用語を定義・統一するビジネスグロッサリー（ビジネス用語集）、データ項目の名称・型・定義を記述するデータ辞書、組織内のデータを探索・理解するためのデータカタログ、メタデータを格納するメタデータリポジトリ、データ要素の定義を登録・管理するメタデータレジストリ（その標準がISO/IEC 11179）があります。

データリネージは、データの生成元から加工・連携を経て利用先に至るまでの来歴とつながりです。テーブルレベルは「どの表からどの表へ」、カラムレベルは「どの列がどの列の計算に使われたか」まで追えます。カラムレベルは影響分析に強い反面、収集・維持の負荷が大きくなります。

メタデータ管理は、DMOなどが運用ルールを整備し、ルールに基づいて追加・更新します。メタデータアーキテクチャには集中型・分散型・ハイブリッド型があり、メタモデル（メタデータ自体の構造）を定めます。メタデータの品質は、リポジトリの利用頻度、完全性、可用性、メタデータ成熟度などで評価します。

マスターデータは顧客・商品・取引先・組織など、業務の基本となる比較的変化の少ないデータです。日々の取引記録であるトランザクションデータ、国コードや通貨コードなどの区分・コード値である参照データと区別します。複数システムに散らばったマスターデータを統合・管理するのがMDM（マスターデータ管理）で、統合された最も信頼できる1件のレコードをゴールデンレコードと呼びます。

統合の中心は名寄せです。同一の実体を表すレコードを見つけるマッチング、1件にまとめるマージ、誤って統合したものを戻す分割、そして結果の確認・是正からなります。マージ時に、項目ごとにどのシステムの値を正とするか（例：住所は最新更新日のもの、与信限度額は基幹システムのもの）を決める規則を定めておきます。

参照データ・コード体系の管理では、コード体系の標準化、コードの新設・改廃の手続、システム間のコードマッピング、業界標準・国際標準コードの利用、有効期間と世代管理が論点です。有意味コード（桁に分類などの意味を持たせる）は人が読みやすい反面、分類変更時にコード変更が必要になります。無意味コード（連番など）は変更に強い反面、コードから内容を推測できません。MDMは対象ドメイン（顧客→商品→取引先など）を段階的に拡大するのが一般的です。

データの提供者と利用者の間で、データの仕様、品質水準、更新・提供条件、利用条件及び責任分担を取り決めたものがデータ契約（データコントラクト）です。科目B 1-4ではデータ契約を定め、その変更管理プロセスを設計する技能が挙げられており、IPA公表の科目Bサンプル問題（問1）でもYAML形式のデータコントラクトが題材になっています。

schema:
  - name: customer_id
    type: string
  - name: amount
    type: decimal
    description: "月間売上金額（単位：千円）"
quality_slo:
  completeness:
    - name: customer_id
      allow_null: false

上の例では、amount の単位が「千円」と定義されています。提供側が利用者に合意を取らずに単位を「円」に変えると、契約を前提にしている利用者（分析やAIの入力など）が誤った結果を出してしまいます。既存項目の意味を変える破壊的な変更は、新しい項目の追加やバージョンの更新とあわせて、利用者への周知・合意を経て行うことが変更管理の基本です。

データメッシュのデータプロダクトは、このようなデータ契約によって利用者・利用目的・意味・スキーマ・品質・更新方法などが明確にされ、再利用できる形で提供されます（科目B 1-6）。また1-4では、命名・データ型・単位・コード値・識別子の発番ルールなど組織横断の標準、AIの入力・生成データの管理ルール、非構造化データの分類・タグ、命名、版管理、権利・利用条件のルール策定も対象です。