Why ISV’s need to consider SAP HANA!

Karl-Heinz Hoffmann

Posted by Karl-Heinz Hoffmann on

VP SAP Indirect Business

More by this author

Data sprawl threatens business ROI, agility and real-time enterprise’s embarking on the digital transformation journey.

 

In today’s modern era of technology, large volumes of data are being collected at unprecedented scales, adding onto the existing data in the enterprise. How do you transact, manage and analyze data in real-time without adding significant complexity and cost to your customers or hosted/cloud estates?

In this blog series, we will look at why ISV’s (Independent Software Vendor’s) should consider adopting SAP HANA. We will start by looking at the basic problem our customers are trying to solve and explain how SAP HANA is revolutionizing the application world. Then we will start by delving into some of the specifics, for example adopting SAP HANA, delivering business cases, optimizing for SAP HANA, increasing developer productivity and implementing specialist engines to name a few.

It is important to mention that this blog series is not about SAP Applications running on SAP HANA, but rather to demonstrate how non-SAP applications can benefit from using SAP HANA. We may relate back to SAP’s own use of SAP HANA, but this will be purely for illustrative reasons, as there are concepts, ideas, and best practices that can be leveraged by any ISV’s.

Lets get started…..

Holy grail of software, combining transaction and analytics into a single platform!

The holy grail of software development has always been the ability to provide real-time reporting from transactional data without negatively impacting the transactional systems or having to “replicate” the data into other systems, creating complexity.

In software design, we have deployed a number of architecture workarounds to provide reporting and analytical solutions on the side of these transactional systems. We at SAP have done the same with SAP Business Warehouse. This architecture had real-time limitations by relying on end-of-day batch runs to load the analytical store. The net result is that the decision making is reliant on batch processing times. For example, in store out-of-stock positions could only be calculated at the end-of-day. Now with the capabilities of SAP HANA we are able to deliver real-time out-of-stock positions, by being able to run complex analytical queries directly on the transactional data. You can now be assured your favorite product is on the shelf when you go to the store.

This continuous loop between transactions and analytics is depicted below and is considered to be the ideal software design paradigm

Diagram depicting the transaction-analytics continuum

Figure 1 Diagram depicting the transaction-analytics continuum

We will start building on this diagram, first by looking at how we would traditionally implement the solution, and then discussing how the scenario could be implemented using the SAP HANA Environment.

How have we traditionally implemented this paradigm?

Businesses constantly challenge development to make real-time reporting at scale a reality. To implement this as effectively as possible, “architecture workarounds” are deployed as depicted in diagram Figure 1 Traditional Architectures

  1. Separating analytical and transactional stores for performance optimization
  2. Creating separate stores, for example, to service predictive & spatial processing.
  3. Integrating these various stores through data movement technologies, which inherently creates data latency and consistency issues.
  4. In some cases, there may be a requirement to bring back aggregations into the transactional system to facilitate follow-on processing, via costly and potentially conflicting integration.

Diagram depicting the traditional of implementing the transaction-analytics continuum

Figure 2 Diagram depicting the traditional of implementing the transaction-analytics continuum

 

These architecture “workarounds” were necessary, as there practically was no other way to implement the business requirements! Consider some of the following physical limitations, that caused the necessary workarounds:

  • The cost of large-scale multi-TB In-Memory Compute Platforms and physical cost of large amounts of memory.
  • Platforms that are designed as single OLTP / OLAP specialty compute platforms
  • Maturity and availability of the In-Memory data compute platforms

There are 3 significant business disadvantages of the architecture, detailed in Figure 1:

  1. Latency and inconsistent data stores prevent real-time reporting
  2. The cost to maintain and integrate these multiple platforms is significant, coupled with the fact that they do not solve the real-time analytical question makes the architecture questionable today
  3. The cost to develop on these architectures, number roles, and skills required to not only acquire and but also maintain, will hinder innovation.

