SAPinsider Las Vegas: Rethinking Enterprise Data Architecture for the AI Era

At SAPinsider Las Vegas, Gaurish Dessai, Principal Enterprise Architect at SAP Schweiz, framed enterprise data architecture through an unexpected lens: Douglas Adams’ The Hitchhiker’s Guide to the Galaxy. His central message was simple but pointed, “Don’t panic.”

For many SAP organizations, the rise of generative artificial intelligence (AI) and the introduction of SAP Business Data Cloud (BDC) have created both urgency and uncertainty. Questions around BW modernization, data platform strategy, and AI readiness are converging all at once. Dessai argued that while the technology landscape is evolving rapidly, the real challenge lies in how enterprise data architectures have been built over time.

A Stack of Rational Decisions, an Irrational Landscape

Dessai set the context using a Hitchhiker’s analogy: while Arthur focuses on the bulldozer in his front yard, the Vogons are already in orbit. In the enterprise, teams concentrate on immediate operational issues while a larger systemic shift, AI, is already underway.

Against this backdrop, he described today’s enterprise data environments as the result of “a stack of rational decisions that produced an irrational landscape.” Over time, organizations have layered systems, data models, and reporting logic to meet immediate needs, often without revisiting foundational design.

The result is a fragmented architecture: business logic embedded in spreadsheets, data quality fixes applied in isolation, and complex pipelines connecting systems that were never designed to work together. While each decision made sense in context, the cumulative effect has created data environments that are difficult to scale and even harder to trust, he said.

The Real Problem: Optimized for Reporting, not Decisions

A key theme throughout the session was that most enterprise data architectures are not designed to drive decisions.

Dessai outlined three common patterns:

• Architectures designed around systems rather than data
• Governance models built for compliance rather than usability
• Analytics environments optimized for reporting rather than decision-making

Organizations often measure success by the number of dashboards available rather than the quality or speed of decisions made. As a result, many businesses still rely on intuition, even when data is readily available.

Don’t Confuse Volume with Intelligence

As data volumes continue to grow, Dessai cautioned against equating more data with better insights. Enterprises are collecting vast amounts of structured and unstructured data, from transaction logs to meeting transcripts, but often struggle to extract meaningful intelligence from it.

This disconnect is increasingly exposed by AI. While organizations are eager to deploy AI models, many lack the underlying data quality, lineage, and trust required to support reliable outcomes.

AI Exposes Data Architecture Gaps and Shifts the Model to Connection

Dessai compared the current state of AI to the early days of the steam engine, promising, but not yet fully understood. While AI capabilities are advancing quickly, most organizations are still in the early stages of building the data foundations required to support them.

He emphasized three conditions required for trustworthy AI:

• Data quality: Poor data leads to confidently wrong outcomes
• Data lineage: Organizations must be able to explain where results come from
• Data trust: If users do not trust existing reports, they will not trust AI outputs

Rather than asking whether they have an AI strategy, Dessai suggested organizations should first consider whether their data is trustworthy enough to support AI at scale.

He also highlighted a fundamental shift in how organizations should approach architecture. Instead of asking, “How do we centralize all data?” organizations should ask, “How do we connect distributed data, owning it where it lives?”

Rather than building new pipelines to move data across systems, Dessai advocated for a “hitchhike, don’t build” approach, implemented through SAP Business Data Cloud data products and zero-copy data sharing.

In practice, this means exposing data as data products that bundle the dataset, standardized metadata, and an API endpoint, then sharing them across platforms such as SAP Datasphere and Databricks using Delta Share via BDC Connect.

SAP provides primary, source-oriented data products from S/4HANA and line-of-business systems, while organizations can build derived, consumer-oriented data products in Datasphere. This allows teams to access and combine SAP and non-SAP data without ETL pipelines, enabling bidirectional data sharing and reuse across analytics and AI workloads.

This approach reduces architectural complexity, minimizes duplication, and enables faster access to trusted data across systems.

Rethinking BW Modernization

BW modernization remains a critical concern for SAP customers. Dessai outlined several pathways, including system cleanup (“diet”), lift-and-shift approaches into private cloud environments, and more targeted transformations using SAP Datasphere.

Technically, he framed this as a BW “diet strategy,” starting with housekeeping to remove unused objects and reduce in-memory footprint, followed by a BW assessment to identify high-usage InfoProviders and data flows. From there, organizations can choose among several patterns: lift and shift into BW PCE to quickly connect to BDC, convert and lift to BW/4HANA for simplified modeling, lift and optimize using data tiering across hot, warm, and cold storage, lift and split by offloading selected data to Datasphere, or lift and transform by redesigning top N high-volume flows in Datasphere while retaining the rest in BW.

Rather than pursuing large-scale transformations immediately, he suggested organizations focus on simplifying existing BW landscapes, identifying high-value data objects, and incrementally evolving toward more flexible architectures.

Beyond technology, Dessai emphasized the importance of institutional knowledge, echoing the Hitchhiker’s idea that “the mice were running things all along.” BW developers and BI analysts often understand the nuances of data, exceptions, workarounds, and data quality issues that are not captured in any system or catalog.

This knowledge plays a critical role in maintaining and evolving data architectures, yet is often overlooked in transformation initiatives.

Asking the Right Question

Ultimately, Dessai argued that organizations have become too focused on building systems without revisiting the fundamental questions behind them.

Instead of asking what technologies to implement, organizations should consider:

• What is the most important data question the business needs to answer?
• Who owns data quality as a business outcome?
• Would the organization trust its data if AI were deployed today?

These questions shift the focus from technology to outcomes, ensuring that data architectures are designed to support decision-making and business value.

What This Means for SAPinsiders

42: The answer is not more data, but better decisions. Organizations optimizing for reporting risk missing the real outcome: faster, better decisions. Shifting architecture toward decision-making unlocks measurable business impact from analytics and AI.

Connected data beats centralized data. Moving toward distributed architectures with data products reduces duplication and complexity while enabling real-time access across SAP and non-SAP systems. This is critical for scaling analytics and AI use cases.

AI success depends on data trust, not tools. Without strong data quality, lineage, and governance, AI initiatives will fail to deliver reliable outcomes. SAP teams must prioritize data foundations before investing in advanced AI capabilities.