From DaaS to DaaP: SQL Isn’t Enough — You Need Accountability

DaaS vs DaaP

Table of Contents

1. Introduction: “What Even Is Data?” They say data is sacred, but we’re still stuck converting numbers to text in Excel.
2. DaaS: Here’s the Data — Now Good Luck Sharing data is easy. But what about context, responsibility, and meaning?
3. DaaP: Thinking of Data as a Product Not just transferring, but crafting lovable, usable, decision-driving data.
4. The Evolving Role with DaaP: From “Data Supplier” to “Data Product Owner” The teams winning today aren’t writing queries — they’re understanding users.
5. DaaS vs. DaaP: One Table, Two Worlds Two teams look at the same table — one shrugs, the other writes strategy.
6. 2025 and Beyond: The Era of Value, Not Just Data Data is no longer just transmitted; it’s owned, processed, and turned into value.
7. Where Do We Start? With Culture, Small Steps, and Bold Decisions DaaP isn’t just a vision anymore — it’s a roadmap, a team effort, and a shift in mindset.

Data. Everyone keeps chewing on the same old gum: “Data is the new capital.” “Data is the new oil.” “We make data-driven decisions.” One day, a guy proudly said: “Thanks to data, we even know which desk I’m more productive at.” I thought: This isn’t “data-driven work” anymore — it’s corporate feng shui.

But ask the real questions: Which data? In what condition? Who actually benefits from it? Silence. The only sound is the deep hum of Excel in the background.

This is my world. For over 25 years, across many European countries and Turkey, I’ve personally witnessed how hundreds of companies have wrestled with data during large-scale digital transformation projects based on SAP. We said ERP, we said CRM, we said BI… But more often than not, what we were left with was: “We got the data, but nobody’s using it.” Because the real issue isn’t accessing the data — it’s making it actionable, decision-driving, trustworthy, and yes, even a little lovable.

In most places, what they call “data” is nothing but a CSV-shaped disappointment. A patchwork of failed migrations, half-filled forms, and free-text entries that started with “let’s just jot this down for now, bro.”

I once witnessed this actual conversation at a company:

– “Boss, is this data accurate?” – “Which sheet?” – “The file named ‘Final_V2_real_final_final2.xlsx.’” – “Ah, then it must be.”

See, we say we’re “talking about data,” but what we’re really doing is wrestling with file names, version wars, and endless copy-pastes. In some companies, asking for “data access” is as painful as begging pardon from the Byzantine Empire.

And the worst part? Even if you get the data, your job is far from over. Because that data is usually either incomplete, dirty, or includes bizarre notes in the “description” column like “we need to clarify this!!!” What AI are you planning to train with that? At best, you could train a desperate PowerPoint deck. And even that’s a stretch.

So here’s what this article is really about: Is it more important to provide data, or to make it usable?

In other words:

Will you just open the pipe and let the data flow, Or will you clean it, package it, and make it ready for the user?

The difference is as big as muddy tap water versus bottled mineral water. One says, “Here’s your data.” The other says, “Here’s your decision.”

Now, as we charge into 2026, let’s be clear: It’s not the data itself that matters. It’s how it’s delivered and what impact it creates.

And that’s exactly what we’ll dive into in this article: DaaS (Data as a Service) vs. DaaP (Data as a Product).

And yes, we’ll poke some fun at the clichés of the industry along the way. Expect a bit of roasting, a bit of revealing, and a lot of reality. Ready? Let’s go.

2. DaaS: Here’s the Data — Now Good Luck

DaaS — Data as a Service — sure sounds fancy. At tech expos, you’ll hear people say things like: “We built a DaaS layer in our microservices architecture.” That’s my cue to ask for a glass of water — because as the word count goes up, reality usually goes down.

So what does DaaS really do?

“Here you go, bro. Here’s the data you asked for. JSON? CSV? Want it without columns? Extra header rows? Explanations? Nah. The data’s just… there.” That’s DaaS for you — it makes data accessible, but not understandable or usable. It’s like going to a library and picking a book off the shelf. But what if it’s in Chinese? And if you manage to translate it, what if pages are missing?

That’s DaaS: It delivers data, but doesn’t understand it, explain it, or own it.

One common scenario I see in companies:

– “This report has missing data.” – “But I pulled all the fields.” – “Yes, but the ‘Customer Type’ field is empty.” – “Well, I didn’t filter for that…”

