Across ERP environments, the pressure to become AI-ready is accelerating. Yet many organizations are still grappling with fragmented data landscapes, legacy systems, and competing modernization priorities.
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.”
Dessai argued that while new technologies like SAP Business Data Cloud (BDC) and generative AI are driving urgency, the real issue is not the tools themselves, but the way enterprise data architectures have evolved 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.
Analysis
What This Means for ERP Insiders
AI readiness starts with operational data trust. ERP systems are the source of critical business data, but inconsistencies in master data and processes undermine confidence. Without trusted operational data, AI-driven insights will struggle to influence real business decisions.
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.
Analysis
What This Means for ERP Insiders
Data strategy must connect operations, not just systems. ERP environments span finance, supply chain, HR, and beyond, yet data often remains siloed across functions. Connecting data where it lives enables more integrated planning, reporting, and decision-making across the enterprise.
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.
Analysis
What This Means for ERP Insiders
Modernization is about simplification, not replacement. Many ERP teams assume transformation requires large-scale system overhauls. In practice, incremental approaches like data tiering, selective migration, and reuse of existing data assets can deliver faster value with lower risk.
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.
