Skip to content
Software Architecture Guide

Data Architecture Artifact

Explanation

Section titled “Explanation”

Data architecture artifacts are the working documents of the data part of enterprise architecture. In TOGAF, they belong to Phase C, the Data Architecture phase. (See the articles TOGAF and TOGAF Architecture Development Method.) One goal of this phase is to find gaps between the current (baseline) and desired (target) data architecture. Those gaps become candidates for the roadmap.

There are three kinds of artifact, and each does a different job.

  • Catalogs are inventories. The organization’s data inventory is kept as a catalog in the Architecture Repository.
  • Matrices show relationships between model entities. They feed diagrams and help assess the impact of a change.
  • Diagrams are visual views.

Catalogs and matrices take their structure from the attributes of entities in the TOGAF Content Metamodel. The metamodel defines which things exist and which properties each one has. So the artifacts stay consistent with each other.

Typical artifacts

  • Data Entity/Data Component catalog. It maps data entities to the applications or data components that hold them. See Data Entity/Data Component Catalog.
  • Data Entity/Business Function matrix. It maps each entity to the business functions that create and use it, in a CRUD-style way. See Data Entity/Business Function Matrix.
  • Conceptual Data diagram. This business data model shows the relationships between core entities. See Conceptual Data Model.
  • Other data diagrams. Phase C also suggests logical, dissemination, lifecycle, security and migration diagrams.
  • Mastering policy. A dissemination diagram can reveal duplicated data. In that case, define which copy is the master and which are copies. This is the master/slave (system of record) idea.

The conceptual model mainly helps spot data duplication. A logical data model is usually normalized to reduce that duplication. See Conceptual, Logical and Physical Data Model.

Example

Section titled “Example”

A retailer lists its data entities: Customer, Order, Product. The catalog records which application holds each one. A matrix then shows that the web shop creates Orders, while the warehouse function only reads them. A dissemination diagram shows Customer data stored in two systems. The team decides the CRM is the master and the other system holds a copy. Each gap between this picture and the desired state becomes a roadmap candidate.

Trade-offs

Section titled “Trade-offs”

The facts here describe what each artifact contains. They do not say how much effort the artifacts cost to keep current. Phase C only suggests the diagrams (“should be considered”), so teams choose which ones fit their needs. Producing every artifact is not required.

How catalogs, matrices and diagrams build on each other in the Data Architecture phase.

Diagram source 
flowchart LR
  M[Content Metamodel] --> C[Catalogs: inventories]
  M --> X[Matrices: relationships]
  C --> X
  X --> D[Diagrams: visual views]
  C --> D
  D --> G[Gaps between baseline and target]
  G --> R[Roadmap candidates]

Checks

Section titled “Checks”
  • The data inventory is kept as a catalog in the Architecture Repository.
  • Each data entity is mapped to the application or data component that holds it.
  • A matrix maps data entities to the business functions that create and use them.
  • Where data is duplicated, a mastering policy names the master and the copies.
  • Gaps between baseline and target data architecture are identified as roadmap candidates.
Section titled “Related”

Sources

Section titled “Sources”