You’ll chuckle at that — but also clench your jaw remembering past projects. Because the DaaS mindset operates like this: “I gave you the data. Not my problem anymore.”

The data producer doesn’t care. The data consumer is left to fend for themselves. What’s left in between? A bitter dashboard and an angry executive.

Just last year, in one company, we loaded all the data into Power BI. Everything was technically correct. But the user asked:

– “Is this data accurate?” Response: – “We pulled it via API — whatever’s in there, that’s what you see.” Meaning? – “Meaning… we don’t actually know, but it seems accurate…”

That, my friend, is pure DaaS. A system that transports data without knowing — or caring — what’s inside the box.

Okay, you’ve got the data. But now what?

Is it clean? Is it consistent? What if the same customer is entered under three different names? Are the numbers up-to-date? Are they explanatory? Or just a dump of “something someone once collected for reasons unknown”?

Here’s the real issue with DaaS:

It delivers the data, but not the value.

3. DaaP: Thinking of Data as a Product

To understand the DaaP approach, let’s start by asking ourselves:

“Who am I giving this data to?” And right after that, the real question: “Is this data solving a problem for the user, or is it creating one?”

See, most data projects fail precisely because these questions aren’t asked. There’s data, but no decisions. Dashboards, but no trust. Reports, but no action. Because the data was merely delivered, not designed.

This is where DaaP changes the mindset: thinking of data as a product.

Are we talking ingredients or a meal?

DaaS gives you the ingredients: flour, oil, milk, eggs… But what if you don’t have time? What if your oven doesn’t work? What if you don’t even know what to cook? You go hungry.

DaaP, on the other hand, serves you a hot, delicious meal — on a plate, with a fork, napkin, maybe even a slice of lemon. That’s usable, intentional, problem-solving data.

What does DaaP mean technically?

DaaP is not about just storing or sharing data. If a dataset is a product, it needs a full lifecycle:

• Needs analysis: Why does this data exist? Who will use it?
• Design: Schema structure, naming conventions, description fields, data types, indexes…
• Development: Extracting from source systems, cleaning, standardization, validation.
• Documentation: Data dictionary, field descriptions, usage guides.
• Quality control: Catching errors, consistency checks, alerts.
• Versioning: Update frequency, history, rollback plans.
• Feedback: Listening to user input and improving accordingly.

None of these come “by default” in a typical data pipeline. But teams working with the DaaP mindset don’t skip them. Because they know a data product — just like any software product — lives and grows through user experience.

We were once preparing data for a sales forecasting model. The data engineers did an excellent job:

• Reports were delivered on time,
• The API was fast,
• Database normalization was on point.

But the business side was unhappy.

“We can’t work with this data.” “We can’t separate sales channels.” “Product categories are missing.”

Why? Because the technically correct data was functionally meaningless. It didn’t serve the user experience.

So I sat down with someone from the business team, one-on-one. It turned out what they actually needed was: “Channel-based, product group–level data, broken down by week, with at least 12 months of history, and segmented by promotions.”

But our data layer didn’t know that — because we had built a pipeline, not a product.

That day I told the team:

“From now on, we don’t just write ETL. Delivering data without understanding the user’s workflow is well-meaning, but ultimately pointless. What will the user do with the data? Make a decision? Build a report? Give a presentation? Trigger automation? Delivering data without knowing these is like building a product without ever talking to the customer.”

From that day forward, our team adopted a motto: “Don’t deliver data — deliver value.”

DaaP: A New Culture Within the Organization

DaaP isn’t just a technical approach. It’s a cultural one.

• It strengthens the bond between IT and business teams,
• Encourages ownership over data,
• And ensures responsibility isn’t anonymous — it’s assigned.

I always say: there are two things in corporate life that are always orphaned:

1. PowerPoint drafts
2. Data tables

Both eventually get the same reaction:

“This feels incomplete.” “Wait, who made this?”

But in an organization working with a DaaP mindset, data doesn’t go unclaimed. Every dataset has a Product Owner — just like in software projects.

DaaP is not a choice. It’s a necessity.

We’re speeding toward 2026. AI, automation, smart decision systems… they’re all the rage.

But if we still don’t know which data to use, we’re just moving data around.

To support business outcomes with data, the dataset must be:

• User-friendly
• Trustworthy
• Documented
• Simple

Data should not be built to be “used.” It should be designed for the user.

And that’s only possible with the DaaP approach.

Because DaaS gives you data. DaaP gives you decisions.

