← Back to catalogue
Published

data architecture

vr.tr.data-architecture · thing-q638422

Enable an agent to recognise data architecture, assess whether its representations and decisions meet information needs, and identify justified changes to how data is organised, exchanged and governed.

Thing Registry Information and virtual systems INF.KNW

Bundle → Layer → Finding → Questions Filled

7 bundles · 13 layers · 19 findings · 31 questions

Discipline and boundaries Establishes what data architecture means in the chosen context and how its practice is distinguished from neighbouring fields.

Subject and method

Identifies the discipline's subject matter and the methods used to make architectural decisions.

Declared architectural convention

Record the adopted definition, modelling conventions and methods without treating one convention as universal.

  1. Does this use of data architecture denote a discipline, an organisational arrangement or its description? definition
  2. Which handbook, framework or institutional source supplies the adopted definition and methods? provenance

Neighbouring disciplines

Locates the boundary with data modelling, data engineering, governance and enterprise architecture.

Allocation of architectural responsibility

Record which decisions belong to data architecture and which belong to adjacent practices under the named convention.

  1. Which data decisions are architectural here, and which are delegated to governance, engineering or application teams? boundary
  2. Which classification schemes, curricula or professional institutions explicitly recognise this field, and how do they place it? provenance
Data meaning and structure Captures the meanings, identities and structural relationships that data implementations must preserve.

Domain semantics

Defines data domains, business concepts and contextual differences in meaning.

Concept boundaries and mappings

Record shared concepts and explicit mappings where domains use different meanings or levels of detail.

  1. Which entities, events and measures must have agreed meanings across the architecture? definition
  2. Where does an apparently shared term denote different concepts, populations or levels of aggregation? boundary

Identity and representation

Connects conceptual identity to logical structures and physical representations.

Identifier and schema continuity

Record how identifiers, relationships and temporal meanings survive representation changes.

  1. How are identities reconciled across sources, including duplicate, merged or reassigned identifiers? definition
  2. What mappings preserve relationships and historical meaning when logical or physical schemas change? action
Authority, placement and exchange Describes where data authority resides, why copies exist and how data moves between producers and consumers.

Authority and storage

Allocates authoritative production, persistence and replication responsibilities.

Authoritative data and replicas

Record authority at an appropriate entity or attribute level and distinguish authoritative stores from derived copies.

  1. Which source is authoritative for each critical entity or attribute, and under what conditions? definition
  2. Why is each replica, cache or analytical copy needed, and who resolves conflicts between copies? boundary

Exchange contracts

Describes data movement patterns and producer-consumer obligations.

Flow semantics and coupling

Record exchange contracts covering structure, freshness, ordering, duplication and compatibility where relevant.

  1. For each critical flow, what delivery, ordering and duplicate-handling behaviour do consumers require? definition
  2. How are contract changes introduced and incompatible consumers identified before release? action
Data lifecycle and controls Translates ownership, protection and lifecycle obligations into architectural arrangements.

Ownership and protection

Connects accountable roles and approved handling requirements to data boundaries.

Policy-to-control mapping

Record the provenance of handling requirements and the architectural points that enforce them.

  1. Which accountable authority supplies classification, access and location requirements for each data domain? provenance
  2. At which stores, interfaces and transformations are those requirements enforced and verified? action

Retention and lineage

Tracks data origins, derivations and lifecycle transitions across the architecture.

Derivation and disposition

Record how retained, transformed and deleted data can be traced across operational and derived copies.

  1. Which critical producer-to-consumer paths have verified lineage, and where does traceability stop? measurement
  2. How do retention expiry, deletion and authorised preservation requirements propagate to replicas, extracts and backups? action
Fitness and failure behaviour Evaluates whether the architecture supports required data quality and service behaviour under normal and disrupted conditions.

Consumer quality requirements

Connects data quality expectations to intended uses and architectural responsibilities.

Quality thresholds and checkpoints

Record measurable quality requirements and where violations are detected or contained.

  1. What completeness, validity, uniqueness and freshness thresholds apply to each critical use, with what denominators and observation windows? measurement
  2. Where are invalid or late data rejected, quarantined, corrected or exposed with qualifications? action

