With the recent announcement of BW/4HANA some questions arise on the motivation for a new product rather than evolving an existing one, namely BW-on-HANA. With this blog, we want to shed some light into the discussions we have had and why we think that this is the best way forward. Here are the fundamental 3 reasons:
Nowadays, HANA has become much more than a pure, classic RDBMS that offers standard SQL processing on a new (in-memory) architecture. There is a number of specialized engines and libraries that allow to bring all sorts of processing capabilities close to where the data sits rather than the data to a processing layer such as SAP's classic application server. Predictive, geo-spatial, time-series, planning, statistical and other engines and libraries are all combined with SQL but go well beyond the traditional Open SQL scope that has been prevalent in SAP applications for almost 3 decades. Please recall that Open SQL constitutes the (least) common denominator between the classic RDBMS that have been supported in SAP applications. Long time ago, BW has broken with that approach a bit by introducing RDBMS specific classes and function groups that allowed to leverage specific SQL and optimizer capabilities of the underlying RDBMS. Still, the mandate has to be pushing BW's data processing more and more to where the data sits. Accommodating a "common denominator" notion (i.e. complying with "standard-ish SQL") impedes innovation at times as it stops adopting highly DW relevant and effective capabilities from HANA.
BW has been originally architected around the properties and the cost models imposed by the classic RDBMS. Over the past decade, cautious re-architecting has allowed to continuously innovate BW and to safeguard the investments of the BW customers. There has been a strong emphasis on keeping newer versions of BW as compatible with past versions as possible. Similar to sticking to "standard-ish SQL" this impedes innovation in some areas. BW/4HANA breaks with this strict notion of backward compatibility and replaces it with tooling for conversions that might require user interaction here and there, thus some effort. However, this allows for removing some legacy not only inside a software product but also in existing DW instances that move from BW to BW/4HANA.
Now, with some "baggage" removed it has become easier to focus on new, innovative things without being squeezed into considerations about backward compatibility in order to keep older scenarios going that you would build differently (e.g. with BW/4HANA's new object types) nowadays. So and in that sense, BW/4HANA is a much better breeding ground for innovations than BW-on-HANA can ever be. This is not because BW-on-HANA is a bad product but because it comes with a guarantee of supporting older stuff too which BW/4HANA does not.
Finally, and that is basically the result of 1. and 2., many of our partners and customers have asked us for guidance about which of the many options BW provides they should use for their implementation. Some of those options are there simply because they got introduced some time ago but would be actually obsolete within a new product. So, SAP has decided to reduce the complexity of choices and created a product, namely BW/4HANA, that offers only those building blocks that customers and partners should use now and in the future. The product has become simple and that will translate into simplified DW architectures.
I hope this blog helps you to understand why SAP has moved from BW to BW/4HANA. In simple terms, it's similar to choosing between renovating and rearchtecting your existing house or building and moving to a new house with the latter fitting your furniture and all the other stuff that you cherish. We all hope that you will feel comfortable in the new home.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
28 | |
27 | |
14 | |
13 | |
12 | |
11 | |
10 | |
7 | |
7 | |
6 |