4. The Role is Changing with DaaP: From “Data Supplier” to “Data Product Owner”

In the past, data didn’t really have an owner. It just floated around. Nobody claimed it, but everyone used it somehow. A classic case of the tragedy of the commons.

But things have changed. Data is no longer just an output — it’s a product. And like any product, it needs an owner, a lifecycle, and accountability. Otherwise, data systems turn into filing cabinets with lost keys.

This is where the DaaP approach changes the game.

The “Data Supplier” mindset:

– “I delivered the data. If they don’t use it, that’s their problem.”

The “Data Product Owner” mindset:

– “Who’s using this data, how often, and for what?” – “If there’s an error, they should call me.” – “If something’s missing, I’ll add it to the roadmap.” – “If usage increases, I’ll plan for capacity.”

CTO’s Desk: A Real Example

In one project, there were 7 subsidiaries under a holding group. All of them used SAP, but each kept their data separate. Every team said, “Our system is different.”

The management wanted to standardize financial reporting. They said, “Consolidate the data.” In the first week, everyone sent their reports — but no one owned the data.

Every day, the same scenario:

– “Is this figure accurate?” – “It came from accounting.” – “Accounting says sales entered it.” – “Sales: We pulled it from inventory.” – “Inventory: Check the ERP.” – “ERP: It doesn’t show in the SQL logs.”

This isn’t about lack of data — it’s about lack of ownership. And the cost of this chaos is paid in time, trust, and decision quality.

Eventually, I said:

“Listen, someone has to own this data. Someone who knows the source of the number, writes the explanation, plans the update schedule, and says ‘this is my responsibility’ when there’s an issue.” We gave it a name: Data Product Owner.

You wouldn’t believe it, but the strongest pushback didn’t come from IT — it came from the business units:

– “So now we’re responsible for this data?” Yes. If you’re using it, you’re also a co-producer of it.

Projects That Run on “We Just Pull the Data…”

Teams operating with a data supplier mindset often sound like this:

– “We did what was asked.” – “We opened the fields you wanted.” – “We wrote the query — it works.” – “The dashboard’s ready, but they’re not using it.”

But here’s the truth: An unused dashboard is just an expensive JPEG. And this job doesn’t end with showing a table. Any system that doesn’t make data truly usable doesn’t create real value.

Why is there no data ownership in organizations?

Because data often lives in a space no one wants to be responsible for. If it’s wrong, IT gets blamed. If it’s incomplete, the business unit gets blamed. If it’s messy, it’s ERP’s fault. Nobody steps up to say, “This is my data.”

But with a DaaP culture, you build a system like this:

So now, when someone asks “Where does this data come from?” — the answer starts with who it comes from. In companies that get this right, data producers and data consumers sit at the same table. Data is no longer just something that “passes through” — it becomes something that is owned.

Data Product Owner = The New Guardian of Corporate Memory

As data becomes productized, the organization’s memory becomes clearer. Now, when someone new joins and asks, “Why is this field empty?” — there’s an answer. When a dashboard breaks, there’s no panic — there’s accountability. And when AI models are trained, they’re trained with awareness of the source.

In short, DaaP isn’t just a data strategy — it’s a model of organizational responsibility. The Data Product Owner isn’t just accountable for the data, but for the entire process surrounding it.

5. DaaS vs. DaaP: One Table, Two Worlds

Imagine two teams sitting at the same table. Both work with data. They look at the same tables. They open the same reports.

But while one is trying to make the data actionable, The other is still focused on delivering the data.

This isn’t just a difference in perspective — it’s a difference in approach. DaaS and DaaP both think they’re solving the same problem — but they actually answer different questions.

DaaS (Data as a Service):

• “You asked, I delivered.”
• “The data’s there. Take it and use it.”
• “They told us what to include — we did that.”
• “You define the fields, I’ll pull the data.”

The DaaS mindset usually defines the job in technical terms: Data = A service. Requests = A list. Solution = ETL processes, query outputs, API connections.

How the user will use the data, for what purpose, whether they understand or even trust it — these are typically out of scope.

DaaP (Data as a Product):

• “Who will use this data?”
• “What business decision does it support?”
• “If a field is missing, why is it missing?”
• “How often should this data be updated?”
• “Is the user documentation sufficient?”
• “If there’s an anomaly in the data, how will it be detected?”

The DaaP mindset cares not only about accessibility, but also usability and sustainability. Data is treated like a product:

• It has versions
• It undergoes quality checks
• It has a support process
• It comes with user guides
• And most importantly: It has an owner.

