- Hasso Plattner provides a summary of the benefits of S/4HANA’s new application architecture. However, Hasso’s proposals are all false.
- We cover these false benefits in this article.
Hasso Plattner has written a great deal of promotional literature about S/4HANA. One of his proposals is that S/4HANA is a new application architecture. In this article, we will cover this topic and analyze the legitimacy of the claim.
Hasso on S/4 HANA as a New Application Architecture
“The in-memory database SAP HANA allows for a radically different application architecture and a new philosophy with regards to the data model simplicity. While most of the business functionality of the business suite will be carried over to SAP S/4 HANA, new workflows, larger transaction volumes, real time analytics on transactional data, unmatched flexibility when changing reporting structures and even real time simulation of business scenarios are possible. And all this comes with a completely new UI and a new framework for modifications and extensions. SAP S/4 HANA will continue to be developed at a different speed in order to match the new requirements of the digital age.”
Hasso does not explain why “in-memory database” allows for a radically different “application architecture.” According to Wikipedia, the definition of application design is the following:
“Applications architecture is the science and art of ensuring the suite of applications being used by an organization to create the composite architecture is scalable, reliable, available and manageable.”
I don’t think Hasso’s claim here holds true. He may be able to propose that that HANA creates more scalability — although that could be easily debated. I see no reason why HANA makes S/4HANA or ERP functionality more reliable, available or manageable. SAP ECC is already quite reliable; it is available. It ‘s hard to maintain, but that is only in a small way related to its database. Much more of the difficulty in maintaining ECC has to do with its user interface, learning curve, issues with maintaining master data and other non-database related issues.
See our The S/4HANA Implementation Study. For the real story and details on actual S/4HANA implementations.
There is not much to take away from this section of the paper by Hasso Plattner. The statements are not substantiated.
Search Our Other S/4HANA Content
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
I cover how to interpret risk for IT projects in the following book.
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model