6.2 Data Architecture, Design and Standards

Data architecture has traditionally been part of enterprise architecture, and this remains true. Data sources, structures, interfaces and data flows must continue to be designed as part of the overall architectural landscape. Historically, data design focused on information systems and the data flows between them, later extending to interfaces that allow data to be used without relying on the user interface of the source system.

This foundation remains essential. However, the way data is used is changing. AI-driven capabilities increasingly move data processing outside well-defined and thoroughly tested information systems. This creates new challenges for how data is defined, controlled and standardised, and places greater emphasis on clear data design, shared standards and explicit governance.

The Data Architect defines and maintains the structures, models, metadata, design principles and standards that make data understandable and reusable across systems, services, analytics and AI-enabled capabilities. The Data Owner confirms the business meaning, quality expectations and appropriate use of the data. Together, these roles ensure that data can be extended and reused without losing its meaning, authority or business control.

From system-centric data design to explicit reuse

Traditional data design assumes that business rules, validations and logic are embedded in transactional systems. These systems enforce data consistency, structure and validity by design. Business rules embedded in transactional systems ensure that data is captured in the right format, follows agreed definitions and complies with required constraints as part of normal operations.

When data is reused outside these systems, for example through analytics, automation or AI-assisted processes, those embedded controls no longer apply automatically. AI-assisted processes may also add smart, use-specific checks or guidance, but these must be aligned with the authoritative definitions and rules maintained in the source systems and governance model.

This shift requires data architecture to be more explicit. Data definitions, constraints, relationships and allowed use must be documented and governed independently of individual systems. Interfaces and data products must carry sufficient structure and context to be safely reused across multiple purposes.

Traditional enterprise architecture practices have sometimes been too slow to describe every data usage scenario in detail. As enterprise architecture becomes more responsive and AI-enabled, it can provide faster guidance for data and AI development. Data architecture and standards therefore need to support incremental refinement and practical application close to business use, while still maintaining common meaning and control.

Example: Customer order data extended by an AI-assisted sales agent

In an online sales process, the transactional system typically defines order as a data asset. The order contains line items with attributes such as product, quantity, price, discount and delivery terms. This design is sufficient within the core sales system because the system enforces the rules related to confirmed order data, such as valid products, allowed product combinations, pricing rules, discount limits, delivery options and approval requirements.

When an AI-assisted sales agent is introduced, the order data is used in a broader way. The agent may interpret customer input, ask clarifying questions, apply product guidance and support creation of an order that fits the customer’s needs. To do this, it may need information that was not part of the original order design, such as customer preferences, product compatibility rules, delivery constraints, historical examples or curated expert knowledge.

The agent may also produce new forms of data, such as interpreted customer requirements, assumptions made during the interaction, applied constraints or explanations supporting the recommendation. These must not be confused with the confirmed order stored in the transactional system.

As a result, the original order data asset needs to be extended and clarified. The organisation must define what belongs to the confirmed business record, what is supporting context, what is AI-assisted interpretation, who is accountable for each part, and how the data may be used. This ensures that AI-assisted work remains aligned with core system rules and business intent.

This example illustrates why data architecture becomes more important as AI-enabled capabilities develop. Transactional data can be combined with context, knowledge and interpretation, but the organisation must still separate facts, assumptions, advice and explanations. Without this separation, data may be technically available but not reliable enough for controlled business use.

6-2-1 BT Architecture combined with AI capabilities

Figure 6.2.1 BT Architecture combined with AI capabilities (online sales process example)

Standards as enablers, not constraints

Data architecture standards define the shared rules for how data is structured, named, described and exchanged. They cover data models, interfaces, metadata and documentation practices. Their purpose is not to restrict innovation, but to ensure that data is understandable, reusable and safe to use across organisational boundaries.

Well-designed standards make it easier to develop new capabilities, integrate services and reuse data without repeatedly redefining meaning or rebuilding controls. They reduce friction rather than add it.

Effective standards are:

  • Clear, so they can be applied consistently in everyday design and development.
  • Flexible, allowing justified local extensions without breaking shared understanding.
  • Actively maintained, evolving as data usage, technology and business needs change.

Standards are applied through normal ways of working, such as design and architecture reviews, shared tooling and integration practices. They are enforced through use and governance, not through static documents alone.

The Data Architect ensures that standards remain practical, consistent and usable in development and operational work. The Data Owner ensures that standards reflect the business meaning and quality expectations of the data assets they govern.