Coder Legion - Recent posts tagged enterprisedata

SAP partnered with its competitors to let customers choose their data platform. That's not weakness.

Wed, 05 Nov 2025 22:59:30 +0000

SAP's Data Strategy: Why the Snowflake Partnership Makes More Sense Than It Seems

The Partnership Nobody Expected

SAP announced a partnership with Snowflake at TechEd 2025. The announcement included a new "SAP Snowflake" solution extension that brings Snowflake's data and AI capabilities to SAP customers.

The immediate reaction from the analyst community: why would SAP do this? They already have SAP HANA Cloud. They already have SAP Datasphere. Why partner with a competitor?

Muhammad Alam's answer in the post-keynote Q&A session cut through the confusion: "What customers want from us is optionality."

That word, "optionality." reveals SAP's entire data strategy.

What SAP Actually Built

SAP Business Data Cloud is not a data warehouse. It's a data fabric architecture.

The distinction matters. A data warehouse consolidates data in one location. A data fabric connects data wherever it lives while maintaining business semantics, the business meaning and relationships in the data.

Alam explained it in the keynote: "Every intelligent application starts with trusted data. SAP is giving developers more ways to put that data to work through SAP Business Data Cloud."

The technical implementation has three layers:

Layer 1: Data Products

Data products are SAP's key abstraction. They package raw data with metadata, business semantics, and governance rules into reusable assets.

The new Data Product Studio (general availability planned H1 2026) gives developers a visual workspace to model, configure, and manage custom data products across SAP and third-party sources.

Developers can turn raw data into ready-to-use assets known as data products that support analytics, AI and application development.

Layer 2: Business Data Cloud Connect

This is where the partner integrations happen. Business Data Cloud Connect enables secure, zero-copy sharing of SAP's data products into customers' existing data lakes and platforms.

The key technical feature: data stays in its original location. No ETL pipelines. No data duplication. Data products are published into partner catalogs with business semantics intact.

Layer 3: Partner Compute Platforms

This is where Snowflake, Databricks, Google BigQuery, and Microsoft Fabric come in. They provide compute infrastructure for analytics and AI workloads.

The architecture: SAP provides data semantics and governance. Partners provide compute and storage. Customers use both.

The Snowflake Integration Specifically

SAP Business Data Cloud Connect for Snowflake does two things:

Outbound: Publishes SAP data products directly into the Snowflake Horizon catalog. Business semantics, lineage, and governance from SAP Business Data Cloud are preserved. Users working in Snowflake see SAP data with full business context.

Inbound: Exposes Snowflake data products within the SAP Business Data Cloud catalog. SAP applications and agents can access Snowflake data through standardized data products.

General availability is planned for H1 2026.

Alam explained the value proposition: "A new SAP Snowflake solution extension for SAP Business Data Cloud brings Snowflake's fully managed data and AI capabilities directly to SAP customers, enabling seamless, zero-copy data sharing that maintains governance and business context."

Why This Actually Makes Sense

Bharat Sandhu framed it as customer reality: customers "already know what they need to do." SAP's job is to "provide customers with rich data products."

The practical truth: enterprises have already invested in data platforms. Some chose Databricks three years ago. Others standardized on Snowflake. Some are committed to Google Cloud or Microsoft Azure.

Requiring migration to SAP HANA Cloud for all analytics workloads creates friction. Enterprises resist because:

Migration projects are expensive and time-consuming
Data teams have built expertise in their chosen platform
They've already built analytics and ML pipelines
Breaking those dependencies creates business risk

SAP's response: don't require migration. Instead, extend the existing platform with SAP's business semantics.

Brenda Bown described the broader strategy: "Meet customers where they are. Open ecosystem."

The Complete Partner Landscape

SAP Business Data Cloud Connect now integrates with four major platforms:

Databricks: Generally available now
Google BigQuery: Planned for H1 2026
Microsoft Fabric: Planned for H1 2026
Snowflake: Planned for H1 2026

Each follows the same pattern: SAP data products published to partner catalog, partner data products exposed in SAP catalog, zero-copy sharing, governance maintained.

Additionally, SAP is expanding native capabilities. A technical capability called "near real-time extraction" enables extraction of SAP data from on-premise systems into SAP Business Data Cloud, making it easier for developers to build custom data products enriched with SAP business context.

What About SAP HANA Cloud?

SAP continues significant investment in SAP HANA Cloud as its multi-model AI database. New capabilities announced at TechEd reveal the positioning:

Knowledge Graph Generator

Automatically maps relationships across SAP database tables, columns, and data models. Developers can see how data connects across systems and uncover underlying business insights.

