Skip to Content


For many years, the absence of powerful analytic modeling and processing within SAP’s R/3 and Business Suite applications led customers to install an instance of Business Warehouse (BW) next to such a system. Essentially, BW closed the analytic gap of those solutions. To that end, data was loaded from R/3 or the Business Suite into BW. Maintaining those load processes, two systems and the resulting time lag between the data being created in R/3 or Business Suite and the data being visible in BW reporting was the price for this workaround. Now, that operational analyticsis possible within S/4HANA, this workaround has become obsolete. This is sometimes mis-perceived as BW becoming obsolete. Let’s have a look into the situation to understand what is dead and what is alive.

In my recent blog on S/4HANA and Data Warehousing, I’ve made the point that data warehouses – in general – are still necessary, even with the advent of operational analytics in S/4HANA. Here, I like to tackle the topic from BW’s point of view. To that end it is important to understand that BW can be deployed in two ways; fig. 1 shows this visually:

  • embedded: into any application that runs on NetWeaver like SAP CRM, SCM, HR, FIN etc, and
  • stand-alone: as an enterprise data warehouse (EDW) that allows to harmonise data originating from various, disconnected systems so that it can be analysed in a consistent way. This allows to get an understanding across many disparate business processes that exist in an enterprise.

Deployment options for BW.
Figure 1: Deployment options for BW.

So in both deployment options, BW exists and can be used for operational or cross-system analytics. This leads to 4 potential situations, also depicted in fig. 2:

  1. Embedded, used for operational analytics
    • BW reuses application’s storage, semantics, security.
    • No redundancy.
  2. Stand-alone, used for operational analytics
    • Data, semantics, security is copied to BW as a workaround as no analytics options are available in the app.
    • This is the case that should be replaced as it is sufficient but not necessary.
    • It is not ideal but a workaround to fill a gap within the app.
  3. Embedded, used for cross-system analytics
    • BW within NetWeaver (on which S/4HANA, SAP Business Suite, SAP CRM etc are built) is used as a DW.
    • Technically this is possible.
    • However, it is currently not recommended due to concerns around workload + governance around the system.
  4. Stand-alone, used for cross-system analytics
    • BW as a stand-alone data warehouse.
    • This is the most frequent deployment of BW.

Theoretical combinations of BW use cases and BW deployment options.
Figure 2: Theoretical combinations of BW use cases and BW deployment options.

Case 2. is solved in S/4HANA by replacing it with case 1. – which is not a prominent but yet a fact. This frequently leads to the misunderstanding that “BW was obsolete” which should actually read that case 2. is mostly obsolete (in the context of S/4HANA) . Furthermore, case 4. continues to be a valid, as is any data warehouse approach that blends S/4HANA data with data from other systems for deeper insight into what is going on in the enterprise. The advent of IoTscenarios makes this even more imperative than before.

This blog has been cross-published here. You can follow me on Twitter via @tfxz.

PS: The figures can be found in this slidedeck.

PPS: There is an excellent real-world example for case 1. in the blog How Nucor Simplified Their BW Landscape By Using An Embedded BW, maybe with a certain overlap with case 3.

