Data & AI DAC Architecture with Mustafa Qizilbash

Key Takeaways

• Unified Ecosystems: The DAC framework integrates data and AI ecosystems, eliminating silos and fostering effective AI integration.
• Enforced Boundaries Prevent Chaos: Traditional architectures often falter due to weak boundaries, resulting in duplicated pipelines and high costs.
• “One Door In, One Window Out”: DAC centralises data flow through a single hub, ensuring controlled access and eliminating redundant extractions.
• Federated Operating Model: The framework promotes a federated approach, separating data into an “Enterprise Zone” and various “Business Zones.”
• Mandatory Metadata: In DAC, comprehensive metadata is essential for ensuring system observability and maintaining data lineage.
• Upgraded Layering Structure: DAC enhances the Medallion architecture by adding areas for unstructured data processing and format standardisation.
• Objective vs Subjective Quality: DAC architecture ensures objective data standardisation, while subjective quality depends on governance and oversight.
• Governance Drives Architecture: Strong organisational governance and clear definitions are essential for a successful technical architecture.

Webinar Details

Title: Data & AI DAC Architecture with Mustafa Qizilbash
Date: 2026-06-22
Presenter: Mustafa Qizilbash
Meetup Group: DAMA SA Big Data
Write-up Author: Howard Diesel

What is the DAC Framework’s Main Purpose?

The Data and AI Cognitive Architecture (DAC) framework addresses the urgent need to integrate data and artificial intelligence ecosystems while strictly managing governance controls.

The presentation introduces the DAC framework as a solution to modernise organisational data strategies. A foundational goal of DAC is merging data and AI capabilities, resolving the persistent issue where isolated, siloed data hinders the work of data scientists and artificial intelligence initiatives.

Furthermore, essential tracking functions, such as system auditing, are managed explicitly under the framework’s overarching governance umbrella rather than the conceptual model itself.

Key Takeaways

• DAC intentionally merges data and AI ecosystems into a single, cohesive architecture.
• Critical tracking functions like auditing and compliance are governed centrally.

FAQ

• What is DAC? DAC stands for Data and AI Cognitive Architecture, a framework designed to bridge data silos and prepare information for artificial intelligence models.

Figure 1 Data & AI Cognitive (DAC) Architecture

Why do Traditional Data Architectures Fail Consistently?

Traditional data architectures fail because they rely on conceptual intent rather than enforced infrastructure boundaries, leading to disjointed systems and uncontrolled AI expansion.

Without strict control points, popular frameworks often degrade into “architecture by exception”. When development teams are allowed to build systems however they see fit, organisations suffer from duplicate data pipelines, competing semantic definitions, and heavily inflated operational costs.

The rapid acceleration of artificial intelligence amplifies these hidden structural flaws. This creates “AI chaos,” where developers engage in “vibe coding” without understanding the complete software development life cycle (SDLC), resulting in unmaintainable products.

Key Takeaways

• Unenforced architectural boundaries create multiple conflicting sources of truth and lower data trust.
• Without strict infrastructural control points, any design becomes architecture by exception.

FAQ

• Why do traditional data architectures struggle with AI? They fail to enforce strict data movement controls, which amplifies existing structural flaws and creates expensive, redundant pipelines.

Figure 2 Overview

Figure 3 The Moment We’re In

Figure 4 Why Traditional Architecture Fails

Figure 5 The Cost of Architectural Drift

Figure 6 Why Modern Architecture Must Achieve

How does DAC Ensure Data Governance and Integrity?

The DAC framework utilises strict entry and exit protocols—”one door in” and “one window out”—to deliver a highly governed, unified data environment.

To combat architectural drift, DAC enforces a federated governance model equipped with standardised data movement frameworks. All enterprise data must enter through a single Integration Hub (“one door in”) and exit exclusively through a unified virtualisation layer (“one window out”).

This mandatory routing prevents unauthorised duplicate pipelines from proliferating. Additionally, DAC natively integrates AI and strictly enforces mandatory metadata capture as a prerequisite for proper governance and model training.

Key Takeaways

• Data enters the ecosystem via a single Integration Hub and exits via a controlled virtualisation layer.
• Capturing comprehensive metadata is a non-negotiable, enforced requirement within the DAC model.

FAQ

• What are the core design principles of DAC? DAC relies on controlled data ingestion, governed movement, and enforced metadata capture to effectively unify data and AI operations.

Figure 7 What You Want Vs. What DAC Delivers

Figure 8 Design Principles of DAC

Figure 9 The Confusion in the Current Industry

How does DAC Differ from Other Data Models?

DAC distinguishes itself from Centralised and Data Mesh models by utilising a federated operating model that enforces strict, infrastructure-level governance.

Operating models dictate how organisational data teams function. While centralised approaches often create operational bottlenecks, heavily decentralised models risk creating a “spaghetti” network of unmanaged, intertwined integrations.

DAC champions a federated approach that centralises high-level policies while distributing data product ownership across domains. Within this ecosystem, observability platforms can seamlessly monitor execution traces and AI performance purely because DAC enforces the mandatory collection of technical and operational metadata.

Key Takeaways

• DAC employs a federated operating model to successfully balance domain autonomy with enterprise control.
• Comprehensive system observability is fuelled by the framework’s strictly enforced metadata requirements.

FAQ

• How does DAC differ from a decentralised Data Mesh? Unlike a Data Mesh, which permits direct cross-domain integrations, DAC requires all data movements to route back through centralised, governed integration points.

Figure 10 Decentralised – Operating Model

Figure 11 Centralised – Operating Model

Figure 12 Data Hub – Operating Model

Figure 13 Data Fabric – Operating Model

