SAP BTP data and analytics is the part of the SAP Business Technology Platform that brings data together, models it, and lets people ask questions of it. It is four products doing four different jobs: SAP Integration Suite moves the data, SAP Datasphere models it, SAP Analytics Cloud presents it, and SAP HANA Cloud is the database underneath. Most of the confusion about this part of the platform comes from those four being described as one thing.
This guide separates them, explains what happens to your existing SAP BW, and says which combinations a landscape actually needs. It is written by a team that builds on the platform through our data analytics services rather than by anybody selling licences, so it also covers the case nobody else writes down: when the honest answer is that you do not need this yet.
What is SAP BTP data and analytics?
SAP Business Technology Platform is SAP's cloud platform for everything that is not a core SAP application: integration, extension, automation, and data. The data and analytics part of it is a set of services for getting data out of your systems, putting it into one model, and letting people use it.
SAP calls the result a business data fabric. Stripped of the marketing, that phrase means one thing: you build a single model of your business data that stays connected to the systems the data lives in, instead of copying everything into a new warehouse and maintaining two versions of the truth. Data can be federated, which means read where it sits, or replicated, which means copied in. The point of the architecture is that you choose per source rather than being forced into one approach.
That is the whole idea. What makes it hard is not the concept, it is that four products are involved, they overlap at the edges, and two of them have been renamed.
Where SAP BTP data and analytics sits in an SAP landscape
Picture the systems you already run. SAP S/4HANA or SAP ECC holds the transactions. There is probably an SAP BW somewhere with fifteen years of reporting logic in it. There is a CRM that may not be SAP at all, a payroll system, and several spreadsheets that people will not admit to.
SAP BTP sits beside all of that, not underneath it. It does not replace S/4HANA and it does not change how your source systems work. It connects to them, brings what it needs into one model, and gives people somewhere to ask questions that span more than one system. That last part is usually the reason a project starts, because almost every interesting business question crosses two systems that were never designed to be read together.
The same platform does other jobs beside analytics. Our write-up on SAP BTP workflow automation covers a delegation-of-authority build on the same platform, which is worth reading if you want to see what a BTP project looks like in practice rather than in a diagram. If you are still deciding how SAP fits your wider estate, our piece on SAP ERP for large enterprises covers the layer beneath.
The four SAP BTP data and analytics services, and what each one is for
Read the table first. Each service is then covered on its own, including the thing people most often get wrong about it.
| Service | The job it does | You need it when | You can skip it when |
|---|---|---|---|
| SAP Integration Suite | Moves data between systems | Sources are not already reachable in one place | A working integration layer already exists |
| SAP Datasphere | Models, catalogues and serves the data | You need one model across SAP and non-SAP | Everything lives in one SAP system already |
| SAP Analytics Cloud | Dashboards, stories and planning | People need to ask their own questions | A handful of fixed reports is genuinely enough |
What happens to SAP BW and BW/4HANA?
This is the question most SAP customers actually arrive with, and it gets answered in vendor language more often than in plain words. There are three honest options, and which one applies depends on what is in your BW rather than on anything about the platform.
Keep it. BW carries on doing what it does while new work goes into Datasphere. This suits a BW that is stable, well understood, and serving reports nobody is complaining about. It is not a failure to leave it alone, and the pressure to migrate everything usually comes from outside the reporting team rather than from the people using the reports.
Connect it. Datasphere reads BW as a source, so the logic already built there keeps working and becomes available alongside non-SAP data in one model. For most enterprises this is the sensible middle path, because fifteen years of BW logic represents real business rules that nobody has written down anywhere else.
Retire it, selectively. Rebuild the parts that are worth rebuilding in Datasphere and switch the rest off. Worth doing where BW models have become unmaintainable, where the people who built them have left, or where the underlying process has changed so much that the model is describing a business that no longer exists.
What nobody tells you: this is not a migration with an end date. It is a decision you take model by model over several years, and most large SAP customers are somewhere in the middle of it indefinitely. A plan that promises BW switched off by a fixed date is a plan that has not looked inside the BW yet.
How to decide, per model. Three questions. Is anybody still using the report? Does the logic still match how the business works? Could somebody rebuild it from the specification, or does the specification only exist inside the model? A yes, yes, no means connect rather than rebuild. A no to the first question means you have found something to switch off, which is the cheapest win available in any BW estate.
What SAP BTP data and analytics actually gives you
Five outcomes, each with the condition attached. No figures, because licence terms and landscapes differ enough that any number published here would be wrong for most readers.
One version of a number. When finance, operations and sales each maintain their own definition of revenue, meetings are spent reconciling rather than deciding. A shared model ends that. The condition is that somebody has the authority to say which definition wins, and that is a governance decision, not a technical one.
Non-SAP data in the same model as SAP data. Most useful business questions cross a boundary: SAP orders against non-SAP web traffic, SAP costs against a third-party logistics feed. Getting those into one model is the platform's strongest argument. The condition is that the non-SAP source is reachable and reasonably clean.
Analytics that survive an S/4HANA change. Reporting built directly on transactional tables breaks when the underlying system changes. A semantic layer between the two absorbs that. The condition is that the layer is maintained rather than bypassed whenever somebody is in a hurry.
Planning and reporting in one place. Forecasting against the same numbers the reports use, rather than in a spreadsheet that diverges from month three. The condition is that the planning process is stable enough to model; a process that changes every quarter will fight the tool.
Governance you designed rather than inherited. Who can see which data, where a number came from, what changed and when. The condition is that somebody owns it. Catalogue and lineage features record what you configure, and configure nothing on their own. Our piece on data management and governance covers what that ownership involves, and data privacy and security covers the obligations that come with holding the data in one place.
There is a sixth outcome people expect and should be careful about. Machine learning and predictive features exist in this stack and they work, but they need clean, well-modelled data underneath them, which is the same work as everything above. Our overview of AI and machine learning in data management covers what is realistic. Buying the platform for the predictive features before the model exists is the most common way to be disappointed by it.
When SAP BTP is the wrong answer for analytics
No vendor page carries this section and no partner page carries it either, which is exactly why it is here. Four signals. Any one of them is worth pausing over; two together mean the project is likely to disappoint whoever sponsors it.
Your estate is small and the reporting is adequate. One SAP system, a handful of reports, and nobody complaining. The platform is built for landscapes with several systems and conflicting versions of the same number. If you do not have that problem, you would be buying a solution to it.
A non-SAP warehouse is already working. If your data already lands somewhere that the business trusts and can query, the case for moving it is much weaker than it looks in a slide. The honest question is whether SAP data is genuinely hard to get into what you already run. Sometimes it is, and then there is a case. Often the real requirement is one connector, not a platform.
Nobody owns the data. This is the one that sinks projects. If no single person can say what active customer means, or who decides when two systems disagree, no platform will settle it. The technology will faithfully reproduce the disagreement in a nicer interface, and the team will conclude the tool failed. Sort out ownership first; the work is unglamorous and it is the work.
The real problem is source-system data quality. If material master data is wrong in S/4HANA, or customer records are duplicated in the CRM, moving them into a new model does not fix them. It makes the problem visible in higher resolution, which has some value, and it does not make the reports right. Fix the source, or accept that the first phase of the project is cleaning rather than building.
A fifth case, less common and worth naming. If your organisation is midway through an S/4HANA programme and the target design is still moving, building analytics on top of it is building on sand. Wait for the shape to settle.
Saying this costs us work occasionally. It costs less than a project that goes live and is quietly abandoned, which is the alternative.
What a first SAP BTP analytics project actually involves
A sequence that works, with no durations attached, because they depend entirely on how clean your sources are and how quickly your organisation makes decisions.
Pick one question, not one platform. A real business question that crosses two systems and that somebody currently answers by hand. Which customers are late paying and also have an open support case is a project. Build a data platform is not.
Find out whether the data is reachable. Before any modelling, confirm you can get to every source that question needs, and what shape it arrives in. This step regularly changes the plan, which is why it comes second and not sixth.
Agree the definitions. Write down what each term in the question means and get it agreed by the people who will argue about it later. Half a day now, or an argument in month four.
Model it in Datasphere. Only the entities that question needs. The temptation to model the whole business at this point is strong and should be resisted; a model that answers one question is finishable, and a model of everything is not.
Build the one report. In Analytics Cloud, with the people who asked for it, and show it to them before it is finished.
Then decide. Keep going, change direction, or stop. Stopping after one honest attempt is a legitimate outcome, and considerably cheaper than a programme nobody wants to cancel.
What your team needs to bring
This decides success more than any product choice, and it appears on almost no competing page.
Somebody who owns the data. One person who can settle a definition. Not a committee. Without this, the project stalls at the first disagreement and never restarts properly.
Somebody who knows the source systems. What the fields actually contain, as opposed to what they are called. The person who knows that a particular status code has meant two different things since a change in 2019 is worth more to this project than any tool.
Modelling skill. Either in the team or brought in. This is the scarcest of the three and the easiest to underestimate, because the interface makes modelling look like configuration.
A business user who will actually use the output. Named, available, and willing to look at something unfinished. A project with no such person builds what the team imagined instead of what somebody needed.
If the gap is people rather than approach, our covers what bringing in BTP capability for a defined period looks like.
Work with a partner on SAP BTP data and analytics
4Labs Technologies works out which BTP services a landscape actually needs, builds the models and the reporting, and connects the sources that are not SAP. We have delivered on the platform beyond analytics, including workflow and integration builds, which is where most of the awkward lessons come from.
The honest line first: in a first conversation, the question is often whether the analytics layer is the problem at all. A surprising share of reporting complaints turn out to be source-system data quality wearing a different hat, and that is worth finding out before anybody buys anything.
Talk to our data analytics services team
From the point this page leaves you at, a first conversation is short. You describe your landscape and the reporting you cannot get today. Somebody tells you which of the four services that actually needs, what has to be true in your source systems first, and what the first deliverable should be.
What you bring: which SAP systems you run, where reporting happens today, and the one report somebody rebuilds by hand every month. Nothing more formal than that.
If you are weighing SAP BTP for analytics, tell us what your landscape looks like and which report is costing you the most time. Let's Connect.
If you are earlier than that, two of the pages above serve different needs: the SAP BTP workflow automation build if you want to see what we have delivered on the platform, and SAP BTP staff augmentation if what you need is capability in your own team rather than a project. Our data analytics services page covers how the work runs.
Frequently asked questions about SAP BTP data and analytics
What is SAP BTP data and analytics?
It is the part of the SAP Business Technology Platform that brings data together, models it, and lets people query it. Four services do four jobs: Integration Suite moves data, Datasphere models it, Analytics Cloud presents it, and HANA Cloud is the database underneath.
What is SAP Datasphere?
SAP Datasphere is the data layer of SAP BTP. It connects to SAP and non-SAP sources, models the data into business terms, catalogues it, and serves it to whatever consumes it. Modelling is where most of the effort goes on any Datasphere project.
Is SAP Datasphere the same as SAP Data Warehouse Cloud?
Yes. SAP Datasphere is the current name for the product line formerly called SAP Data Warehouse Cloud. Older documentation and proposals use the previous name.
What is the difference between SAP Datasphere and SAP Analytics Cloud?
Datasphere holds and models the data; Analytics Cloud is what people look at. Datasphere answers where the numbers come from and what they mean, and Analytics Cloud answers how somebody explores them. Most landscapes use both, and a dashboard built without the model beneath it will disagree with the system of record.
Do I need SAP HANA Cloud as well as SAP Datasphere?
Usually not as a separate purchase. HANA Cloud is the database Datasphere runs on and typically arrives inside an existing entitlement. You name it separately when you need your own database on the platform, for a custom application or for data outside the analytics model. Check what you already have before adding it to a budget.
What is a business data fabric?
It is SAP's term for building one connected model of your business data that stays linked to the systems the data lives in, rather than copying everything into a separate warehouse. You choose per source whether to read it where it sits or replicate it in.
What happens to SAP BW when we move to SAP BTP?
Three options: keep it running as it is, connect it to Datasphere as a source so existing logic keeps working, or rebuild selected models and retire the rest. Most large SAP customers do all three at once and stay that way for years. It is a decision taken model by model, not a migration with an end date.
Can SAP BTP connect to non-SAP data sources?
Yes, and that is usually the strongest reason to use it. Integration Suite and Datasphere both connect to non-SAP databases, cloud services and applications. Getting SAP and non-SAP data into one model is what makes cross-system questions answerable.
