SAP BW/4HANA: Data Acquisition, Modeling, and Life Cycle Management

SAP BW/4HANA: Data Acquisition, Modeling, and Life Cycle Management

SAP BW/4HANA: Data Acquisition, Modeling, and Life Cycle Management

Christian Savelli & Joe Darlak

Enjoy the second webinar within our SAP BW/4HANA WebinarSeries, hosted by Comerit’s own Chris Savelli and Joe Darlak! Our speakers explain how the robust functionality provided by this new technology is useful when it comes to data modeling and life cycle management. The session ends with a brief Q&A, re-caped in part below.

If a company already has SAP4HANA implemented, is SAP BW/4HANA really useful? What would be a good way to present a case for BW/4HANA to a client?

 BW/4HANA remains useful in the same way it has been in the past: as an enterprise data warehouse for all your BI reporting needs, including reporting on non-SAP data sources. It serves as a separate environment to S/4HANA, so reporting on large datasets does not impact and consume memory/CPU from your S/4 system.

Some clients are using embedded BW on S/4HANA and there are cases where clients are using BW/4HANA as a separate box. What would be the best approach?

This depends; it’s a case-by-case basis. If you need some train analysis, if you needed to reach the data with external sources, embedded BW analytics would not be the best approach, especially because being an operational system, S/4’s data aging is a little different than BW’s. You may want to keep about 7 years’ worth of data in the BW application as a separate box, and meanwhile you’d just want to protect your HANA box in S/4 with a more restricted data lifecycle. It really is a question about the user concurrency and the data volumes that are going to be reported, and how that impacts memory consumption and CPU utilization on your system. If you’re going to try to pack all these pieces into one system, it’s going to incur a lot of risk on your system; you’re going to have out-of-memory errors, you won’t have enough CPU to run your operational processes in that system, and you certainly don’t want to go down that road. You’ll need to make sure that your systems are appropriately sized, and if you’re going to embed your reporting into your operational system, you’ll need to make sure the sizing is strong enough to support this.

Why would you use a DSO? It seems you could replace the DSO with a Hana view against the original table

DSOs still provide a lot of value, and there’s a lot of functionality packed into the advanced DSO; it supports many different use cases, whereas a table in Native Hana is just that – a table. You could certainly build a view on top of that, but if you don’t want to use BW going forward, you won’t be getting any of the analytic capabilities that BW provides. We see a lot of clients experimenting with Native HANA solutions, but what’s interesting is that they want all the functionality that BW provides, and they want it in Native HANA. Unfortunately, Native HANA is just not there yet. I’m sure someday, there won’t be any difference between data warehousing on Native HANA and BW/4HANA, but for now, that remains to be seen. DSOs still provide functionality such as data propagation (there are still use cases for data staging and denormalization), corporate memory, data acquisition, and reporting.