Almost all the talk at last week's SAP Business Suite Powered By Hana announcement was about "reinventing enterprise systems." It's SAP's vision that companies will drop conventional databases from the likes of Oracle, IBM or Microsoft and switch to its Hana in-memory database in order to dramatically improve the performance of critical systems like ERP. But SAP has also quietly acknowledged, both at the event and in a follow-up interview, that its execs know that not everything will move to Hana right away.

The most obvious sign of this admission is a dual-database deal whereby SAP is including the Sybase ASE transactional database -- meaning it's a free add-on -- when customers license SAP Business Suite Powered by Hana. SAP executives explained the offer in a follow-up interview with InformationWeek last week.

"Customers could choose to deploy ASE or Hana in whatever mix of configurations they want," explained Prakash Darji, SAP's global VP for data warehouse solutions & SAP Hana platform. SAP customers could use Hana to accelerate certain Business Suite processes while leaving other processes on ASE.

There are two reasons why this move to bundle Sybase ASE along with Hana makes sense.

[ Want more on SAP's big move? Read SAP Moves Core Applications To Hana In-Memory Platform. ]

First, not all Business Suite applications are capable of running on Hana as yet. Major ones including ERP, CRM and supply chain management are, but some apps, like supplier relationship management, are not. Thus, customers will obviously continue to need a conventional relational database. Including ASE -- which SAP touts as an alternative to Oracle, IBM DB2 or Microsoft SQL Server for transactional (OLTP) workloads -- is a lure (or a consolation, depending on your perspective) to companies that would otherwise balk at having to license two databases -- meaning Hana, plus whatever they're currently using.

Second, even if SAP reaches its goal of moving all of its software onto Hana fairly quickly, customers may still be selective about which applications they choose to accelerate or reinvent by moving them onto Hana.

Hana's appeal is extreme in-memory performance whereby transactional and analytic applications can run far faster than on conventional databases. In some cases the performance is such that entirely new applications are envisioned, ones that were never attempted because they would simply take too long. At last week's announcement, for example, BusinessSuite on Hana beta customer John Deere said it's testing financial close and manufacturing resource planning applications that will execute within minutes on Hana, where they used to take many hours or days running on conventional databases.

But in other cases customers either don't see value in dramatically speeding up an application, or they just aren't ready to move it over to Hana. In those cases, they can license only selected apps to run on Hana.

"We would love to see every customer consolidate everything on Hana and not go to a hybrid deployment model, but the reason we've included ASE is that some customers are saying, 'Do I really need an in-memory database for, say, a portal?'" Darji said.

[Editor's note: In a follow-up interview, SAP execs said there are compelling reasons to support real-time personalized dashboards on portals using Hana, and that a payroll app would be a better example of a not-so-critical application where in-memory performance is concerned.]

Why not run everything on Hana? For one thing, there is a price for performance. Hana runs on different, memory-intensive hardware than conventional databases, and the database itself is also licensed based on the volumes of data managed. Hardware prices have come down, but memory is still more expensive than spinning disks. Despite all SAP's promises of being able to deliver "innovation without disruption," its ASE giveaway policy seems like a realistic recognition that it may only be in mission-critical spots -- at least initially -- where companies will want to innovate with Hana. 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.