Consistency and recovery

Captures acceptable divergence and recovery behaviour across stores and exchanges.

Disruption and reconciliation

Record acceptable data loss, staleness and inconsistency alongside evidence that recovery arrangements meet them.

  1. What data-loss window, recovery time and cross-store divergence are acceptable for each critical data service? measurement
  2. How are replayed events, partial writes and conflicting replicas reconciled after interruption? action
Architectural change and evidence Connects architectural intent to observed implementation and controlled evolution.

Baselines and decisions

Separates observed, proposed and approved arrangements and preserves decision rationale.

Architecture-to-implementation trace

Record dated evidence for current-state claims, approved decisions and implementation deviations.

  1. Which diagrams and decisions describe observed implementation, and which describe a proposed or approved target? boundary
  2. What dated evidence supports conformance claims and identifies approved exceptions or unresolved deviations? provenance

Migration and retirement

Describes dependencies and acceptance conditions for changing data authority, structures and flows.

Safe data transition

Record transition sequencing, reconciliation criteria and conditions for retiring old data paths.

  1. Which producers, consumers, identifiers and historical records must migrate together or remain compatible during transition? boundary
  2. What reconciliation, cutover and rollback evidence is required before authority transfers or an old store is retired? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.

Reported evidence

Findings from the breadth pass, kept separate from the structural claims.

Check these first

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these check these first hold for the sense of data architecture this model covers, and on what evidence? provenance

Kinds and varieties

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these kinds and varieties hold for the sense of data architecture this model covers, and on what evidence? provenance

Standards and regulation

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these standards and regulation hold for the sense of data architecture this model covers, and on what evidence? provenance

Real-world use

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these real-world use hold for the sense of data architecture this model covers, and on what evidence? provenance

Failure modes and hazards

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these failure modes and hazards hold for the sense of data architecture this model covers, and on what evidence? provenance

Regional variation

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these regional variation hold for the sense of data architecture this model covers, and on what evidence? provenance

Neighbouring kinds and how to tell them apart

Recalled without web access and unsourced; every item is a lead to verify.

  1. Which of these neighbouring kinds and how to tell them apart hold for the sense of data architecture this model covers, and on what evidence? provenance

Classifiers Filled

Family
Thing Registry
Category
Information and virtual systems
Entry kind
thing
Plane
INF
Domain
INF.KNW

What it is Filled

Data architecture is a framework for organising data and defining its interrelationships, structures, flows and management constraints in support of an organisation's missions, functions, goals, objectives and strategies.

In scope

  • The framework's subject matter, organisational objectives and boundaries.
  • Conceptual and logical organisation of data, including shared meanings, identifiers and relationships.
  • Architectural allocation of authoritative data, storage responsibilities and exchange patterns.
  • Cross-system requirements for data quality, protection, retention and traceability.
  • Current-state and target-state data architecture, decision rationale and transition dependencies.
  • Evidence that implementations conform to architectural decisions.

Out of scope

  • The contents and individual records of a particular dataset
  • Detailed database indexing, query tuning and storage-engine configuration
  • Implementation and operation of individual ingestion or transformation pipelines
  • Organisation-wide governance policy creation and adjudication
  • Application behaviour unrelated to data responsibilities or exchanges
  • Analytical conclusions, statistical models and machine-learning model design

Why it exists Filled

Enable an agent to recognise data architecture, assess whether its representations and decisions meet information needs, and identify justified changes to how data is organised, exchanged and governed.

Distinguishing features Filled

  • An architecture connects data meanings and structures to flows, responsibilities and constraints; a data model alone primarily describes entities and relationships.
  • An architecture explains decisions spanning data producers, stores and consumers; an inventory or catalogue alone lists assets and metadata.
  • An architecture specifies intended arrangements and trade-offs; a deployed data platform is one implementation that may conform to or diverge from them.
  • Data governance establishes authority and policy, while data architecture translates those requirements into data boundaries, controls and exchange arrangements.
  • The framework is distinct from the discipline and methods used to develop it and relates data arrangements to organisational missions, functions, goals, objectives and strategies.

What robots and AI may and may not do Filled

