Will SAP HANA TDI make the appliance model obsolete?

NOTE: This text was originally published by me at saphana.com in November 2013.

I believe the future will make the SAP HANA appliance model obsolete, and HANA will be a normal application on the datacenter. Things like downloading the SAP HANA software from SAPNET and installing in a VM for productive use will be a normal activity.

SAP HANA is still a “young child” maturing and evolving, and as it evolves, so does the architecture options and operation practices.

As adoption increases, so does the knowledge on that technology, and broader become the deployment options as well as related best practices.

In my analysis, starting to bring HANA to the market through a very controlled appliance model was a wise choice by SAP, but being HANA targeted to become a mainstream component in datacenters WW, it will need to evolve, and SAP will have to manage that, pushed by the increasing customer requests for more openness and choice.

The SAP HANA Tailored Datacenter Integration is just a first step on the journey to increased openness and deployment options. SAP HANA’s customers, partners and component suppliers must understand the technology evolution journey, not only to be able to best position HANA in their technology portfolio, but also to anticipate next steps that will enable them to lead and innovate in this new reality.

SAP HANA Tailored Datacenter Integration solutions will become increasingly relevant in the evolution of older SAP HANA implementations as well as new core business related implementation scenarios.

          Setting the scene

Let me explain my understanding of the “SAP HANA journey”, why TDI is a sign of the future, and why this understanding is crucial for customers to make the best deployment decisions, in regards to their specific implementation scenarios.

Over the recent months, I’ve been faced with the following question:

• Will SAP HANA imply a return to the early mainframe era with huge central servers and internal storage?

Why does this question come? Let me split it in its two parts:

1.     Because today SAP recommends to scale-up first before considering scaling out;

2.     Because in the early days of SAP HANA many customers opted for single server installations with only internal disks.

I’ve received these questions both from business partners and customers.

          Background on Scale-up vs Scale-out implications on SAP HANA

If you’ve been absent from the HANA discussions, or are just starting to look at the SAP HANA topic, you’ll feel a bit lost among lots of these discussion points.

Let me briefly fill you in regarding the concept and challenges of scale-up vs scale-out on a HANA system.

SAP HANA is an “in-memory” database, which means that all the data in the database is permanently in the RAM of the servers where the database instances are running.

So, if you consider that some customers today may be running SAP systems with over 40 TB databases, even if you consider a compression factor of 4, you end up with many customers requiring over 10 TB of RAM (there are customer cases where compression ratios of 1:8 have been observed, but I’ll stick to the 1:4 for easier calculation in my example).

If you add the fact that HANA only uses about 50% of the RAM for data storage, being the rest used for temporary structures and calculations, you may need systems as large as 20 TB of RAM (if you want to learn more on sizing, start by checking out the “SAP Note 1637145 - SAP BW on HANA: Sizing SAP In-Memory Database”, and make sure of reading the attached PDFs).

Today’s existing systems are limited to 1 TB for analytics use cases (BW on HANA is one example), and 4 TB for transactional use cases (Business Suite on HANA is one example). With the new Intel Ivy-bridge chipsets these limits are expected to be increased by a factor of 3.

HANA has a “shared-nothing” cluster architecture, which means that you can split tables (or partitions of columnar tables) across multiple nodes of a cluster, and that cluster node will have exclusive access to the data it is holding. Note that this is completely different from the Oracle RAC cluster architecture (shared-all cluster architecture), where all nodes access the same data at the same time. The HANA architecture is more similar to the GreenPlum database architecture than the Oracle RAC one.

A SAP HANA database has simultaneously columnar and row storage, meaning that on the same database you can have coexisting tables that store data on rows, and tables that store data on columns. Note that up until HANA, it was typical that companies would operate transactional applications on one database with row tables, and then would use an ETL to load data to a Datawarehouse system where the analytics would run supported on databases with columnar tables. HANA enables to merge these two worlds on the same database, eliminating the need for an ETL. The end result is having optimal options within the same database for simultaneous transactional and analytics needs, enabling real-time analytics on top of operational data, for example for large scale real-time operational monitoring.