Why is everyone still stuck in DaaS?

Because DaaS is easy. – For technical teams: Receive the request, process it, deliver. – For business units: “I just want access to the data.” – For management: “We have a data infrastructure.”

But what’s easy is rarely sustainable. The first crisis, the first incorrect report, the first trust issue shakes the whole system. And everyone starts pointing fingers:

“Who did this?” “Why is this number off?” “When was this data last updated?”

No one answers — because in the DaaS world, data exists, but context doesn’t.

There are two worlds: In one, data merely flows. In the other, data carries meaning.

In 2025 and beyond, the key differentiator won’t be producing data, but producing value from it. And those who succeed won’t just have data — they’ll have data culture.

6. 2025 and Beyond: The Era of Value, Not Just Data

It’s 2025. AI applications have exploded. Data lakes, data meshes, LLMs, RAG architectures are everywhere. And yet, in some companies, data is still at this level:

“We updated it in Excel — this is the latest version, bro.”

Worse yet:

They say they “work with data,” but in reality, they’re just “working in a place where data exists.”

In this era, saying “we have data” is like saying you have electricity — but no lightbulb. Unrefined, ownerless, contextless data is just excess weight. And the heavier it gets, the more projects rely not on insight — but on chaos.

Old Habits Can’t Solve New Problems

Most data problems aren’t technical — they’re cultural. This isn’t just an IT issue — it’s an organizational awareness issue.

Picture a manager: They have seven dashboards, but trust none of them. There’s an analyst, but they double-check everything in Excel. There’s a model, but they go with their gut in the end.

Because the data doesn’t inspire trust. And that lack of trust is what sinks million-dollar projects.

The New Normal: Data Without Value Is a Burden

If you want results from AI… If you’re building autonomous decision systems… If you’re planning real-time operations…

Then you need to look at your data and ask:

• Is it consistent?
• Is it traceable?
• Is it well-documented?
• Is it user-friendly?
• Is it owned?

If your answer is “ehh…”, then you’re still in the world of DaaS. But the world has moved to DaaP. And that transition isn’t just IT’s job — it’s a journey for the whole company.

So What Should We Do?

Every dataset must have an owner – Who updates it? – Who verifies it? – Who uses it?

Every dataset must be documented – What’s it for? – How often is it updated? – What systems feed into it?

Datasets must be versioned, improved, and tracked — just like a product – What did version 1.0 include? – What changed based on feedback?

User experience must be part of the data system – Meaningful interfaces instead of complicated queries. – Clear guides instead of dense documentation. – Teams that act as data guides, not just data analysts.

It’s No Longer About Having Data — It’s About What You Do With It

Everyone has data. But the real difference is: What do you do with it?

It’s not about how much data you have, It’s about how meaningful and usable it is.

A simple but tough truth for 2025 and beyond:

Moving data is easy. Delivering value is a skill. And that skill starts with a DaaP culture.

7. Where Should We Start? — With Culture, With Small Steps, With Determination

You’re probably asking: “Where do we start with DaaP?” The answer is simple — but real: Start with culture. Start small. Start with a committed team.

1. Start with Culture

Data isn’t just IT’s job — it’s everyone’s. Those who create, use, and question data must sit around the same table. Because data isn’t just something to be transferred — it’s something to be explained.

2. Start Small

Big data projects often equal: Big expectations + unclear ownership = disappointment.

So start with one focused, finishable data product serving a clear group. Examples:

• Just inventory data
• Just bonus calculations
• Just overdue invoice analytics

Finish it. Measure it. Learn. Then grow.

3. Don’t Avoid Ownership

“Whose data is this?” is just as important as “Whose invoice is this?”

Every dataset needs a responsible owner, a clear purpose, and a lifecycle. And yes — this ownership should belong not to IT, but to the business unit using the data.

This article isn’t just about DaaS vs DaaP.

It’s written for everyone who works with data to ask themselves:

Am I just delivering data, or am I enabling something through data?

Because if there’s data but no action — then all you’ve done is moved a file. But if that data drives decisions, produces impact, creates momentum — then what you have isn’t just data.

You have a product.

Thanks to everyone who made it to the end of this long piece. I hope it helps you see your team, your dashboards, or your company in a new light.

Talking about data is easy. Producing value from it — that’s the real challenge. And it’s a challenge we can solve. Together.

Warm regards, Dipl.-Ing. Deniz Cengiz