Figure 14 Data Mesh as Federated – Operating Model

Figure 15 DAC as Federated – Operating Model

How does DAC Manage Data Segregation and Flow?

DAC segregates data into an Enterprise Zone for cross-functional executive metrics and Business Zones for domain-specific products, connecting them strictly via an Integration Hub.

All raw organisational data must pass through the central Integration Hub to prevent multiple domains from redundantly querying operational source systems (like SAP). From there, data flows into specialised, isolated zones.

Business Zones maintain autonomy over domain-specific products (such as Sales or Finance), while a singular Enterprise Zone exclusively houses cross-domain data products required for top-level management KPIs. Crucially, Business Zones cannot exchange data directly; everything must route back through the integration layer to prevent untraceable dependencies.

Key Takeaways

• The central Integration Hub actively prevents costly, redundant extractions from primary source systems.
• The standalone Enterprise Zone is reserved strictly for high-level, cross-domain management decisions.

FAQ

• Can Business Zones share data directly in DAC? No; to maintain clean architecture, all cross-domain data must route back through the Integration Hub rather than moving directly between business domains.

Figure 16 Governance Blueprint

Figure 17 One Door In – Integrating Hub

Figure 18 One Window Out – Virtualisation Layer

How does DAC Enhance the Medallion Architecture?

DAC improves upon the popular Medallion architecture by mandating explicit landing and staging layers to accurately process unstructured data and systematically enforce formatting standards.

Traditional Medallion architectures (Bronze, Silver, Gold) often struggle to ingest unstructured raw data (such as video or audio files) because they require structured data formats from the very beginning. DAC introduces a dual-zone landing area to cleanly process and convert non-readable data first.

Furthermore, DAC utilises a strict staging layer to physically standardise data elements—such as date formats and special characters—before information hits the transform layer, which significantly reduces recurring cloud compute costs.

Key Takeaways

• DAC landing zones accurately process both readable and unreadable unstructured data files.
• Standardising foundational data formats in the staging layer prevents highly expensive downstream compute operations.

FAQ

• How does DAC improve upon the Medallion architecture? DAC explicitly includes mandatory landing and staging layers to handle unstructured files and physically enforce formatting before structured transformation phases begin.

Figure 19 The Confusion in the Current Industry

Figure 20 Data Store Types Patterns

Figure 21 Traditional Data Architecture Layers

Figure 22 Data and AI Cognitive Architecture Layers

Figure 23 Data Science & AI Enablement

How does DAC Enhance AI Deployment Speeds?

Implementing DAC can guarantee a 200% increase in AI deployment speeds by enforcing governed data ingestion and natively separating compute from storage.

The unique power of DAC lies in its uncompromising operational efficiency. By forcing all corporate data through a single integration point, the framework permanently eliminates duplicate pipelines and vastly reduces overall system complexity. Modern DAC implementations also mandate the physical separation of compute operations and storage layers.

Organisations are strongly advised to implement DAC in structured phases: establish the foundational governance framework first, build out the Integration Hub next, and finally introduce the virtualisation layer.

Key Takeaways

• DAC significantly accelerates AI readiness by guaranteeing centralised data availability for developers.
• Successful adoption requires implementing the Integration Hub long before altering existing data warehouses.

FAQ

• What is the very first step in implementing DAC? Organisations should formally establish their foundational governance framework before attempting to deploy the Integration Hub.

Figure 24 Comparisons

Figure 25 What Makes DAC Unique

Figure 26 Why DAC?

Figure 27 Traditional to DAC

Figure 28 DAC Layers & Enterprise and Business Zone

Figure 29 Modern Data Reference Architecture

Figure 30 Enterprise Data Strategy

Figure 31 DAC Architecture Strategy

Is a Centralised Integration Hub Really Necessary?

While decentralised advocates argue for direct source data acquisition, DAC maintains that a centralised Integration Hub is absolutely necessary to prevent severe cost and security risks.

Allowing hundreds of decentralised data products to query operational sources independently creates massive data leakage risks, unmanageable operational overhead, and privacy concerns. DAC actively mitigates this by restricting all source queries to the single Integration Hub.

Critics argue that enforcing universal data quality across an enterprise is impossible. However, DAC logically separates quality into two distinct categories: objective standardisation (like date formats), which the architecture physically enforces, and subjective business rules, which require human oversight and policy governance.

Key Takeaways

• Decentralised source querying scales very poorly and massively inflates operational cloud costs.
• DAC physically enforces structural data standardisation but deliberately leaves subjective quality checks to human governance policies.

FAQ

• Can data architecture completely enforce enterprise data quality? No; architecture can only enforce structural standardisation, while subjective data quality relies entirely on organisational governance and metadata policies.

How does Business Alignment Impact Technical Architecture Success?

A technical architecture cannot succeed without robust business definitions driving its governance policies, highlighting the dire need for organisational alignment over pure IT enforcement.

A purely IT-driven architecture will invariably fail to enforce compliance if the broader business lacks unified, agreed-upon data definitions. Establishing centralised semantics—where multiple functional business areas agree on clear, unified metrics—is a critical process that must occur before technical implementation begins.

Industry leaders highly advocate for advanced integration practices like “policy as code,” which automatically checks developer code commits against established governance rules, ensuring that business logic successfully dictates architectural behaviour.

Key Takeaways

• Architecture alone cannot solve alignment issues; business stakeholders must formally agree on strict data definitions.
• Implementing “policy as code” is a highly recommended aspirational goal to automate governance enforcement.

FAQ

• Does technical architecture drive business definitions? No; formal business definitions and governance policies must heavily dictate the technical architecture to achieve meaningful enterprise enforcement.