Skip to Content
Author's profile photo Former Member

The future of the SAP EDW: Interview with Juergen Haupt – Part II

This is the second part of the interview with Juergen Haupt by Sjoerd van Middelkoop. The first part of the interview, covering LSA++, native development and S/4HANA topics, is available here >>

This blog is also available on my company website.  This blog is cross-posted here to reach the SCN audience as well

Q: BW is now more open to non-SAP sources than it was before. Is the main development focus now on supporting any data model and source in BW modeling, or is the focus more on hybrid scenarios?

We are continuously improving and extending BW’s possibilities in respect to also supporting non SAP data. That means we do not force the use of InfoObjects any longer but enable straight forward modeling of persistencies using fields and defining datawarehouse semantics using Open ODS views on top of it. This allows customers to respond faster to business requirements. Next to that, we also support landscapes where a customers use SAP HANA as a kind of a Data Inhub or landing-pad replicating data from any source to HANA and modeling natively on that data. From LSA++ perspective these areas are like an externally managed extension of the Open ODS Layer.

When it comes to data warehousing the customer can integrate these data virtually with BW data or stage them via generate data flows to BW to apply more sophisticated services.

Q: How did BW on HANA and LSA++ change the way you see BW development?

BW on HANA now provides the option to work a lot more with a bottom-up approach. It means that you can evolutionary improve your models and your data starting for example with fields that define Advanced DSOs in the Open ODS Layer ending up with Advanced DSOs that leverage also InfoObjects to provide advanced consistency and query services. These Advanced DSOs are shielded by virtual Open ODS Views allowing a smooth transition between these stages if a transition is necessary at all. This flexibility is highly important to integrate non-SAP data in a step by step manner. I think this complements the proven but slow top-down approach in BW projects like we have seen them in the past.

Q: Talking about development in the current landscape. Customers that are have migrated to HANA a while ago and are remodeling their current LSA structures are finding it hard to keep up with developments in BW and the new functionality rapidly coming available. How can customers develop and remodel without investing in objects that will become obsolete soon?

This is a real challenge. Not a technology challenge, but more of an architectural and functional challenge. How will my landscape of the future look like what are the functions and features that provide most value for my business users? I would advise customers to think of their EDW strategy from a holistic point of view. That means for example you can’t see BW on HANA without considering SAP’s operational analytics strategy. Overall BW is not an island any longer, BW is now tighter connected than ever to other systems. So we have to think about the role in the future of all of our systems and what services they should provide.

So when customers think about going on BW on HANA, normally the first question is “Do we go greenfield or are we going to migrate?” This is very understandable question but I fear that this question does not go far enough.

Q: Most customers, when on the decision point to migrate or greenfield, consider their current investments and make sure these investments will not be undone.

Yes. Very often, but not always. Over the last time we s a steady increase of customers choosing a greenfield approach. They see that introducing BW on HANA is more than just a new version that you upgrade to. They are aware that BW on HANA means running and developing solutions on a real new platform, and they do not want to bring their ‘old’ style solutions into this new platform. So these customers go for a greenfield approach. This approach does not prevent you of course to transport in some of your existing content that you want to keep and maybe invested heavily in.

Q: This point of view is quite opposite of SAP’s ‘non-disruptive’ marketing strategy

What does non-disruptive mean? It is non-disruptive when it comes to migrating existing systems-yes. But does a ‘non-disruptive’ strategy really change the world to a better one? If you look on BW on HANA just as a new better version a non-disruptive migration would be your choice. But if you have the idea that BW on HANA is something really new that allows you creating values you never could offer before and that enables you to rethink the services you want your BW data warehouse to provide bringing it to new level then you cannot be non-disruptive.

It’s like driving into the Netherlands from Germany, I only notice it by chance because the road signs are different – the border has disappeared at least for car drivers… Compared to the EDW I would say that the border we used to have between EDW and sources has always been a very strict border. These borders between systems are more and more disappearing. And this has a lot of influence on all systems and the solutions we build in future. And this is related again with disruption. I can continue to work like I did it ten years before still stopping at borders that have disappeared in the meantime…….

Q: With the Business Suite on HANA and S/4HANA, embedded BW is seen by many as a viable option to use instead of a standalone BW system. In what cases should customers opt for an embedded scenario?

The question here is a matter of your approach. Let’s assume you start with S/4HANA Analytics or HANA Live, you can do everything with these virtual data models as long as business requirements and SLA’s are met. Then, the question is what to do when we need Data Warehousing services. Why not use the embedded BW? Yes, especially for smaller-sized companies, this will be an option. There are limitations of course. I think the rule of thumb here is that an embedded BW system should not exceed 20% of the OLTP data volume. With the HANA platform it is a matter of managing workload.

But there is also a certain danger with this approach and it does not derive just from the amount of BW data you should not exceed. The bigger the company is, the more likely you will have more than a single source. In this case you should start from the very beginning thinking about an EDW strategy. Otherwise you will sooner or later start to move data back and forth between these embedded BWs. So most importantly when making decisions about using the embedded BW is have a long-term vision about the future DWH landscape. In this context it is important to mention that with SAP HANA SPS9, we have the multi-tenant DB feature that allows us to run multiple databases on the same appliance. So sooner or later we will see BW on HANA and S/4HANA running on different HANA DBs but on the same appliance meaning that as there will be no boundary any longer then between the BWonHANA and S/4HANA. Thus you can share between them data and models directly. This would offer the benefits of the embedded BW but with a higher flexibility and scalability.

Q: So what you are saying is that embedded BW is an option for now in some cases, but with HANA multi-tenant DB in the near future and multi-source requirements stand-alone BW is the better option?

That depends on what your situation and what you are developing, for smaller clients and simple landscapes, I can imagine embedded scenarios to function very well, even in the future. For most other scenarios yes, I think stand-alone BW with multi-tenant DB is the better option.

Thank you very much for this interview!

You are most welcome!

This concludes my two-part blog of the interview I conducted with Juergen Haupt. I would hereby like to thank mr Haupt for his time and cooperation, SAP for their cooperation in getting this published, and the VNSG for getting Mr. Haupt in Eindhoven.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.