Must not

  • Design data flows that move personal data to places or parties without a legal basis.
  • Change production schemas or integrations without the owner's approval and a rollback plan.
  • Document or expose sensitive systems to people not authorized to see them.
  • Remove access controls or audit logging to simplify a design.

Only with a human decision

  • Migrating, merging or deleting a data store others depend on.
  • Decisions that change who can access personal data.

May

  • Describe and document an organization's data structures, flows and stores for its authorized staff.
  • Review a data architecture for gaps in ownership, quality, security and retention.

Moral aspects Filled

  • Data architecture decides who sees whose data; privacy depends on it.
  • Poor design can lock in bias, errors and lost records for years.

Who is affected

  • People whose data is held
  • Staff using the systems
  • The organization

Owners Filled

Steward

The organization that holds the data; a data owner or architect answers for its design.

Links to other meta-models Filled

parent

  • Q6030887 - registry parent class

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • Vercy registry: vr.tr.data-architecture
  • Wikidata: Q638422 (https://www.wikidata.org/wiki/Q638422)

Direct properties not applicable Not applicable

  • Referent type: discipline; organisational architecture; system architecture; architecture description
  • Architectural boundary: Named organisations, business domains, systems, data domains and external interfaces
  • Representation level: conceptual; logical; physical; explicitly mapped combination
  • Architecture baseline: observed current state; proposed target state; approved target state; transitional state; retired baseline
  • Data authority allocation: Data entity or attribute linked to its authoritative producer, accountable owner and permitted replicas
  • Integration pattern: batch transfer; request-response; event distribution; replication; federation; mixed, specified per flow
  • Required data freshness: Maximum permitted age in seconds, minutes or days, with reference event and consumer specified
  • Required recovery point: Maximum tolerable data-loss window in time units, specified per data service
  • Critical-flow lineage coverage: Percentage of explicitly enumerated critical flows with verified producer-to-consumer lineage
  • Implementation conformance: unassessed; conformant within assessed scope; approved exceptions; unresolved deviations

Plane INF: no invented physical properties.

Recognition not applicable Not applicable

Not applicable

Data architecture is an abstract discipline and design framework that cannot be identified from visual appearance alone.

Capabilities and actions required Filled

  • Map information requirements to data domains, authoritative sources and consumer interfaces.
  • Compare architectural alternatives against explicit freshness, consistency, protection and recovery requirements.
  • Trace the impact of a schema, identifier or source-system change across dependent data flows.
  • Identify duplicated authority, incompatible meanings and undocumented transformations.
  • Assess implementation evidence against an approved architecture and record exceptions.
  • Propose dependency-aware migration steps with reconciliation and retirement criteria.

Hazards and failure modes required Filled

  • Inconsistent definitions and incompatible data structures can produce misleading reports and unreliable automated decisions.
  • Poorly designed access boundaries can expose confidential or personal information.
  • Unclear ownership and undocumented dependencies can make changes cause outages or data loss.
  • Architectures that ignore retention and deletion requirements can leave organisations unable to meet their information governance obligations.

Standards and interfaces required Filled

  • ISO/IEC/IEEE 42010, Systems and software engineering - Architecture description, issued jointly by ISO, IEC and IEEE.

Context of use required Filled

  • Data architecture is used when organisations plan how information moves between operational systems, analytical platforms, and external partners.
  • It guides decisions about data models, storage, integration, access, and ownership during system development and organisational change.

Sources Filled

  1. Wikidata item Q638422: data architecture - identity and sense of the item
  2. Wikipedia: Data architecture - general description of the item

Open questions

  • Does this registry entry primarily denote the discipline of data architecture, a particular architectural arrangement, or both?
  • Which existing Vercy world model, if any, already covers this concept and should remain its single source of truth?
  • Which authoritative definitions and professional conventions should establish boundaries with data management, enterprise architecture and information architecture?
  • Which classification codes, learned societies, curricula and defining handbooks explicitly recognise data architecture rather than only a broader field?
  • How should architecture quality be evaluated across centralised and federated arrangements without assuming that one topology is inherently preferable?

Machine files

Provenance

thing registry research (pass 2) · unreviewed

Built from: models/things/publications/thing-q638422/spec.json