S/4HANA is our next-generation ERP. To understand what makes S/4HANA different, you need to know why we put it on the HANA in-memory platform in the first place. And you need to know why in-memory options from HANA competitors cannot get the same result. HANA simplifies ERP, giving it a smaller, easier-to-manage footprint yet making it more productive at the same time. Let’s take a look at how this happens.
Traditional databases needed to normalize data in order to manage it. This meant splitting up a single wide table into many narrower ones. While this was necessary to increase transaction speed (inserts and updates), it killed reporting and analytics (select) because there were so many tables involved. So older systems implemented a blizzard of indices and aggregate tables to provide the necessary lookups and reports. Then when it came time to make an update, the system would lock these tables making users wait. It was a constant battle to keep the indices and aggregates updated every single day. Also, when a traditional database updated a row, the entire row had to be written. So no matter what operation you wanted, there was delay and redundancy everywhere.
HANA solves these problems in two ways. First, by using a columnar store instead of a traditional row store, and second, by running in memory instead of waiting on spinning discs.
A columnar store organizes records into one very wide table. Changes are made only in the column where they are needed, rather than to the entire row as with traditional row-store databases. It is a fact that these columnar stores can be scanned much faster than row stores. And when we run in-memory, we can run an entire table scan faster than a traditional system can go read separate indices and aggregate tables.
If you would like to know more about the technical differences between row and column store, I recommend this very educational 15-minute whiteboard discussion.
So what then is the final result of re-building on an in-memory, columnar data store? We no longer need those indices and aggregates. Or to split up records into dozens of smaller tables. Take a look at SAP inventory management on a traditional database:
There were 26 tables just for inventory management (highlighted in a red box on the left), not including change logs or any custom tables customers built on their own. On HANA, though, we can cut that table count down to one, MATDOC, shown on the right side of the picture.
Imagine what this can do for IT management. I hope you’ll watch further videos to see what this does to business productivity and how IT can bring entirely new capability to their organizations.
You may be wondering by now: if in-memory is so good, why not just run SAP ERP with an in-memory option of a legacy RDBMS? At first it seems tempting, and some vendors even use the same terminology, like reducing aggregates and indices. Some of the legacy RDBMS vendors even claim to get all the benefits of in-memory with the push of a button. But all you need to do is count the underlying tables. Was any complexity really reduced? It is more likely that they are just taking the same design, wrapping it in a new data model, and hoping to squeeze some performance out of it in memory. These other databases cannot do for ERP what we are doing.
For another way of looking at this, see my article where we compare data model simplification to photography.
Only HANA and S/4HANA use the combination of columnar and in-memory to re-architect ERP, dramatically reducing complexity and boosting productivity of ERP. I invite you to stay tuned for specific examples in Finance and Inventory Management that no other ERP system can match.