Questions about SAP’s Database Roadmap
I watched with interest the replay of the SAP Database and Mobile Press Conference from April 10, particularly the areas focusing on SAP’s aspirations as a database vendor, and the roadmap that was discussed to get there. While I believe in what SAP are aiming for, and particularly the role of HANA, I was left a little confused by the positioning of SAP’s other database products, and I had a number of questions that I couldn’t clear up as I was too late for the follow up Q&A on Twitter. So here are my key questions in relation to SAP’s Database Roadmap.
1. What about MaxDB?
I’m not sure why, but in a discussion about SAP’s database strategy there was not one single mention of MaxDB. MaxDB may not be shiny or new, but it has quietly chugging away as a supported SAP database for almost 20 years now, and has been owned by SAP for the last 15 years or so. In that time it has racked up more than 15,000 installations at 6,500 customers. OK not massive numbers, but it’s a lot more SAP installations than HANA and ASE have at the moment, and is certainly enough for a mention I would have thought. One could almost be forgiven for reaching the conclusion that MaxDB is going to be superceded by ASE, but this runs contrary to earlier comments from Vihsal Sikka.
In my view, SAP has a problem when positioning MaxDB and ASE next to each other. ASE is no doubt a very good product, but it’s just getting started in the SAP environment, whereas MaxDB already has 15,000 runs on the board. And while it’s dangerous to talk about pricing, currently MaxDB has a distinct price advantage over it’s rivals, including ASE. That advantage (as long as it lasts) is probably enough to counter the lower TCO argument that SAP is using to position ASE against other database products.
2. Why should SAP customers migrate to ASE?
SAP is now arguing the case that ASE is “the best platform for Business Suite”. However there does not yet seem to be much evidence to back up this claim. Putting it bluntly, ifASE is such a good platform, then why hasn’t SAP ported the Business Suite to it during the last 20 years? It seems natural that following the acquisition of Sybase that SAP would add support for ASE, and it certainly represents a compelling option for new SAP customers who already run ASE in other parts of their business.
Of course if you’re running SAP on Oracle, then you’ve probably already thought about a DB Migration, as this business case can almost write itself in many cases. Sure if you’re running ASE already then you might elect to expand the use of this platform. However, you’re not, then do you really want another database product into your IT landscape?
All the arguments I’ve seen so far highlight the benefits of ASE compared to Oracle, which is great, but if SAP really wants to attract customers to the ASE platform, then they need to demonstrate ASE is a better choice than SQL Server, DB2 or MaxDB. Of course, this particular challenge has its own pitfalls, particularly in terms of the relationships with Microsoft and IBM.
3. Why should SAP customers migrate to any different disk-based DB?
Putting aside the relative merits (or otherwise) of ASE for a moment, with the prospect of parts of Business Suite being supported on HANA as soon as the end of this year, does it even make sense for customers to migrate to a different disk-based DB at all. Why not just sit tight and wait for Business Suite on HANA to become GA and then plan a single migration from your existing disk-based DB to HANA? OK it’s probably going to take a little while for Business Suite on HANA to stabilise, but even Gartner acknowledge that 3-5 years is realistic. That’s still enough time to get positive ROI from a move off Oracle, but if you’re on a different DB platform already and contemplating HANA in the future it’s hard to see the benefits of moving too early.
4. Why does HANA need Sybase IQ?
I think this is one of the areas where SAP has done a good job of positioning. HANA’s in-memory approach is always going to be faster, but also more expensive than a disk-based approach. So if you’ve truly got BIG data, and you don’t need millisecond response times then you’d consider a product like IQ. But for the subset of data where you do need the performance you use HANA. This all makes sense, but it goes against some of the very principles that started this whole database revolution. Having all your data in IQ (for completeness), and then a subset in HANA (for performance) means we are using basically using HANA as a cache, which in turns means more replication and duplication, the very things that HANA is ultimately trying to avoid.
If the long term vision is to “simplify and reduce layers” then strategically a single consolidated solution is required (perhaps we could call it “HANA IQ”) where data is first placed into memory but then is subsequently moved to “cheaper” storage (i.e. disk) once it is no longer the subject of updates or real-time queries. This data would still be managed under a single set of models, so if necessary a single query could return data both from memory and from disk. This would allow for significant scalability, and allow HANA to tackle really big data without requiring a whole separate database environment.
So what do you think – are these questions valid, or should I just drink my Kool-Aid and get back to work?