For those of you unfamiliar with my previous blogs, you will be unaware that you are currently digesting the words of a zealot — a man on a mission to strip away the varnish and delve into SAP’s inner workings. Oh, and then to shoehorn it all into a blog without saying anything libellous, wildly inaccurate, or just plain offensive.
Today’s blog is a bit of a long one, so without further ado, let me introduce this week’s topic. It’s a topic that resides in a region of computing not renowned for its glamour, an area that is often labelled as dull and confusing. Wow, this blog sounds enticing, doesn’t it? So if anyone is still reading this, let’s journey into the dark world of database technologies and discuss SAP HANA.
Now the morning I started to research this blog (no jokes, please) had started badly. I’d missed my train, the later train was crowded, and I had just been attacked by an overfriendly golden retriever. Yes, I thought that the day couldn’t get much worse. But I was wrong.
Now, being attacked by a loving dog is one thing, but spending 2 hours on a train reading about ‘in-memory’ and ‘column-oriented’ databases while sitting next to a man who seemingly had a conscientious objection to washing is quite another. To illustrate the point about SAP HANA, here is a typical definition served up by my trusty friend Google.
The heart of SAP HANA Enterprise 1.0 is the SAP In-Memory Database 1.0, a massively parallel processing data store that melds row-based, column-based, and object-based storage techniques.
In the words of a teenage girl…OMG! Now don’t think this is an aberration. Oh no, hit after hit dished up nothing but varying flavours of this nonsense. Now, at this point I should say that I am not knocking SAP HANA. Indeed, fast forward several days and I am firmly of the opinion SAP HANA is a great product, and one that can have real and tangible benefits to an organisation. However, I remain steadfast in my opinion that the marketing around this product is often needlessly complicated, convoluted, and misdirected.
To see what I mean, let’s try and define what SAP HANA actually is. As a concept, it’s simple. It is a set of database technologies that allows the applications that sit on top of it to run very fast — nothing more, nothing less. It can either be the database platform that your SAP business suite ‘sits on’ or it can be an additional ‘bolt on’ to your current architecture. Practically speaking, it means that any business process problems caused by speed (COPA and opening up a large project in Project Systems are two examples that spring to mind) can be resolved by switching the underlying database technology to SAP HANA. It also means that vast amounts of data can be read and — through the use of magic powers, laser-powered quantum mechanics, and possibly alien technology —manipulated and analysed at lightning speed.
So, when it’s put simply, it sounds really good. But in my humble opinion, almost all of the marketing surrounding SAP HANA focuses on the wrong thing. While the technology may well be revolutionary and interesting to a select few, it is completely alienating to many for whom the resultant functionality would really appeal to.
To understand what I am getting at, let’s imagine that SAP HANA is a new type of car engine. If you base your marketing on the fact that it has achieved a maximum thermal efficiency of 45% and a geometric compression ratio of 15:1, then the chances are that you will sell about three, all to men with beards. If, however, you skip the technical stuff and advertise that it can do 100 miles per gallon, then you will see the interest levels shoot up.
Indeed I would go further and suggest that the best way to market your engine is to hardly mention the engine at all, and rather make the engine merely a component of a car that looks great, goes fast, and has fantastic fuel economy. By doing this, the engine becomes almost irrelevant to the purchaser. It is obviously not irrelevant to the car, but to the purchaser its ability to get from A to B quickly, cheaply, and stylishly is the motivation — not the fact that a new type of revolutionary engine makes this all possible.
The slightly laboured point I’m attempting to make is that while technological advances take place, the real benefit of them will never be fully realised if the context is not adequately understood or explained. SAP HANA is a perfect example of this; the focus should be not on the technology but rather the functionality that is facilitated by this technology. Instead of trying to explain terms such as ‘column-oriented’ and ‘in-memory’ to people who neither understand nor care about the technology, more should be done to highlight what is now possible using SAP HANA.
Now for those of you familiar with HANA marketing, you might be forgiven for thinking “Hang on a minute, what about all the references to terms such as ‘accelerated analytics’ and ‘running your business in real time’? Surely they are practical applications of the HANA technology?” Indeed, you would be correct. But this kind of benefit, while undoubtedly true, is in my opinion too vague and too intangible to make it compelling for many businesses. To illustrate the point, and as I am fairly unimaginative, I’ll use the car analogy again. Imagine that you already own a car. It’s reliable, and while it may not be perfect, you have paid it off and it does pretty much everything asked of it. Now imagine that a salesman comes to your house and tries to sell you a much faster car, something that can do 0-60 in 3.1 seconds. While there will undoubtedly be some for whom the promise of speed alone would be enough motivation to dump the family salon, for far more, I suspect it would not be.
Equally, if I was the CEO of a ‘normal’ business operating in the current global economic climate, I would not throw out my existing database technology based solely on the business case that SAP HANA would ‘dramatically accelerate analytics, business processes, sentiment data processing, and predictive capabilities.’ Indeed, I would reply, what the hell does ‘sentiment data processing’ mean? And I would add something along the lines of ‘do you think I am made of money?!’
However, if I was told that installing SAP HANA would mean that I could reduce my month-end close procedure from (for example) 5 days to 4 hours, I would get my calculator out and work out whether this would justify the cost of the technology. It if did, I would make the purchase based on the promise of the functionality — regardless of whether the underlying technology was an ‘in-memory, column-oriented, relational database management system’ or not.
The key takeaway from this blog is therefore as follows: SAP HANA is a fast database ‘thing,’ and the technology behind it, and even the correct way to categorise it, is in the vast majority of cases irrelevant. It is an enabler of functionality and, to truly understand the benefits of SAP HANA, you need to explore this functionality and think about whether you currently have problems or functionality gaps in your business that are caused by the amount of data being processed. If you have, and if they are significant, then SAP HANA might be for you.
Matt Riches is the Principle SAP Architect for Red Solution. An experienced SAP professional with more than 12 years’ experience Matt has fulfilled numerous roles for a myriad of customers over the years, Matt now provides strategic knowledge to both Red Solution, Red Commerce and its customers on the complete range of SAP offerings.
His team #CloudSitter recently became the first ever team to ‘do the double’ and win both the InnoJam and DemoJam SAP developer competitions at SAP TechEd 2013 in Amsterdam. Their application was specifically developed to run on SAP HANA.
You can follow Matt on Twitter @MatthewRiches1