The Problem with John Appleby’s Explanation of S/4HANA

Executive Summary

• John Appleby typically provides inaccurate information on SAP.
• In this article, we review his inaccuracies in his S/4HANA article.

Video Introduction: The Problem with John Appleby’s Explanation of S/4HANA

Text Introduction (Skip if You Watched the Video)

 

Bluefin Solutions is a consulting company that provides incredibly inaccurate information about SAP. Bluefin Solutions has been one of the greatest promoters of S/4HANA and HANA and publishes information that competing vendors commonly call out. Bluefin Solutions releases information without ever admitting their financial bias, which is only to sell SAP consulting services. You will learn about the false information that Bluefin Solutions publishes as we analyze each of their claims in one of their more widely read articles.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

• This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
• Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

The Quotations

When SAP built R/3, it was built to run on any database (AnyDB), and used the capabilities of the lowest common denominator. This led to tremendous complexity in the software design which has persisted through over two decades.

This is untrue and comes from a position of strong bias. This was an essential component of SAP’s success, and in fact, most ERP vendors do the same thing. It has not to lead to tremendous complexity in the software design of any other ERP system. And notice how no other ERP vendor is moving to a single database in their ERP systems.

In doing so, SAP built applications based on the lowest common denominator of all database features, and was unable to take advantage of database-specific functionality like stored procedures.

Well, this problem does not seem to bother other ERP vendors. And let us discuss stored procedures like this, a standard line of reasoning used by SAP. A stored procedure is where logic that was in the application layer is moved to the database layer. The concept is that the code stored in the database is faster than that stored in the application logic. The problem is that SAP presents this as a universal virtue when, in fact, many computer science professors debate whether stored procedures are a good idea. I predict that eventually, SAP will need to open up S/4HANA to run on any database. They will move the code from the database and put it back into the application layer and probably won’t say much about it.

With S/4HANA, SAP is rewriting the software layer to take advantage of the tremendous performance of SAP HANA, which leads to a dramatic simplification of the data model and software. Data size is reduced 10:1 and even the number of database tables is reduced 10:1 in many areas.

HANA does not have a performance advantage over competitive databases. This is covered in the article What is the Actual Performance of SAP HANA. In addition to SAP not having benchmarks that back any of this up, information coming from S/4HANA projects is not much faster than ECC.

SAP S/4HANA is no less real-time, but it is simpler too.

This is also incorrect. First, S/4HANA is a much more complicated implementation than ECC because S/4HANA is still so immature and all the changes. The entire proposal of S/4HANA being more straightforward is deconstructed in the article Does S/4HANA Have a Simpler Data Model?

It’s so fast that it does not need a separate operational analytics system or data warehouse.

HANA is an analytics platform. But it is not a transactional platform, which is why SAP stopped releasing transaction processing benchmarks. John Appleby should be more specific. HANA is faster for analytics and only faster for analytics.

It is the platform for all of SAP’s innovation. Because it is so fast, it is no longer necessary to hold all of the duplicate data in a transactional system including calculations like percentages, totals, indexes and aggregates. This leads to a much smaller data footprint and dramatically faster processing.

Well, that is unfortunate. It means that SAP is doing nothing outside of S/4HANA. Apparently, all the non-S/4HANA applications that SAP sells are not receiving development and are becoming dated in the market.

The rise of cloud platform-based competitors like Salesforce and Workday means that applications exist that are deeply integrated into the database layer, and perform better for it.

Salesforce and Workday don’t spend any time marketing around their database. This is a huge claim. It might be true; John Appleby presents no evidence for it. Why are Salesforce and Workday more “deeply integrated” into its database than any other vendor?

There is less of a focus on openness of what platform software runs on, and more of a focus on openness of integration and APIs. The DBA no longer has the power-base in the Enterprise.

This is a false and dishonest statement. The two items John Appleby is discussing here are unrelated to one another. Secondly, SAP has no history of having the openness of integration. SAP makes it the most difficult to integrate applications in enterprise software, and this is done purposefully to redirect customers to purchase SAP’s, not ERP applications. So what has happened is that while SAP was open to databases and close to integration, now SAP is both closed on integration and closed in database options.

SAP built its own database with SAP HANA, that has the capability to be incredibly differentiating, but performs much like any other database when running the “lowest common denominator” code.

HANA is not differentiated. HANA is far poorer performing than even its benchmarks due to the immature nature of HANA and the fact that SAP is a Johnny Come Lately in the database space. But even from the benchmarks area, HANA is beaten by Oracle 12C and beaten quite easily as the article Which is Faster, SAP HANA Versus Oracle 12c.

For these three reasons, SAP had to re-platform to what it calls “the fastest mover” – its SAP HANA platform. Unfortunately, SAP HANA is sufficiently innovative that the rewritten S/4HANA software performs terribly on the traditional RDBMS systems.

HANA is, in fact, an RDBMS, although not a “traditional RDBMS.” HANA is a column oriented rather than a row oriented design. However, Oracle 12c performs better than HANA in benchmarks.

