Is S4 Hana a real innovation or simply a SAP’s marketing blurb?

Before the era of computers, we had documents. We had Sales Orders, Purchase Orders or Accounting Document. Likewise, all the business processes are represented by a document. With the invent of computers and Database, these are represented by a table called core table to represent the line item table. These tables had about 200 to 400 fields depend on the industry of record.

Whenever there is a change in these documents, the whole record is copied and created a new record. When there are series of changes in a document, there is a necessary to keep track of all the changes in a changelog table. Like who changed it or what changed in it for Audit purposes.

In those days, Data Modelers have got an idea to split the table into smaller ones like header, line and schedule line evolving to the concept of normalization. Of course the other tables have fewer fields. But the concept remains the same. If anything changes it copies the whole record and maintains the changes in the Change Log tables of their own. For this reason one business process has so many smaller (20 to 30) tables forming a cluster by having a join between them. Currently this is the process to support traditional databases.

On top of this there are database constrains like many to one issues or Join relations, DB administrators have to keep it intact to maintain and sustain it. Also, have locking, latching, deadlock, Paging issues and thus creating lot of performance issues. It has two things, massive table space usage and reading these tables is too slow. When the DB is slow, for all these tables with the method that has to be read by a query, we start adding indexes further creating new tables. On each of these tables, it is not necessarily 1, there could be many indexes. These are copy of the tables with a narrow method of access. For the fact that system is getting slower, we are trying to copy the tables taking yet more space and forcing the system to narrowly usable.  But, it turns out to be indexes are not fast enough. So we have started creating aggregates. These are whole new tables by managing the SAP code build and tested to get like daily/weekly/monthly total invoices, thus getting more complex in managing these SAP codes and customer exits. This is all to get better reporting and speeding up the system. These are the standard Indexes and aggregates. But our great DBA’s, with their experiences, they analyze the queries specific to the customers and they build additional custom indexes and aggregates. During the upgrades, service pack updates, and new releases, apart from the work what we have to do, system also has to do lot of work by rolling up the data to all these standard and custom build tables, indexes and aggregates to reflect the changes in the documents and be reportable.

Just a case, if we have to build a dashboard reporting, as a developer, we need to know what business processes change will impact what tables or trigger any change and how it is influencing down the flow. That’s why BW has become significant. SAP has integrated the flow and made a module specific or process specific extractors enabling the single source in BW. BW Extractors took care of this spider web of tables and simplified the logic which makes sense to the consumers.

This is only way we have to run the system brilliant and all the traditional databases are being the best to build and sustain the model. Now, let us talk about what different is in S4 Hana and why?

Alternatively we have to think of getting away from this complexity.

With Suite of Hana, SAP did several things, They were able to drop the need for some of the Indexes and aggregates but the fundamental aspects of all the documents and relations, tables required to maintain them was unchanged in order to have compatibility for customers.

But S4, Complete rethinking by leveraging the capabilities of Hana by simplifying it for customers and making it much more agile for development staff. Document concept is still the same. We still have the same record but it is not a row table. It is now represented as individual columnar stores for each of the fields. The big difference is, if the value changes, we just insert one field. We don’t replicate the whole record with the changed values. It is almost impossible to run this for such a 400 field tables in any relational data bases having so many table rows and indexes. We still have the same no of field changes but each field will have its own columnar storage, which means every field can act as an individual index.

We are now to 1 table from the spider web of 20 to 30 tables for each business processes. All the complexities I talked above on the table locking and latching is no more an issue.  I have to take care of only one locking issue that might happen during the multiple inserts on the same columnar table. We do not need to create whole new aggregates for a new requirement. We can run on the same table and Hana creates on the fly. No need to create any indexes to speed up the process. We don’t need any different status tables or header tables. So all these nested tables has been collapsed into one single line item document. All the SAP code in maintaining the cluster of tables is now that my understanding is all gone. Now think about the testing and regression required, all of that is radically simplified which means higher quality process. With all those variations, ups and downs, mistakes that can go wrong is traditional databases is tremendous with comparison to when we code against this S4 simpler process.

As you read, S4 is a huge innovation leveraging that was not possible before HANA due to both its ability to have a simple system and ability to aggregate on the fly and enabling new code pointing to this simpler structure.

Last, but not the least, Traditional Data bases with this complex structure, they are not compatible with Multi-Tenant Cloud. It has to go through a hosted service or an On Premise environment. SAP took care of this issue while upgrading from clustered table structure to new code line of S4 HANA, they designed in such a way that they can run on multi-tenant cloud or hosted or On Premise. It enables customers to go back and forth between these business models. This is not possible with any of the other ERP mates.

S4 Hana is enabling lot of business benefits leveraging the advantages from Suite of Hana.

S4 Hana Rocks!