Nearly a decade has passed since the introduction of SAP Hana. Now that the hype has died down and the product has stabilized, where does it fit into modern IT and application landscapes? Because HANA is more than one thing, that question depends heavily on the use case, the maturity of the SAP HANA features and functionality, as well as the competitive landscape.
Here's how to start thinking clearly and skeptically about how HANA should be positioned in your organization today.
The first order of business is to answer the question of what exactly HANA is. During its infancy, SAP originally pursued a single-tier strategy with HANA. The idea was to collapse the traditional stack that consisted of application and database servers into a single platform based on HANA.
HANA has since changed, and with good reason, but the enduring monument to that strategy is that SAP has thrown everything but the kitchen sink into the platform. HANA now includes dozens of components that fall into three broad categories:
While specific SAP HANA features must be evaluated separately, its traditional SQL-based data processing and storage features are the most advanced, widely used and stable. Meanwhile, customers seem to use the application platform, non-SQL database features and data integration features less often, as they lag a bit further behind in stability.
Because of the differing strengths of varying SAP HANA features, the question of positioning HANA in an organization comes down to the use cases. The following are a few use cases from SAP customers where HANA is a candidate:
When deciding whether HANA is a good fit for any given use case, it is best to consider the level of maturity of the HANA capabilities for that particular use case compared to the other options. You should also consider the cost, the commitment of SAP to the functionality and the availability of people with the skill set necessary to make the capabilities of HANA perform at their highest potential.
For uses like S/4HANA, the choice is clear. There are no other options. SAP is highly committed to the application and, therefore, to the HANA features that support it. Running S/4HANA on HANA is a fairly common skill set at this point in HANA's lifecycle.
But for other use cases, the choice isn't nearly as clear, and customers will often decide that HANA is not the best option. It is often difficult to find the skill set necessary to use HANA as a general-purpose application platform or data science platform; other platforms offer much wider skill availability and more mature functionality. Of course, calculating this tradeoff will depend on individual preferences, and there will continue to be cases where HANA makes sense for either of these use cases, especially in organizations heavily committed to SAP technology.
Meanwhile, in the general-purpose DBMS and SQL Data Warehouse use cases, HANA likely has the strongest argument outside of pure SAP application uses. Potential users should benchmark their own workloads, but HANA will often widely outperform other database platforms on the mixed transactional and analytic workloads it was designed for. It can also hold its own in many pure transactional and analytic workloads.
In terms of the skills available, maintaining HANA and writing applications that interact with HANA as a database is not much different from the activities for any other database, and SAP is clearly committed to HANA as a DBMS.
As always, companies looking to make a major investment in a database or any other platform need to perform due diligence. Now that some of the hype surrounding HANA has died down and SAP's strategy around the cloud, data management and applications has solidified, due diligence is getting a little easier. However, it's still worthwhile to approach the problem with an appropriate amount of clarity and skepticism.
17 Apr 2019