If you consider the GreenPlum architecture, SAP HANA goes beyond GreenPlum and has more potential use cases, as it has been designed to support not only analytic workloads, but also transactional workloads. This implies that on HANA you have transactional consistency across nodes, bringing a new level of integration challenges, one thing you do not have on GreenPlum or other purely analytics databases today (like SAP's own Sybase IQ).

The fact is that SAP HANA, being still on version 1.0, is still maturing, and with each new Service Pack, new solutions come to overcome the new found limitations.

Note some of the limitations.

• Today, SAP HANA is on version 1.0 SP7, and on this version, there is only possible to store row tables on the single master node of the cluster (consider that for analytic use cases, SAP currently enforces a ratio of 128 GB / CPU socket as maximum of RAM, and of this RAM, only about 50 % is used for permanent data storage);
• All connections to the HANA system as well as query distribution is controlled by the “single master nameserver” making the server with this service a potential bottleneck for massive scale-out deployments (in massive I’m talking about many dozens of servers);
• Doing single commits that imply writing to tables (or partitions) in different HANA nodes, or doing joins of data across different HANA nodes, imply a “cost” in terms of performance that is very significant, since instead of working with data at nanosecond speeds inside a server NUMA node, you need to keep moving back and forth across the network at millisecond grade speed, which represents a very significant performance hit, implying better tools, work and mechanisms to minimize this impact (although a lot has been delivered in this area, there is still a need for further improvement);
• Configuring and operating a SAP HANA system in a scale-out cluster is more complex than operating a single node configuration;
• Due to the specifics of the current implementation of the SAP HANA persistency and “savepoints”, there are still some challenges to be overcome in regards to the recoverability features of the system in case of a disaster;
• Some challenges are already documented, and some already have a solution, but here are some examples:
• 1743225 - HANA: Potential failure of connections with scale out nodes (network configuration needs special attention in scale out configurations)
• 1905462 - HANA scale-out landscape : topology mismatch leads to recovery failure (backup and recovery still not yet fully predictable on scale-out)
• 1945833 - Processing dimension is intermittently slow in HANA scale out landscape (the behavior of certain features is not yet stable in scale-out configurations)
• 1825774 - SAP Business Suite Powered by SAP HANA - Multi-Node Support (no scale-out support yet)
• 1855041 - Sizing Recommendation for Master Node in BW-on-HANA (recommends minimum of 1 TB HANA nodes for larger scale BW on HANA implementations, in order to ensure stable operations…)

These examples confirm that HANA on Scale-out is walking through its growth path in order to become the platform of choice for massive mission critical transactional applications.

All these aspects, on one side push customers to select mostly scale-up solutions which limit their growth potential to the current maximum capacity of existing servers, or when going to scale-out deployments makes them consider HANA as a solution only for analytical (non-mission critical) workloads.

The first has as a consequence both increased cost as the biggest x86 boxes fully loaded with memory and CPU will cost more than twice as 2 half sized boxes, as well as making HANA to be kept out as an option for the core largest core business systems.

The second, prevents the customers from experiencing the greatest benefits of HANA regarding real time operational monitoring, planning and forecasting, as in this scenario, HANA will not be the preferred persistency layer for their core business operational systems.

The point is: you cannot look at these aspects in a static way like they are written in stone, and limit your decisions based on what others have chosen in the past. A customer thinking today on a HANA implementation may face a decision and implementation cycle that reasonably could be around 18 months. At the speed that HANA is evolving, this is an eternity!

Remember that technology evolves, and what is true today, may have changed tomorrow. As guessing the future is no way of conducting business, you need a more pragmatic and supported analysis, so that the understanding of the technology direction provides you a reasonable perspective of how the future might look like.

SAP's previews on what is planned for future releases regarding Datacenter Integration features, is definitely something to consider before making decisions on infrastructure architecture.

          Background on file vs block

Regarding the disks discussion, I’ve already written a blog post on that, which you can read here: http://sapinfrastructureintegration.blogspot.com.es/2014/01/choosing-right-sap-hana-architecture.html 

Nevertheless, let me add some further background on the “file vs block” discussion, in the “evolutionary journey” perspective, of course.

Most of you knew a software that SAP have named: TREX – Search and Classification Engine. This software has existed for many years, and represents a big part of the foundation on which SAP HANA has been built on.

Why is this important?

If you understand where HANA comes from, maybe you can also understand why some things started in a certain way, or where it may evolve to. TREX leveraged a “shared filesystem” to store all the data when in a multiple host / scale-out configuration. This was because, TREX stored data on small files in a directory structure, which formed the index that existed in memory. So, as TREX was already based on a “shared filesystem”, I would say SAP had a lot other priorities for development to make HANA the “new platform” other than just changing the persistency access model.

Any smart company leverages existing knowledge in order not to be reinventing the wheel. So if SAP had a software component already in their portfolio that allowed to build the HANA vision on top of it, why not leverage it before starting to develop completely new code?

As a curiosity, do you know that the main process on HANA is called "IndexServer", which was the name of the executable that on TREX managed the in memory indexes of the search engine?

The following picture helps you understand better how SAP HANA was born, and the software that SAP leveraged upon to build the SAP HANA code.

This picture was extracted from the IBM RedBook on SAP HANA.

Also, if you want to understand better TREX, you can check the “TREX 7.1 Installation Guide – Multiple Hosts” at http://service.sap.com/installnw74 > “3 – Installation – Standalone Engines” > “Installation: SAP NetWeaver Search and Classification TREX” > “Installing TREX 7.1 Multiple Hosts” (NOTE: Access to this document requires an S-User!).

As a conclusion, I believe SAP HANA started with “file over NAS”, because that was the architecture of TREX (which made all the sense for TREX as it stored the index in the form of small files in a file-system), and so, they leveraged that scenario and invested their development efforts on building new possibilities at the development and data modeling layer, as the “persistency access model” was nor a first stage priority.

As HANA evolves and is challenged with other types of use cases, workloads and datacenter scenarios, SAP is being asked for more options from their customers as a pre-condition to consider HANA as the primary platform for their datacenter. This makes SAP to look closer into these aspects, tune them, and find better solutions.

The point: HANA having been born based on NFS access to persistency doesn’t necessarily mean that this is the best option for all implementation scenarios!

          Background on internal disks vs shared disks

As for the fact that some server manufacturers started with servers with internal disks only, clustered through a parallel file system, if you understand some of the use cases of Parallel file systems in the HPTC world (High Performance Technical Computing), as HANA started in 2010 being positioned as an “analytics workload” purpose built database, aspects like data protection, disaster recovery, cross node consistency, ease of change and maintenance, simple scalability, etc, weren’t on the top of the concerns.

Note that on many pure analytics application scenarios, you do not expect the system to ensure transaction consistency across nodes, as you assume that the consistency has been ensured by the previous load process (for example through an ETL) that has dumped the data in these systems. So, now it’s only about massive parallel reads, and even backups are not that critical, since the data still exists someplace else other than the analytics database, and in case of corruption could always be reloaded.

Considering HANA just as an analytics database, the internal storage story with a parallel filesystem made sense.

But SAP’s vision for HANA goes beyond “just” an analytics use case, and SAP states that HANA will be the next generation platform, on top of which all their applications will run.

Also SAP ambitions to become a top tier player in the “Database Management Systems” space, and this will put HANA to the test of transactional systems aggressive RTO and RPO requirements over large distances.

This is making those server manufacturers that started with this scenario of only internal disks to realize that there is a need for other options. Even the ones with a bigger stake in the “internal disk with parallel file system” story have started to develop offerings for HANA with external storage. So it’s clear that other use cases of HANA, will imply different architecture designs where this “internal disks design” may not always sustain the needed Service Level Agreements for operational mission critical applications.

Some of these server vendors’ documentation on TDI will make it clear to you, they’ve realized that an internal disks cluster cannot be the only solutions for all HANA scenarios.

As a conclusion, in the scenario of a larger HANA adoption, the customer has the power to decide what is best for him, and many will want to keep their existing datacenter standards for architecture and operations. Being block access to shared storage the “today’s enterprise standard for mission critical transactional workloads”, I believe it will be the chosen one, which will make it observe increased adoption in the new HANA world.

Note that Block access to HANA Persistency has been available since SAP HANA 1.0 SP5.

  

          An evolutionary analysis of SAP HANA

Having understood a bit on the history behind HANA, let’s start to consolidate an analysis of the SAP HANA evolutionary journey.

HANA has started as an analytics only platform, leveraging the TREX as a foundation.

Has evolved, being today the preferred platform for SAP BW, and seeing all SAP applications being ported to work on top of it.

SAP Business Suite, comprising components like the ERP, CRM or SCM, supports in many customers their core business processes, requiring levels of performance, availability, recoverability, security and stability that push existing technologies to their limits.

As SAP puts its best efforts on bringing those workloads to work on top of HANA, this platform will need to evolve in order to present the choice, robustness and datacenter integration and operation capabilities that customers are used to for their existing mission critical applications.

                    The promise over the early years

SAP started to position HANA as the next big thing. It would be the fastest platform you’ve even seen. It promised more than 100 times faster performance for analytics on your existing applications.

Those of you that like me have long years of consulting managing large enterprise customers, know that most of the performance and availability problems observed in existing SAP systems, had as most common causes:

• Poor architecture designs:
• not enough spindles for the expected workloads;
• poor network connections between database and application servers;
• low memory on database servers;
• bad separation / aggregation of components;
• etc.
• Poor integration of components:
• wrong / sub-optimal configurations on Network ports;
• wrong / sub-optimal configurations of fibre channel HBAs;
• excessive resource sharing without accounting needed reservations for critical applications;
• etc.

So, if I was SAP, knowing all the above, would “I” ever leave in the hands of “infrastructure integrators” the success of my most important strategic initiative?

Would “I” risk having customers saying my software isn’t as fast as “I” promised, having “me” troubleshooting thousands of different configuration combinations that “my” hardware partners and all their implementation partners could have come up with????? NOOO WAYYYY !!!!!

"SAP HANA WILL BE DELIVERED AS AN APPLIANCE ONLY!!! This way I’ll ensure control of the variables, and restrict the configuration options in terms of support requests."

Also, this option would enable “me” to focus “my” resources more on the development of new functionalities of the platform, boosting early adoption and higher returns, instead of having to put in place right from the start a very extensive and costly support organization.

But all of this is just me thinking...

                    The adoption and knowledge growth acceleration

A fact we all need to realize when comparing the deployment options of traditional Netweaver applications and HANA, is that Netweaver has been around for many years, and the ABAP Application server as we know it is now over 20 years old, and has more than 80.000 installations worldwide.

This means that there is enough experience to write a “sizing best practices guide”, or “architecture recommendations for maximum availability and performance”, etc.

The point is, many people claim that “SAP should provide more sizing guidelines and architecture recommendations”, as well as “provide mode options when deploying SAP HANA”. Have you considered for a moment that - maybe - there isn’t yet enough knowledge on this new platform to provide the same level of options as you have on Netweaver?

HANA was announced in 2010. The ABAP Application server has been around since the launch of the R/2 in 1981! Can you compare the level of knowledge gathered over 30 years with what SAP has done with HANA in less than 4 years???

The conclusion is that HANA is !!OUTSTANDING!!, considering its young age, and what SAP has delivered so far.

Connecting back to the reason why it made sense (at least in my head) to start offering HANA on an “appliance model only”, with more customers using HANA, with customers having used HANA over several yearsnow, and going through the growth learnings, more al life knowledge gets gathered on the system operational behavior and challenges.

One thing is the planned operational practices on the design table, and another is the reality on the customer datacenter.

Today, we are only starting to have relevant "operations knowledge" on HANA, as (comparing with the ABAP application server reality) the number of customers with more than 2 full years of experience managing and operating a productive HANA system is still small. So, time is still short to understand all the lifecycle challenges of evolving a HANA system and coping with its growth demands.

So, in my perspective it makes sense that SAP starts to open up a little bit the appliance model. But still with caution.

On my view, some conditions are starting to be fulfilled for more “openness” to come:

1.     There is already real-world experience of operating and evolving productive HANA system;

2.     There are already a “large enough” SAP HANA customer base to support the expansion of the support matrix;

3.     There is already a level of requests in the market, where not having enough wide of deployment options, may hinder the growth expectations, pushing SAP to open up a bit more;

4.     The level of functionality is not the biggest barrier to adoption, so development resources can be focused on other aspects.

On my view, the fulfilment of these (or simillar) conditions has enabled SAP to say: “Ok, as the appliance model doesn’t fit the datacenter setup of most and largest customers, we’ll let you choose your preferred server and storage vendor independently”.

This is the SAP HANA Tailored Datacenter Integration, and is the first sign that HANA is maturing and growing in terms of market adoption.

                    More use cases, more options are requested

As time goes by, the reasonable expectation, considering the massive effort and investment SAP has put on the SAP HANA initiative and how much has been delivered in such a short time, is that HANA adoption will continue to grow.

With this adoption growth, the knowledge will also grow, but most of all, the HANA software reputation will settle, and customers will increasingly differentiate the HANA Software problems from the infrastructure integration problems.

It’s also expected that as the use cases expand, and as HANA spreads more in customer type and customer specific utilizations, the request for increased flexibility becomes larger.

In such a scenario, probably the investment in developing and supporting more deployment options:

• On one side, will justify against the risk of not gaining some customers;
• And on the other, will pay-off against the new expected revenues, as with more experience, the cost of development tends to become lower.

So, my expectation is that in a time-frame up to 3 years, SAP HANA to become another normal application in the datacenter. One that you can download from SAPNET and install, and one that can be deployed on the shared (or even virtualized) infrastructures you use for other equivalent applications.

          Conclusion

I do believe that promoting a higher level of adoption and contributing to the acceleration of HANA maturity, will be the best way to open up the deployment options of SAP HANA and make the appliance model become obsolete at some point in time.

This means that, in terms of server memory, the Tailored Datacenter Integration allows today for customers to choose their preferred server vendor and storage vendor in separate, and integrate the two components. 

This is "approach" is no rocket science, as that has been the approach in which most customers have deployed SAP Netweaver based applications until today, procuring each of the infrastructure components to their preferred vendors, and then installing the SAP applications on top of it.

So, this is "THE" option for all those customers where the appliance model doesn't fit either their datacenter setup or operational practices.

I have no question this is the way forward, and it will make storage vendors play a more important role in SAP HANA implementations, as storage vendors have been the experts on data availability, protection and replication for many years.

Make no mistake though, as HANA represents a significantly different paradigm and a different workload pattern (mostly disk-writes with HANA, instead of mostly disk-reads with legacy Netweaver based applications), and the solutions that have made storage vendors successful over the past SAP Netweaver customer based reality, do not ensure success on this new SAP HANA era.

So, what I try to do every time I meet customers, is to demystify HANA and make it simple to understand. 

Having a clear understanding of the HANA history and future evolution, will enable you to make the best choices for your specific implementation scenarios, not only based on the few things supported today, but also on what the future is likely to look like.

Know more about EMC and SAP HANA Tailored Datacenter Integration at: https://community.emc.com/docs/DOC-31784

SAP HANA Datacenter Readiness - Customer Discussions

Over the recent months I've been involved in a series of customer meetings, where the key topic has been SAP HANA.

Big take away: today ROI and business case identification are the biggest barriers to an accelerated SAP HANA adoption. Not the technology or datacenter readiness.

Let me share the top 5 questions I’ve faced, and what I've found out from these customer meetings.

Over these meetings, I've talked with:

• Directors of applications;
• Corporate IT Architecture leads and their infrastructure teams;
• Directors of IT Planning and their implementation teams;
• Directors of IT Operations and their SAP Administration leads.

QUESTION 1: What really is HANA?

Surprisingly still lots of customer stakeholders are very confused on what HANA really is at a technical level. They get lots of marketing attention that position HANA as the next big thing, and the solution to all problems, but many of them still don’t understand the how. So, on all the times I’ve found myself spending at least 10 to 15 minutes on the whiteboard describing the SAP HANA Architecture, why it is transformational, and how it benefits from current Intel NUMA Architectures. Also, surprisingly, most of these customers told me that until then no one else (SAP or other Solution Providers) had explain them in such a clear way what HANA is, and why it is such a transformational technology. The note to be taken here is that a lot still needs to be done at multiple levels of the customer organizations to drive up the knowledge on the technology, as in the end it will need to be integrated in the datacenter architecture and operated, and no way it will go into production unless those teams really understand what they are dealing with.

QUESTION 2: Is HANA ready for the Datacenter and Mission Critical use cases?

This topic goes straight to Infrastructure and operations teams pain points. All of us that at some point in time managed IT operations know that the easiest is to get a new technology to work. The hard is later to keep it operating in a stable, predictable way, and with the needed access and data security. Also many of us have spent nights awake, fixing poorly designed architectures or implementations, as the requirements for availability and performance were not correctly evaluated when this new application was implemented. On this topic, this year’s SAP TechEd sessions like the ITM214 show how much effort SAP has put into this aspect, and as I guide customers through these options, they come to two conclusions: yes HANA is ready for the datacenter, but as it is changing so fast wouldn’t it be better to wait another 6 to 12 months to get it more tested and more robust? This last comment trails back to an expression I’ve heard a lot from operations directors in charge of core business mission critical systems: “I want in my datacenter the almost newest technology”. Many customers are conservative on their technology adoptions, and the most critical the systems are for their core business, the more conservative they are. The reasoning is: let other less critical usages get adopted and more tested, before we put our core workloads there. This is a reasonable point, but as all new technologies in the end, it will all depend on the business case and corresponding SLA requirements. Today, HANA has definitely built in the features to support mission critical workloads, and there are partner solutions for a solid integration in the datacenter operations’ SLAs.

QUESTION 3: I’m being sold HANA to the “X” use case. Is this the right tool for my problems?

We all have lived the paradigm between the sales pitch and the reality. Most IT companies make a huge effort to align their offerings with the real customer needs, but the supplier’s pressure to fulfill the sales goals sometimes makes account teams shoot every possible target. On my understanding this question related with two key aspects: many people not understanding the real positioning and business transformational potential of HANA (that was widely approached by SAP through the Use Case discovery work and clarification on the strategy behind the Real Time Data Platform), and the fact that no single big customer is likely to become a “full single provider shop”, if not for anything else, because of risk management and non-full dependency of a single provider. In these discussions with the different customer stakeholders, some conclusions come out: in some cases, maybe HANA is like killing a mosquito with a canon, and also there might be more interesting use cases for real time applications that weren’t even thought off. The end answer to this questions most of the times has been: “we’ll start with a Proof of Concept with the lowest possible investment, also to give us the opportunity to touch this technology and getter a better understanding of it”. As customers understand better the technology and get more familiarity with it, the value starts to shout out clearly.

QUESTION 4: what would be the use case for HANA in my business scenario?

In an increasing number of customers, this question has already been answered by the key business stakeholders. But still many IT stakeholders, who will have to implement and operate HANA, and fulfill its business SLAs, are loaded with questions. There are still many discussions at the level of positioning HANA just as another database in the datacenter, which reveals a lack of knowledge on aspects like the possibilities offered by the XS Engine or by the embedded Web Dispatcher, regarding processing code where the “data lives”, meaning in the RAM of the server, reaping the benefits of the NUMA architecture of current Intel Based servers, and their memory to CPU bandwidth and throughput. Here the key discussion topic has been: understand how HANA is a different architecture from any of your existing databases, and how it is much more than just a database, moving the discussion to the “what if” of imagining the future type of discussion. This topic is critical, as a key barrier to faster adoption even when business decision makers have defined a business scenario, is the resistance of the architecture, planning and operations groups in the IT organization. It has been very fulfilling for me to be able to contribute in this area.

QUESTION 5: will “my selected HANA use case” provide a positive ROI?

This is the most sounding question I’ve seen so far. Sometimes, “providers” forget that customers don’t buy new solutions just because they are cool and they like it. Although I’ve found a couple of IT organizations claiming still not to have any budget restrictions, this is not the reality in the majority of the market in Europe due to the current economic situation, and in Middle East and Africa due to more limited investment budgets even though some of these markets are experiencing significant expansion. So, for a new solution or technology to be adopted, there must be a well support “Return on Investment Analysis”. Here I have to split 2 major scenarios. 1) Implementing HANA integrated into the existing SAP Applications landscapes; 2) Implementing HANA for new applications. On the first scenario, when customers sum up the costs on the new infrastructure needed, licensing, implementation services, new skills development costs, plus potential dependencies (cost of needed Version Upgrade, OS/DB Migration, or Code Optimization projects), it has been challenging for most of them to come up with a positive ROI number. Even though, some are starting pilots as they understand that as HANA adoption increased, all these costs will come down, and they need to start and learn / integrate this new technology in their portfolio. As for the second scenario, the investment justifications has shown to be way easier, as it’s a whole new implementation, and some of the costs of change do not enter the calculations. Nevertheless, I realize that most customers are only considering the first scenario, which means that there is still a lot of work to be done to open up the discussions on new use cases and business transformation potential of HANA.

