Tomasz Zajda - Fotolia
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.
What HANA is 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:
- Data processing and storage. These capabilities include the original hybrid columnar in-memory database engine, database management and graph database features, as well as geospatial database, document database and machine learning features. While the architecture of HANA's database engine goes by many names, hybrid columnar in-memory is still the best description because it captures a clever architecture that is both partially columnar and partially in-memory. This allows for many of the advantages of columnar and in-memory approaches while avoiding the massive drawbacks of fully columnar and fully in-memory architectures.
- Data integration. These integration features enable HANA to interact with other data platforms, offering the possibility of a single federated data model. Smart Data Access and Smart Data Integration allow for varying degrees of federated or replicated access to external data in traditional databases, Spark controllers, the Hadoop Distributed File System and other platforms. These features also form the foundation for some of HANA's data tiering options, which admins can use to store data on less expensive platforms.
Strengths, weaknesses and use cases
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:
- Running S/4HANA or BW/4HANA. In this case, there isn't a great deal of choice, and HANA shines when running these purpose-built applications that make use of its strongest features, namely the hybrid columnar in-memory engine.
- General-purpose database management system (DBMS). While database use cases vary greatly in terms of workload, for many, HANA is in the competition for best of breed for database performance and scalability. The sweet spot for HANA is workloads that require both transactional and analytical characteristics.
- Application platform. SAP customers will often consider HANA as a general purpose application platform for business applications that may or may not integrate with S/4HANA.
- SQL Data Warehouse. HANA provides data warehousing modeling features. Its strength as a SQL database can make it a contender in this space.
- Machine learning and data science platform. HANA has built-in machine learning and text analysis features.
How to make a decision
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.