It isn’t easy to see what is innovative about HANA as Sybase IQ was a column-oriented database that preceded HANA for over a decade. SAP and Bluefin seem to be actively deceiving customers and readers as to the history of column-oriented databases and the use of memory and SSD to push them into making a purchase.

S/4HANA may run terribly on a traditional RDBMS. But for example, Oracle 12c has identical and superior abilities to HANA (for some time now, but not when Appleby wrote this article). However, the overall benefit of putting any ERP system on a column-oriented design will be small. So SAP’s whole premise is weak and should not be accepted.

The primary extension framework for all S/4HANA systems is the HANA Cloud Platform (HCP) Extensions. This allows customers, SIs and ISVs to extend S/4HANA in a compatible way.

It has been over two years since this article, and HCP is still barely used. I covered this in the article Is HANA Cloud Platform Designed for Cloud Washing? What John Appleby predicted here has still not come true.

Currently, there is support for core finance (GL). This will be extended to Logistics in 2015, and other modules will follow. It’s worth noting that the existing Business Suite code lines are backwards compatible with HANA, so all the existing supported modules will run.

Over two years after John Appleby wrote this, S/4HANA still has very few implementations.

There are some generic IT-based business case points for SAP S/4HANA: reduction in data footprint, TCO, development costs and faster transaction processing and reporting.

All of these items have proven to be incorrect.

• TCO Reduced?: The overestimation in reducing the footprint is covered in this article, How to Best Understand the Price of HANA. TCO has to go up with S/4HANA because immature applications with few people with implementation experience increase costs. This is covered in the article How to Understand the TCO of S/4HANA Best.
• Development Costs Going Down?: There is no evidence that development costs go down—just the opposite. Development costs go up because S/4HANA breaks every single customization and every single integration that was previously used because of the changed data model. This is covered in the article How to Best Understand Customizations and SAP S/4HANA. S/4HANA will perform better in reporting but will perform worse in the transaction process.

It’s clear that cloud computing is SAP’s stated direction. SAP S/4HANA will have three modes – a Public Cloud, Private Cloud, and on-Premise. It will be “cloud first” approach and the cloud versions will provide innovation earlier than the on-premise version.

Wong again. This is a prediction that went the opposite way. The few S/4HANA implementations that have occurred have been almost entirely on premises. In the future, almost all S/4HANA implementations that are “cloud” will be a private cloud, or hosted because S/4HANA in almost all cases will be customized. This means that SAP will never offer a very compelling argument for S/4HANA in the cloud because the costs will not be much lower than on premises S/4HANA.

The Concur, Fieldglass, Ariba and SuccessFactors clouds are already truly cloud multi-tenant.

This is true. It also has nothing to do with S/4HANA. All of the applications listed above were truly cloud multi-tenant before SAP acquired them.

The Public Cloud version will use database multi-tenancy, which is quasi-multitenant from a cloud perspective. ABAP Code-lines, configuration tables etc. will not be shared yet between customers on one SAP HANA container database. This is expected to come in time, as SAP HANA supports true cloud multi-tenancy.

Wrong, for reasons explained in the previous section.

SAP S/4HANA projects will be faster and cheaper, and there will be less time spent doing configuration and development. Business Consulting skills will be in-demand, but ERP configuration skills will slowly wane away.

Nope, S/4HANA projects have been and will continue to be slower and more expensive. That is what happens when you implement software with a lot of changes, and that is immature. This is entirely obvious to anyone who has worked in software implementation.

Do note that from a consulting perspective, the transition to S/4HANA will take 10 years or more – Enterprise ERP systems are extremely sticky.

Yes, this is true. S/4HANA implementations will also take a very long time. They are an excellent source of consulting revenue unless the project gets canceled, which has been happening with high frequency with S/4HANA implementations up to this point.

For various reasons, SAP S/4HANA is a new product SKU, which means that it does have to be purchased by customers. Existing customers will not get SAP S/4HANA licenses included in the maintenance of their SAP Business Suite, but existing SAP Business Suite for SAP HANA customers are covered.

There is one reason for this, not various reasons for this. SAP intends to double charge customers for what should be a free upgrade. This is covered in the article Why S/4HANA Should be Free. It is telling that John Appleby is so under SAP’s control that he cannot admit an obvious truth as to why S/4HANA has to be repurchased by companies that have been paying 23% or more on support for many years.

Conclusion

This is an article that shows signs of an author having any independence from SAP. It contains a vast number of false statements and many predictions that never came true.

Bluefin Solutions has been one of the least reliable sources of information on S/4HANA and HANA since these products were introduced. This article may as well have been published by SAP marketing and represents what SAP would like to be true but is not what is, in fact, true.

Bluefin Solutions is an SAP consulting partner, and as such, they are not allowed to publish any information on SAP without SAP reviewing it and approving it. In this sense, they are mindless repeaters of information from SAP marketing. But they present their information with high confidence as if they have some unique insight or have somehow independence from SAP. Their primary reason for publishing any information on any topic is to convince customers to hire them to implement SAP. And that is, of course, a significant problem of bias.

See our The S/4HANA Implementation Study. for real story and details on actual S/4HANA implementations.