Hello Lars and thank you for such a considerate response. The fact that this article is reaching subject matter experts such as yourself is a big honor for me. You’ve helped me resolve countless doubts on the SAP Community message boards over the years and I really respect your expertise. One of my motives for writing this article was to help start a discussion around where the industry is headed and I thank you for giving me an alternate point of view.

You rightly noticed that the analysis in the article is at a CTO/CIO level. I chose to maintain a narrow focus on broadly applicable categories like price and performance instead of going into granular details like time-dependent hierarchies, which may not be required by most users. However, given the reach and engagement that I’ve had with this article, I’m considering writing a part two which will compare these two warehouses from a developer perspective and can dive into the weeds on technical features.

Since you brought up specific examples, I’d like to address them directly.

Currency conversion is a great example to start with as it’s both widely applicable across most companies and best highlights the pros and cons associated with opting for an out-of-the-box solution. SAP has inbuilt functionality for storing different rate types and defining conversion templates based on reporting fields; however, instead of something which could conceivably be stored in a single table with a simple structure (conversion_type, from/to_date, from/to_currency, conversion_factor), SAP stores this in multiple tables (separating the rates, decimal shift factors, internal/external factors, and cross rates). Assuming this all works seamlessly, you will never have to unravel what these concepts entail. But it doesn’t always work seamlessly, and simple debugging to identify why a conversion failed becomes a development task. Even referencing the main table (TCURR) is not straightforward because the dates are stored in a cryptic format which requires programming to decipher and make legible. Meanwhile, this can be done in one simple JOIN in any other database.

The same can be said about SAP time-dependent hierarchies (except perhaps the part about them being widely applicable). In my entire BI career, I have never come across a user who understood time-dependency, let alone been able to make a practical case for using it in their reporting. Even if required, it means changing the JOIN condition from “=” to “BETWEEN”. This is not complicated by any means and I would rather build it myself using flattened hierarchies instead of using SAP’s relational approach.

Finally, and only because you brought it up, let’s tackle “arbitrary cells to be computed differently than the others”. As a BI Architect, I would never sign off on a design which utilized this functionality. This is a lazy way of pushing business logic up to the reporting layer instead of doing it in the DW where it belongs. Having 2+2=4 in one row and 5 in another is a recipe for confusion for anyone who isn’t intimately familiar with the business rules of the specific report where this logic is implemented.

I completely understand that some organizations will be sold on the idea of automated currency conversion or time-dependent hierarchies or any singular feature that SAP BW offers. As I said in my article, this is especially true for DWs which rely on SAP ERP systems as the source of their data. However, most customers will not require these things and they should not have to incur the added cost and complexity.

The trend in the modern era has been that of specialization; doing what you do best. There is still a place for generalized solutions, but the “Swiss Army knife” approach must never make the claim of also being the “sharpest tool in the shed”. If BI is to continue to evolve, the focus must be on openness and integration. Customers should be free to choose not just the WH, but the ETL and reporting tools which best fit their needs since they are not likely to come bundled all in one package. Organizations depend on the marketplace to deliver these specialized products and to make sure they integrate seamlessly through open APIs.

I have had this conversation many times with SAP sales reps and technical experts. In the face of a customer expressing concern or discontent (or even pointing out an obvious bug), SAP digs in its heels and insists that its way is the best way. Maybe, but not always, and certainly not for my current company. Snowflake’s stellar growth (and they are not the only cloud-based offering) should be a wake-up call to the established players in the industry. A call to take a step back from long-held ideals and listen — really listen — to what the customer is asking for.

Again, thank you for opening up this discussion and creating a conversation around this topic. I hope there are practical takeaways for everyone involved as well as our audience.