Alam described it: "A new knowledge graph generator tool for SAP HANA Cloud automatically maps relationships across SAP database tables, columns, and data models, revealing how data fits together and why it matters."

General availability expected Q1 2026.

Tabular AI Capabilities

Forecasting, anomaly detection, and predictive modeling directly on structured business data. These capabilities from SAP AI Core are now generally available in SAP HANA Cloud.

Model Context Protocol Support

Makes SAP HANA Cloud data accessible to Joule Agents and custom agents. MCP provides agents with direct access to the rich multi-model engines in SAP HANA Cloud.

General availability planned Q1 2026.

SAP is enabling bidirectional data product sharing between SAP Business Data Cloud and SAP HANA Cloud. Developers can use data across both transactional and analytical workloads while maintaining business logic, KPIs, and governance.

Bharat Sandhu explained: "This capability will allow customers to reuse their existing calculation views in SAP HANA Cloud directly in SAP Business Data Cloud, keeping the business logic, KPIs, and governance intact as data models are extended across the customer's data fabric."

General availability planned Q1 2026.

The Architecture Decision

This creates three legitimate architecture options:

Option 1: SAP-Native

Use SAP HANA Cloud for everything. Best for:

Applications requiring real-time data access
Tight integration with SAP applications
Workloads that need SAP's multi-model database capabilities (relational, graph, vector, spatial in one engine)
Organizations wanting to minimize data platform complexity

Option 2: Hybrid with Partner Compute

SAP Business Data Cloud for semantics and governance, partner platform for compute-intensive analytics and AI workloads. Best for:

Large-scale analytics requiring significant compute
Organizations with existing platform investments
Teams with deep expertise in a specific platform (Snowflake, Databricks, etc.)
Workloads that benefit from partner-specific features

Option 3: Partner-Native with SAP Semantics

Work primarily in partner platform, access SAP data products through Business Data Cloud Connect. Best for:

Data teams standardized on a non-SAP platform
Analytics and ML workloads that don't require real-time SAP data
Organizations prioritizing analyst productivity in their chosen tool

The technical requirement for all three: understanding SAP's data products and business semantics.

The Critical Mistake to Avoid

Bharat Sandhu emphasized the most common integration mistake: "Don't take data out without the semantic understanding."

This is the core value SAP is protecting. Extracting data from SAP and loading it into any data warehouse is technically simple. But you lose:

Business relationships (how entities connect)
Valid transformations (what calculations are meaningful)
Governance rules (who can access what)
Business context (what the data actually means)

One developer during the experience center tour described a failed implementation: "We pulled all our SAP data into our data lake, built our analytics, and everything looked right. But the numbers were wrong because we didn't understand how SAP calculates certain KPIs. We had to rebuild everything with SAP's semantics."

SAP Business Data Cloud Connect solves this by maintaining that semantic layer as data moves to partner platforms.

What SAP-RPT-1 Changes

SAP introduced its first enterprise relational foundation model at TechEd: SAP-RPT-1.

Unlike large language models that predict the next word, RPT models predict business outcomes. They're trained on structured business data and can perform classification and regression on tabular data.

Examples: predicting delivery delays, payment risk, sales order completion.

The technical approach: in-context learning. Users provide example records in the API call. The model analyzes patterns and makes predictions without a training phase.

Brenda Bown explained the positioning: RPT models "has business context." They're designed for accurate predictions on business data, while LLMs handle natural language understanding and generation.

SAP-RPT-1 will be generally available in Q4 2025 on the generative AI hub in SAP's AI Foundation. SAP also launched an interactive testing playground where users can experience the model without coding.

This matters for the data strategy because RPT models need access to trusted, semantically rich business data. That's exactly what SAP Business Data Cloud provides.

The Real Strategy

SAP's data strategy isn't about forcing customers onto SAP infrastructure. It's about becoming essential at the semantic layer regardless of where compute happens.

The bet: compute infrastructure will commoditize. AWS, Azure, Google Cloud, Snowflake, and Databricks will compete on price and performance for raw compute power.

But business semantics won't commoditize. Understanding how SAP calculates revenue, inventory, or employee costs requires deep domain knowledge. That knowledge is encoded in SAP's data products.

As Muhammad Alam said in the keynote: "Innovations across SAP's unique flywheel of applications, data and AI put developers in the drivers' seat."

The flywheel only works if the data layer maintains business context. That's what SAP is protecting with Business Data Cloud and its partner integrations.

What Developers Need to Understand

If you're building applications or analytics on SAP data:

Understand data products first: Before choosing a compute platform, understand what data products SAP provides for your domain. These are the building blocks.

