TL;DR

Data Architecture artifacts describe the baseline and target data structure of the enterprise. Useful Phase C artifacts include the Data Entity/Business Function Matrix and the Logical Data Diagram.

Why data artifacts matter

Data Architecture describes the important data entities of the enterprise and how they relate to business activity, applications, and stakeholders. Think of it as the enterprise’s data structure.

Good data artifacts help answer:

  • what data entities matter?
  • which business functions use or own them?
  • which applications create, store, or reference them?
  • how do critical data entities relate to each other?

Useful data artifacts

TOGAF lists several catalogs, matrices, and diagrams that may be used for Data Architecture.

Two useful examples are:

ArtifactTypeWhat it shows
Data Entity/Business Function MatrixMatrixRelationship between data entities and business functions
Logical Data DiagramDiagramLogical relationships between critical data entities

Other common data views may include data entity catalogs, application/data matrices, data lifecycle views, data dissemination views, and data security views.

Data Entity/Business Function Matrix

The Data Entity/Business Function Matrix shows how data entities relate to business functions.

It can be used to:

  • assign ownership of data entities to organizations
  • identify which business functions create, read, update, or delete data
  • define the application of origin for a data entity
  • define the application of record for a data entity
  • define applications that reference a data entity
  • support gap analysis across baseline and target data architecture

Example:

Data entityBusiness functionOwning organizationApplication of originApplication of recordApplication of reference
SupplierSupplier OnboardingProcurementSupplier PortalSupplier Master DataERP Finance
Purchase RequestPurchase Request ManagementProcurementPurchase Request AppERP FinanceReporting Platform
InvoiceInvoice ProcessingFinanceERP FinanceERP FinanceReporting Platform

Application of origin, record, and reference

These terms help clarify responsibility for data across applications.

TermMeaning
Application of originThe application where the data is first created or captured
Application of recordThe authoritative application for the data entity
Application of referenceAn application that reads or uses the data but is not the authoritative source

This distinction is useful when the same data entity appears in many applications.

Logical Data Diagram

The Logical Data Diagram shows logical relationships between critical data entities.

It is usually created for stakeholders such as:

  • application developers
  • database designers
  • data architects
  • integration designers
erDiagram
    SUPPLIER ||--o{ PRODUCT : supplies
    CUSTOMER ||--o{ PURCHASE_ORDER : places
    PURCHASE_ORDER ||--o{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : referenced_by
    PURCHASE_ORDER ||--o{ INVOICE : billed_by

The diagram should stay logical. It shows meaningful data relationships without jumping too early into database tables, physical storage, or implementation technology.

Matrix vs diagram

The matrix is better for collecting structured facts about ownership, usage, and application responsibility.

The logical diagram is better for explaining relationships between data entities.

Use both when needed:

  • matrix for completeness and traceability
  • diagram for communication and shared understanding

Exam note

  • Data Architecture artifacts are created in Phase C.
  • The Data Entity/Business Function Matrix shows relationships between data entities and business functions.
  • The matrix can support ownership decisions and identify applications of origin, record, and reference.
  • The Logical Data Diagram shows logical relationships between critical data entities.
  • Logical diagrams are useful for application developers and database designers.
  • Data Architecture artifacts describe baseline and target data structures.

Sources