CONCLUSION: 

(1) It’s my clear understanding that HANA presents a transformational technology in the IT landscape like we haven’t seen in the last 10 years. Nevertheless, as for all new technologies, lots of “educational work” still needs to be done in order to drive higher adoption levels. In this space I do believe SAP at a corporate level has been making the right moves, with extensive information and “free training” available for those interested in knowing more, still needing further roll-out throughout the different countries. 

(2) As for the technology and datacenter features, I would say that for more than 95% of existing customer installations of SAP applications, HANA is ready. Questions remain for very large scale systems and transactional systems that require 24x7x365 continuous operations with near zero maintenance windows, although I believe will see stronger answers over the next HANA Service Packs. 

(3) It is also clear that the competition is not sleeping and is coming back with all their arguments. In this sense, having more communication from SAP (observed both the Las Vegas TechEd and in the Amsterdam one) regarding to the Real Time Data Platform (RTDP), and how SAP has different tools for different needs (HANA, Sybase IQ, Sybase ASE, HADOOP), makes the message better received. Field teams need to understand this and ensure to position HANA where it is the right tool: fast data, real time analytics and planning, etc. 

(4) It is when you talk about business transformation towards the integration of real time business decisions, that the HANA potential shines. I believe SAP has some great initiatives like the “SAP Idea Incubator” that are contributing to overcome this challenge, and great innovation has been driven into this direction. Still, the challenge I see is customers realizing SAP is not only a business applications provider, but also a platform provider, with differentiating technologies ready to cope new challenges outside the traditional scope of the Business Suite applications, being SAP HANA the next generation platform for real time planning, forecasting and operational reporting.