You must be Logged on to comment or reply to a post.
  • Hi Thomas,

    The statement regarding case 3 "currently not recommended due to concerns around workload + governance around the system" is quite vague.

    Can you please explain the reasons, why BW Data Warehouse structures can't co-exist in the same DB instance with S/4HANA? SAP are telling us that HANA can perfectly support both OLAP and OLTP workloads.

    The consolidation of both datasets in a single instance of the DB ensures the full data consistency during normal operations and even in the case of DB recovery, that it much more difficult to achieve in the case of separate DB instances. You yourself referred to the issue with DB stamps that becomes immaterial in the case of consolidated DB instance.

    Thank you,


    • To me the "it is currently not recommended" is very disappointing.  I'm hoping that this statement is removed someday so that we can reduce ETL.

    • Hi Alex and Mel,

      look, of course, you can put multiple systems onto one and the same HANA box, especially using the multi DB feature shipped with HANA SPS9 and given appropriate sizing. However, that comment appeals to common sense, namely that if you run applications A, B, C on the same HANA box then you create a dependency of A, B, C which might make things more difficult to manage those systems.

      Assume that application A requires that an SP is applied and that A's SP implies that a new HANA revision needs to be applied. This forces applications B and C also to run on the same HANA revision which is hopefully not a problem but can potentially require to also apply SPs to B and C respectively. Also, if one of the applications requires a moment of downtime of HANA then this downtime is also imposed onto B and C.

      So in summary I think it's a fair statement to not guide customers into those situation unless they have thought this through. There is customers that run 2 or more applications on the same HANA box. But very frequently, those applications are heavily related, e.g. a data mart, a BW system or a CO-PA accelerator. Then the dependency is not only technical but natural.

      I think it's as it is in other parts of the industry: big container ships are more efficient than smaller ones but are more difficult to manoeuvre and require big harbours, i.e. they are less flexible. It's not about good or bad, black and white but about the right trade-off that satisfies your needs.

      I hope this helps.


      • Hi Thomas,

        Thanks for the reply.  I would agree with you for S/4HANA on-premise, but what about S/4HANA on-cloud private/manage.  With a forced quarterly upgrade to the latest GA version, is it possible possible to have CRM, ECC, HR, PLM, APO, etc on one SAP HANA system?  If so, can BW be added to the above system to do analysis of cross application data?

          • Thanks, Thomas.

            It's still disappointing.  I guess I got caught up with the "ERP, CRM, SRM, SCM, PLM in one system*" statement.  I didn't see the asterisk which means available in the future.

            Is it possible to create a select query between two tables that are in different tenant databases in a SAP HANA system?

            Is it possible to create a select query between two tables that are in different SAP HANA systems?


          • Hi Mel,

            ok, I think you are mixing up a number of things. Let me try to sort this out:

            • Yes, SQL across tenants is possible. See this slide deck for further info:…
              Please beware that my arguments go along system administration and management concerns and not SQL access or the like.
            • The picture you post talks about MCOD, i.e. "multi components (= apps), one DB server" whereby components can be separated by schemas or tenants.
            • Scenario 3 in my blog, i.e. the one with the yellow smiley in fig. 2, is a single component (namely a NW system that has an in-built BW and that hosts an SAP app like CRM or ERP) on one DB server. So BW and, say, ERP would not only share the DB server but also the application servers. They would even run off the same DB schema. This is not MCOD.
            • For a discussion of MCOD and HANA please refer to the note above.

            I hope this helps.


          • Hi Thomas,

            I thought that I understood your explanations, but the reference to the use of single component in scenario 3 in your blog confused me again.

            With single component like CRM or ERP having in-built BW and, say, EP, your reference to the dependencies of A, B, C (like CRM, BW, EP) loses the ground as all these roles are shared by the same single application and have common code and maintenance. They can't have any individual dependencies on the version of HANA as they aren't individual applications, as you explained to Mel in your response.

            The reference to dependencies is actually valid for MCOD, and I thought that this is what you were talking about, but you say that this is not the case...

            Can you please explain your position.

            Sorry for hassle, but I am really confused.

            Thank you,


          • Hi Alex,

            sorry, you are right. My initial answer has been messy in the sense that I should have pointed out that scenario 3 in this blog is about "embedded" (= one NW system and BW inside that NW system being used) and not MCOD. I should have distinguished this early on. I only know very few customers who run something like scenario 3 - all of them are very specific cases or somehow blur scenarios 1 and 3 - but there is quite a number of MCOD customers like you.

            However, in both cases, concerns circle around managing workload (app A grabbing all resources and thus stalling app B) + system management (see dependency example above) albeit in different ways.

            Does this help?


          • Hi Thomas,

            Yes, it does!

            Both problems are absolutely valid and we do face them with MCOD.

            We found an efficient solution for DB resource ring fencing on Oracle RAC, but I am not sure that it will be applicable to HANA. System management issue so far caused only minor inconveniences.

            Thank you for an excellent blog, and particularly for very useful links to the additional resources!



      • Hi Thomas, thank you for explanations and references to SAP Notes, now I understand what you had in mind!

        I do like your analogy with container ship šŸ™‚ ! We do run for many years tightly coupled CRM, ECC, CPS and PI in the same instance of MCOD Oracle DB and do observe significant benefits due to consolidation, particularly cost savings and streamlined DB recovery in DR drills. I can't deny the validity of your concerns regarding more complex governance processes required for such complex systems, but from our experience consolidation simplifies the governance as well.

        None of these tightly coupled applications can run separately from others anyway, so they have common maintenance downtime. And so far SAP maintained the downward DB compatibility so well, that we didn't experience any problems if we had to patch/upgrade any application ahead of others. For example, PI is upgraded to 7.31, while CRM is still at 5.0 level. We have similar experience with another MCOD DB where we are running together EP 7.3, BW 7.0, BIP 4 and SRM 4.0.

        In development we actually have 13 different SAP applications running on the same instance of MCOD DB šŸ˜‰ You can imagine the benefits of running single instance of DB instead of 13.

        Assessing the migration to HANA, we definitely don't want to lose these benefits. We don't want as well to perpetuate the duplication of our SAP transactional data in BW, and would dedicate it to non-SAP data as described in your scenario. The reporting from transactional SAP systems and BW storing data from non-SAP transactional systems seems to be the most cost-effective option, assuming that all these systems can use a single instance of HANA DB. This was the real reason of my enquiry.

        Thank you again,


  • Hello Thomas,

    Nice Blog.

    I need to know about the impact on Existing BW extractors - FI , LO etc after we migrate to S/4 HANA. I did not find any specific blog/ article on web. Can you kindly direct me to right path?

    Thanks in advance.