Choose compute based on workload: Real-time applications might need SAP HANA Cloud. Large-scale analytics might benefit from Snowflake or Databricks. There's no single right answer.

Maintain semantic understanding: Whatever platform you choose, ensure you're working with SAP's data products and business semantics, not raw extracted data.

Plan for bidirectionality: Data products flow both ways. You can use SAP data in partner platforms and bring partner data into SAP applications. Design your architecture to take advantage of this.

The flexibility is real. The semantic requirement is non-negotiable.

TextQL rewrote their codebase seven times to solve natural language querying at petabyte scale.

Fri, 10 Oct 2025 14:43:01 +0000

TextQL Built a Rosetta Stone for Enterprise Data — and It Actually Works

Most natural language query tools fail when you move beyond your laptop. TextQL built theirs to work with data that doesn't fit on a single computer.

The company spent three years teaching AI how to work with tables at enterprise scale. Not the tables you find in a Google Doc or Excel file. The ones with hundreds of thousands of tables, trillions of rows, and petabytes of data spread across different systems.

Ethan Ding, TextQL's CEO, explained their approach during the 64th IT Press Tour. "First generation AI products were designed for documents that fit on your computer," he said. "Try to put more than 10 gigabytes of data in an Excel file and your computer starts to fall apart."

The Real Problem

Enterprise data lives in data warehouses, ERP systems, CRM platforms, and ITSM tools. Each platform has its own query language, table format, and way of storing data. Moving data between these systems costs millions of dollars and takes months.

The expense isn't accidental. These platforms deliberately make it expensive to leave. They charge 10 to 20 times markup on the underlying infrastructure costs. A CFO who wants to move business logic from SAP to NetSuite faces a contract with Accenture that runs $50 million over five years — and only moves 10% of the actual business logic.

"If your landlord knew it cost you $50 million to move apartments, they could charge whatever they wanted," Ding said. "That's why these platforms have really high lock-in."

The Technical Challenge

TextQL built what Ding calls a "Rosetta Stone system." Instead of translating between every possible combination of query languages and table formats (an n-by-n complexity problem), they created an intermediary layer that makes it a one-by-n problem.

The system can connect to any database and translate queries on the fly. It doesn't require data migration or lengthy setup. You connect your database, ask a question in natural language, and the AI agent writes code, checks results, and tries different approaches when queries fail.

During the demo, Ding showed how the system handles a complex query about flight routes and passenger data. The AI wrote SQL queries, caught execution errors, rewrote the queries, and eventually produced visualizations on a satellite map. All without manual intervention.

"The AI is problem-solving the same way a human data scientist would," Ding explained. "You try something, it fails, you keep working through it."

What Makes It Different

Most natural language query tools work fine with documents and small datasets. TextQL focused on the hard stuff. They can handle petabytes of data across multiple systems with different schemas. The system reconciles when a customer appears as "Fred" in one database, "Fred Frankel" in another, and "Emails are not allowed" in a third.

The company uses Claude and GPT models but runs their own infrastructure layer. "We can spin up a really big computer on the fly," Ding said. "Historically, you had to do this work where the database lives. We can do it on the fly, which means you only pay for minutes in transit."

Their pricing model reflects this approach. They charge based on compute usage, not on tokens or seats. Customers commit to an amount and burn it down as they use the system.

The Hard Road

TextQL started in December 2022. They rewrote their entire codebase seven times. The first version didn't work. Neither did the second. Or the third.

"We lost every customer until January of this year," Ding admitted. "All the code is new as of January. We haven't lost a single customer or pilot since then."

The 15-person team is mostly senior engineers — dropouts from high-frequency trading firms, former researchers, and people with Master's and PhDs. The CTO was the youngest senior engineer ever at Facebook, working on a team led by Andrew Bosworth (the person who got the famous billion-dollar offer from Facebook).

Current State

TextQL raised $5 million and projects $7 to 7.5 million in revenue. They started serious customer conversations in June and closed their first major contracts. Sales cycles in this space typically run 12 months. TextQL shortened theirs to six.

Their target customers are CFO offices, financial services firms, and healthcare organizations. The team recently hired experienced enterprise sales executives who've sold to Fortune 500 companies for decades.

"Put us in a room next to competing software," Ding challenged. "Put us in a one-to-one comparison. I will bet on our system every time."

The company's approach works because they focused on the hardest problems first. When data is spread across multiple systems, when queries need to run against trillions of rows, when the cost of vendor lock-in reaches millions of dollars — that's where TextQL operates.

Most companies promise natural language querying. TextQL built a system that can actually deliver it at enterprise scale. That's a meaningful difference.