ISV’s like SAP have constantly grappled with this issue, leaving customers to absorb the cost of maintaining, integrating and developing these additional analytical data stores which is not insignificant. With the cloud, customers are pushing the cost of these platforms back onto the ISV’s. As a result, ISV’s need to look at a way to simplify their software application stacks to provide the real-time insights their customers need, but at a price that is cost-effective and competitive.

The question ISV’s need to ask is, “Is there a platform that enables the real-time continuous flow of information between transactions and analytics at a reasonable ROI without the data sprawl issue and integration spaghetti issue?”

 

SAP HANA – The platform to build the future on

To deliver on SAP’s promise to our customers to deliver the real-time business, SAP had to fundamentally redesign the core platform of SAP’s applications. It just was not feasible within market platform technologies. SAP challenged the status quo, delivering into the market a new revolutionary in-memory platform – SAP HANA. This platform has uniquely enabled SAP to deliver its next generation of real-time applications. It is important to re-enforce, SAP HANA is not built to only support SAP Applications, but for non-SAP centric applications as well.

Diagram depicting the implementation of the transaction analytics-continuum in SAP HANA

Figure 3 Diagram depicting the implementation of the transaction analytics-continuum in SAP HANA

 

SAP HANA was designed from the ground up to solve the problem of continuous integration between transactional and analytical solutions, delivering real-time insights at scale. Based on industry leading in-memory columnar technology, SAP HANA can manage not only transactions and analytics at scale in the same store – but can deploy specialist engines on the same data without duplication, for example spatial, predictive, AI, etc.

Let’s take a step back and uncover what this means from a business perspective. Today, SAP delivers capabilities like the board room of the future, where CEO’s and executives are no longer required to wait for 2 weeks for reports to be delivered to answer a specific question, the question can be answered when it is posed. Operations managers can make real-time changes in manufacturing processes, based on real-time insight. This would not have been possible by separating analytics from transactions.

By utilizing SAP HANA’s capabilities, ISV’s are also able to substantially decrease the environment’s complexity that their applications require, forming the foundation for the digital core to re-Imagineering of their installed base, whether on premise or cloud. By driving complexity and duplication out of the ISV estate, ISV’s can not only reduce their TCO (total cost of ownership) but also deliver on the real-time aspects their customers are expecting and improve developer productivity through a single environment. This multi-model (transactions + analytics + specialty engines) development approach of SAP HANA increases developer productivity that would result in substantive time-to-market gains.

Using SAP HANA, ISV’s will be able to combine transactions and analytics in a single store and expand the value obtained from the data through the use of specialty engines, like AI, Machine Learning, Predictive, Spatial etc.

In Summary

SAP HANA dramatically simplifies an ISV’s application environment by transforming and simplifying to ensure ISV’s applications meet the requirements of the real-time enterprise at scale and TCO, both on-premise and in the cloud.

This modernization of the platform will leap frog ISV’s application into digital transformation, which they can deliver to their customers and integrate with their digital transformation strategy

As an example, in this brief, SAP and ESRI describe how they teamed up to accelerate and simplify spatial environments by providing new insights into spatial and transactional data.

Contact Us

We understand that every ISV’s application is unique and has their own set of opportunities. As such, SAP offers multiple ways of partnering on the digital transformation journey and offers services to help ISV’s understand what would be required to adopt SAP HANA and the potential joint business impact.

The time is now to understand how an SAP HANA partnership can drive your transformation to the digital core! To engage with SAP, please either email us at sap_isv_engagement@sap.com or fill out the form below.

Upcoming Blog Topics

Stay tuned for our upcoming topics, including:

  • How to get your application on the SAP HANA Platform (includes cloud deployment options)
  • Specific business cases and technical properties of SAP HANA
  • ISV use case’s and examples
  • RASP properties of HANA to support ISVs
  • Incorporating specialty engines into your application (Real Time Dashboards, Spatial Analytics, Predictive Analytics, Artificial Intelligence/Machine Learning)

Suggested Readings

VN:F [1.9.22_1171]
Average User Rating
Rating: 5.0/5 (4 votes cast)
Why ISV's need to consider SAP HANA!, 5.0 out of 5 based on 4 ratings

429 Views