July 2, 2013


The Real Impacts of SAP HANA

There is a lot of fuss about SAP HANA at the moment, but most of the excitement is simply about it being a faster database platform. Personally, I don’t think that’s the exciting bit about HANA; the exciting bit is moving business rules from up-front allocations to run-time features of a report. The result is radically more flexibility, ultimately to the point of getting rid of structures like the chart of accounts.

Perhaps I need some more justification for this view. It’s clear that the speed of HANA on its own is not enough – we’ve been able to build faster systems by throwing money at them for years, either by buying more hardware, or writing custom code dedicated to a single purpose. What more general systems have not been able to do, regardless of money, is to be simultaneously complex enough for the real world and fast. This is where the real impact of HANA comes in.

No Flexibility…

We’ve mostly resolved the issue that systems cannot be both fast and complex by aggregating the data up front, so there’s less to crunch when it’s needed. One example is when we had big leather-bound ledger books for account postings. We could have just written down each transaction as it happened in a long list, and then tried to sort them out at the end of the year, but it would have taken forever. So we created a system of accounts, and wrote each transaction in its own pre-allocated account, and we added them up as we went (“carried forward” balances). This was good for some reporting (“How much does Bob owe us today?”), but at the expense of flexibility (“How much are we owed for transactions of under$5?”).

It’s easy to look at paper ledgers, and see inefficiency. But the aggregation problem remains today. For example, many companies allocate sales to a geographic sales region for reporting (“The southern region had a good quarter…”). But it’s then hard to change the regions – if you cut the regions up differently (because you opened a new sales office in the west), you can’t really do comparisons with previous years very easily, or you reallocate old transactions, and lose the information from the old structures.

Until HANA

HANA lets us not aggregate the data until we have to – when we report. So the examples above can be just a long list of transactions – real business events. Not allocated to accounts, or cost centres, or sales districts, or industry sectors. We still have to do this allocation to make any sense of the data, but we can do it at report time. We can then look at many different ways of slicing the data up, and use the one which delivers the most value. If small transactions and large ones seem to act differently, we can re-cut reports by transaction size, and make business decisions differently for each type.

The benefit is even more striking if we use a model to do the allocations. For example, if someone has decided that a certain range of products are all similar, they can average out the cost of servicing them. If one product fails more often, the average may cope. But if we then start selling more of that product, the old model has broken, and we may not find out until it’s too late. If we report on the granular detail, not the average, our cost forecast would start to move when the sales change, not when the failures start to mount up.

This is where the real business benefit from in-memory will come, but we’re going to have to change some processes (and attitudes) to take advantage of it. So focus on the real world, and try to ignore the layers we’ve added over the years.