I'm in Sydney Australia attending Mastering SAP. Why? It is always good to get another perspective on the world. Short of New Zealand and Antarctica you can't get much farther away from Palo Alto and Walldorf.
During the initial SAP InsideTrack session the crowd decided (among other things) that it wanted to discuss database strategies. Local government was heavily represented and they take a risk averse view of their IT landscape.
Almost from the get go there was much discussion about formulating strategies going forward that embrace a possible move to SAP HANA. RIght now, many SAP shops use HP/Oracle as their preferred platform upon which to deploy SAP but there are other combinations including Microsoft/SQL Server and IBM/DB2.
It is an open secret that SAP would like nothing more than to see those Oracle shops transition to HANA but that is not what motivates those I met. The common thread in the various conversations can best be summed up in two words: fear, TCO.
Customers believe that over time, Oracle will continue to increase costs at a time when they think their interests are better served by reducing or maintaining the cost line. However, a switch to another database is far from trivial. Much as they might wish to switch, there are genuine technical concerns over the ability of alternatives to match the capabilities they already get or worse still, they worry that their current systems become unstable.
Regardless of the final decision, all were talking about having a homogenous environment. That is counter intuitive to me because it inevitably leads to risks attached to single vendor lock on. Recognising that, those I spoke with said they would prefer to deal with a vendor which is perceived to play fair. That excludes Oracle which is a master at account control and price increases. Does that mean SAP becomes the de facto alternative?
No. In one reported survey, the overwhelming choice was SQL Server. That will surprise some people but in discussions last week at Microsoft Convergence, I sensed that customers are comfortable making direct comparisons between Oracle DB and MS SQL. Surprising to me, IBM DB2 comes way down the list despite the fact IBM is one of SAP's largest SI partners.
When it came around to a discussion on HANA, there was much debate about whether customers will put their OLTP systems on this as yet to be available database. The question in my mind is whether there is any real advantage in moving to HANA which today, can provide huge speed improvements in analytic style scenarios. The answer is a heavily qualified 'maybe.'
HANA's columnar store thrives on complex aggregation queries but is slow when trying to replicate what amount to row store calculations where an Oracle performs very well. SAP says it has the Business Suite running on HANA but it is only in dev/test environments. The company will spend the next year or so figuring out which of the 1,000 plus SAP database tables can benefit from HANA and which cannot. Eventually - and I am thinking in the 2017 timeframe, customers can expect to see an optimised version of the BusinessSuite running on HANA. At that stage, we will know whether HANA really is the database of the future for SAP shops or whether customers will be stuck in mixed environments. The good news is that customers have plenty of time in which to work out a long term OS/DB/hardware strategy.
In the meantime, no one should expect Oracle to stand idly by. It recently announced what amounts to a replacement for its ageing analytics engine and it is clear that Oracle wants its customers on a combination of hardware and software. That will be enforced through making key capabilities needed by enterprise only available on a combination of Oracle kit. Even so, customers should be aware that this amounts to Oracle shoehorning the database onto ageing Sun boxes.
Those customers who have informed Oracle they are looking at alternatives are the focus of much sweet talking. The worry as one person said: "I don't know how they do it but whenever we talk about reduced cost they somehow come up with something that gets us to pay more."
The Australian experience is not an outlier. More broadly, I see this type of discussion occurring around the world. It is a topic that could have significant long term impact for everyone.
- There is no rush to do anything. Keep calm and do not be wooed into making an early choice that you later regret.
- Use this opportunity as a way of redefining long term database/hardware strategy. The inevitable death of Itanium should serve as a spur to rethink.
- Long term DB strategies need to embrace your perception of analytics requirements and the impact of non transactional data on workloads. It will not be possible to size with precision so allow for plenty of headroom.
- Ensure you understand different vendor cost models and how those change as your requirements increase.
- Start considering what types of scenario will be best suited for high speed databases like HANA. Watch for emerging business solutions you may need to consider adding into your applications landscape and how they impact your database strategy.
- Make sure that you understand where SAP will make significant enhancements over the coming year but expect to see the core remain stable apart from bug fix and tweaks. Size those loads and negotiate hard for commodity pricing.
- Regardless of vendor, be aware of the long term risks of single vendor lock in. They are real.
UPDATE: I received this response from one insider among the companies represented: "Regarding DB2, a great deal of activity Is occurring where Oracle is displaced in large strategic outsourcing engagements and IBM GBS/GTS is brought in to do an entire transformation of an enterprise using SAP particularly if mainframes are involved. A survey is very unlikely to represent these environments due to the very closed nature of these deals ($100m-$1B)."