‘The Gap Between AI Ambition and AI Delivery Is a Data Architecture Gap’: Gaurish Dessai

As organizations accelerate investments in AI, analytics, and cloud platforms, many are discovering that ambition alone does not translate into value. Beneath the surface of modern tools and transformation roadmaps lies a more fundamental challenge: enterprise data architecture that has evolved organically over years of acquisitions, customization, and locally optimized decisions. Without structural clarity, even the most advanced AI initiatives struggle to scale.

Speaking with SAPinsider, Gaurish Dessai, principal enterprise architect at SAP Schweiz AG, shares practical insights on navigating legacy BW environments, applying clean core principles beyond ERP, and building resilient, future-ready data foundations. In this Q&A, he explains why architectural discipline is the prerequisite for AI at scale — and how organizations can measure success by business outcomes rather than technical milestones.

Q: Organizations frequently describe their environments as “too complex.” From your perspective, what is typically the underlying architectural issue driving that complexity?

GD: When organizations describe their environments as “too complex,” they are usually describing a symptom, not the root cause. The underlying issue is accumulated architectural debt, i.e., decisions made at different moments in time for valid local reasons that collectively created structural fragmentation.

Over years or decades, business units, IT teams, and integrators made locally rational decisions like shadow data marts, regional instances, and bolt-on acquisitions, that produced globally irrational outcomes. The result is an estate that is increasingly difficult to manage and evolve.

Q: When you talk about “legacy gravity wells,” or legacy BW environments, what is the smartest way to escape them without disrupting the business?

GD: Legacy BW environments should not be treated as purely technical data warehouse problems. The first step is to define the target data architecture required to enable AI at scale, then work backwards. Rather than migrating every object, organizations should assess active business usage. In most cases, only 20%-30% of BW objects drive critical decisions.

The governing principle is simple but counterintuitive: the goal is not to migrate your BW, it is to replace what BW was doing for your business with something a future-ready data platform like SAP BDC that is more capable, more AI-ready, and more aligned to how your organization and your agents will consume data in the future.

Q: What core architectural principles must organizations establish to successfully navigate enterprise data complexity at scale?

GD: Organizations that navigate complexity well establish a small number of durable architectural principles and enforce them consistently.

First, design for adaptability, not permanence – assume components will be replaced within five years.

Second, recognize that simplicity is a technical decision requiring political courage. Every layer of complexity in an enterprise landscape exists because someone, somewhere, said yes when they should have said no to a new integration, a one-off customization, a parallel system that was supposed to be temporary.

Third, architecture must be legible to business stakeholders; if it cannot be explained to a CFO in clear business terms, it will not receive sustained investment.

Q: How does the clean core philosophy extend beyond ERP customization into enterprise data architecture design?

GD: Clean core principles apply to data architecture just as strongly as they do to ERP. Keep the ERP kernel standard, extend through SAP’s defined extension framework, and preserve upgrade paths by avoiding custom code that entangles with core ERP logic.

It is an architectural principle that applies with equal force to enterprise data architecture. For example, a global consumer goods company I worked with had spent years allowing individual business units to pull data directly from BW InfoCubes into local spreadsheet models and BI tools. When they migrated to a modern data platform, every one of those direct extractions broke. The migration cost three times what it should have. A clean core data architecture would have eliminated most of that rework.

Q: What distinguishes a resilient enterprise data architecture from one that becomes restrictive over time?

GD: A resilient architecture can absorb change without requiring structural redesign. Business requirements, technologies, and organizational structures will evolve; resilient systems anticipate this. Restrictive architectures, by contrast, create cascading downstream consequences with each change, eventually making change more expensive than inertia.

Q: Based on your experience with landscape consolidation and M&A integration initiatives, how does enterprise data architecture influence post – merger success?

GD: In M&A contexts, enterprise data architecture becomes business critical. Financial consolidation, supplier rationalization, and customer deduplication all depend on harmonized master data and unified reporting structures.

Finance cannot consolidate books on a consistent basis. Operations cannot rationalize supplier relationships because vendor master data is incompatible across the merging entities. Sales cannot prevent customer duplication or accurately assess overlapping customers. These are all data problems.

Two organizations both running SAP ERP have radically different data models, chart of accounts structures, plant hierarchies, and reporting frameworks. Organizations often underinvest in interim architecture, which is the structure that supports governance and combined reporting during the two to four years it takes to reach a target state.

Q: In highly regulated industries such as Life Sciences and Healthcare, how do compliance requirements shape enterprise data architecture decisions?

GD: In regulated industries, compliance must be embedded into the architecture itself. Requirements such as traceability, electronic signatures, immutable audit trails, validation protocols, and jurisdictional data storage rules shape integration design, access controls, and lineage tracking.

For instance, compliance in Life Sciences and Healthcare must be embedded into the architecture, not appended to it.

According to U.S. Food and Drug Administration (FDA) and European Medicines Agency (EMA) guidelines:

1. Every action on a critical record must be traceable to a specific person
2. Electronic signatures must be as legally binding as handwritten ones
3. Records cannot be altered without leaving an audit trail
4. Systems must be validated, meaning formally tested and documented to prove they work as intended
5. Data must be protected from accidental or deliberate corruption.

This means an organization must be able to demonstrate exactly where a piece of data originated, how it was transformed, who accessed it, and when. In SAP environments, this means ensuring that the integration and transformation layer maintains full lineage metadata, that access logs are immutable and independently auditable, and that any data used in regulatory submissions can be traced back to its authoritative source with complete provenance.

Healthcare data is subject to strict requirements about where patient data can be stored and processed. These requirements vary by jurisdiction and are becoming more, not less, restrictive as privacy regulations evolve globally.

Q: How can organizations accelerate innovation while maintaining architectural discipline and operational resilience?

GD: The gap between AI ambition and AI delivery is primarily a data architecture gap. Before AI initiatives are funded, organizations must know where data originates, who owns its quality, and how errors are detected.

AI models require continuous monitoring, cross-domain integration, and governed data pipelines. AI amplifies the strength or weakness of underlying architecture.

Organizations that prioritize speed over discipline create architectural chaos that eventually consumes their innovation capacity. Organizations that prioritize discipline over speed create bureaucratic gridlock that drives innovation outside the architecture entirely.

However, innovation and discipline are not opposing forces. Organizations must design architectural “fast lanes,” meaning controlled environments for experimentation within defined boundaries. When properly structured, architectural discipline becomes the infrastructure that makes innovation sustainable.

Q: How should organizations measure the success of enterprise data architecture initiatives beyond technical implementation milestones, and what guiding rules would you offer as a “survival guide” for SAP customers?

GD: Enterprise architecture investments so often disappoint because they are measured by what was built, not by what changed as a result. Go-live dates, migration completion percentages, and system availability metrics tell you that implementation occurred. They tell you almost nothing about whether the architecture is delivering business value.

Measuring what actually matters requires a shift in perspective:

Business capability metrics, not technical delivery metrics. Success should be measured by whether the business can act faster and with greater confidence. For example, reducing the time from question to trusted answer and eliminating manual reconciliation work.

Data trust and adoption metrics. An architecture that is not actively used has failed. Track who is consuming governed data, how often it informs decisions, and whether it is trusted at the executive level.

Architectural health metrics over time. Monitor whether complexity is increasing or decreasing by tracking ownership, integration discipline, and the ease of adding new capabilities without redesign.

Business agility metrics. The ultimate test is responsiveness – how quickly the organization can adapt to regulatory changes, acquisitions, or strategic pivots without structural disruption.