(5) As for the costs/ROI, more and more customers want to see quantifiable ROI before decisions are made. I see merit in initiatives like the simplification driven on the BW migration to HANA, with all the tools that make it easier and more streamlined, but still for many customers this is the key roadblock and the current environment in the global economy does not make it any easier. As architecture implementation models get more “open” (for example through the SAP HANA Tailored Datacenter Integration), and more knowledge grows in the field, this aspect will be less and less challenging. Definitely on this dimension, time will be a best friend. As time passes, customers will reach their upgrade timings, technology end-of-life and other major events that will facilitate the decision.

My experience talking with customers over the last 15 years, both at a business and IT level, has shown me that handling all levels within the customer organizations both on the business side and on the IT side, is critical for the successful and smooth adoption of new technologies. My SAP HANA discussions over the last 6 months confirm the same applies also for this new technology.

It has been very rewarding to help customers demystify HANA, make it easily understandable by the IT stakeholders, helping them build the confidence to implement it, showing them the “datacenter” readiness characteristics and options now available, and helping bridge the widely discussed gap between business and IT. 

Still, the biggest barrier is related with the identification of the “low hanging fruits” for adoption of this new technology where, the business benefits are clear when moving into a “real time business process model”, and the “total costs” fit into the business case.

Full and updated information on the datacenter readiness characteristics of SAP HANA 1.0 SP6 can be found on the presentation in attach to the following blog post: http://www.saphana.com/docs/DOC-2010 

Updated information for SAP HANA 1.0 SP7 regarding Backup&Recovery, High Availability and Disaster Tolerance, can be found here: http://www.saphana.com/docs/DOC-4351

And check out EMC's solutions for SAP at: https://community.emc.com/community/connect/everything_sap