Perhaps customer ambitions (and costs) will change over the long term, but for now, a dual-database strategy is a given. And for all those non-critical applications, replacing Oracle or IBM DB2 with ASE as the application database would be less expensive than moving onto Hana.
Companies need databases for reasons other than running SAP's software, so it's an open question whether they'll take to ASE. It's a venerable, highly scalable database that's widely used in the banking industry, but it has a tiny market share compared to Oracle, IBM DB2 and Microsoft SQL Server. What's more, it was certified to run Business Suite only last year, so SAP customers aren't exactly familiar with the product. As a SQL-based relational database, it has much in common with the other products, but database administrators and IT shops are known to be resistant to change. On the other hand, free is a powerful inducement to at least consider a change.
The ASE deal is significant, but because it's an OLTP database, the advantage to customers only goes so far. On the analytic (OLAP) side, SAP chairman Hasso Plattner acknowledged last week that customers will still need data warehouses (running on still other databases) to bring disparate data sources together and to transform and cleanse data.
It was not startling to hear that SAP customers will still need their data warehouses; it was always pretty obvious that deep historical data and non-SAP data weren't likely to be addressed by Hana. With SAP's low-latency data-integration technologies there is an opportunity to bring third-party data into real-time analytics scenarios on Hana, SAP execs told InformationWeek last week. But data warehousing is another spot where Hana won't address all needs (and there's no talk of bundling SAP's Sybase IQ analytic database to fill that void).
[ Want more on SAP's big move? Read SAP Moves Core Applications To Hana In-Memory Platform. ]
One more caveat regarding analytics: "dramatic simplification" might not involve disruption of the SAP landscape, but if you're going to eliminate aggregates, cubes and other performance aids that are no longer necessary with powerful in-memory technology, be prepared to rework the database model as well as dependent analytics and business intelligence reports. Dependencies on database artifacts don't magically disappear when you swap in Hana.
Add it all up and Oracle actually has a stronger "without disruption" story with Exalytics than does SAP with Hana -- assuming you're committed to using Oracle's bundle of hardware, database and analytical software, meaning Oracle Exadata and Oracle Business Intelligence Enterprise Edition. Without doing any modifications, you can run Oracle apps and middleware and even SAP apps on Exadata and gain incremental, cache-based analytic acceleration with Exalytics. With SAP you'll need two different databases -- at least for now -- because not all Business Suite apps run on Hana.
SAP's in-memory platform, meanwhile, gives you a better shot at delivering game-changing performance improvements and developing never-before-possible applications. You also get a shot at consolidating and simplifying infrastructure and eliminating data redundancies (likes aggregates and materialized views) because Hana can run both transactions and analytics.
Customers choosing Hana will need ASE or another database alongside it over the short term, and they may continue to use it over the long term where in-memory performance isn't needed. They'll also continue to need conventional data warehouses. Nonetheless, Business Suite on Hana beta customers like John Deere anticipate transformational performance on key, mission-critical business processes, and that has been the promise all along. SAP customers will undoubtedly want to see more customer examples before they're convinced that they, too, will be able to realize big advantages by reinventing key applications on Hana.