Mar 30, 2015

Eliminating the Risk Out of the HANA TDI Model


Part 1 of this blog ‘Is TDI going to make the HANA Appliance model Obsolete’. was published in August 4th, 2014. By March 2015 it has been reviewed over 2,000 times making it my most read blog so far. I have received many emails from readers stating that this blog made them rethink their Appliance model in preference to the TDI approach. This is a continuation to that blog so if you have not read the first one highly recommend you do as it lays the foundation to this blog. We have developed a leadership position in the North America market in SAP HANA-TDI build and deploy support and optimization to reduce TCO by around 40%. However if the customer wants to go with HP Compute and Net App storage and backup (TDI) then the mix could take slightly longer- but is very doable. We have faced many customers who had some very valid concerns with the TDI option with its current deliverables and support SLA’s. Here is a brief on their concerns and available solutions.

 
 

Very Important Note: The traditional Appliance model comes into play with vendors that provide HANA appliances only with their components. So if you buy an HP, IBM, Dell, NEC or SGI HANA box the Compute, Storage, Network all come from the same supplier. So if a customer states they want their compute from one of the above vendors and their storage from another then the TDI business case is clear and comes into play. This may be due to the customer wanting to use best in world-class components, or because they have some unused components sitting in their data-center or because their datacenter has standards/partners that would be better served with the TDI option.
Cisco is an outlier in the Appliance and TDI case. This gets slightly complicated when our customer asks us for a Cisco UCS Compute with an EMC Storage and requests both an appliance and a TDI Quote. Cisco sits in a very unique position of having started from the ground up with a TDI as their appliance. The Cisco designers chose from the ground up to go with best in world-class components. So their appliance comes with Cisco UCS Compute, EMC or NetApp Storage and other HANA stuff. Cisco HANA appliance is a TDI build from the get-go. So as a prospective customer when does an appliance make sense and when does a TDI come into play if you plan to go the Cisco route. My brief answer-
[1] Cisco Appliance: If you are buying everything net-new opt for the Cisco appliance, i.e. if you want a combination of Cisco + EMC or Cisco + NetApp.
[2] Cisco TDI: If you have a bunch of Cisco UCS servers, or EMC Storage or NetApp Storage sitting idle in your data center then take the TDI approach as that would be assembled and tested on site for certification. This is a net new question that has started flowing in just this week with more and more customers wanting to review the TDI option.


We currently see no evidence that any one company is the best-in-world-class vendor for all the SAP HANA components, i.e. as in a SAP Appliance. We also predict that other leading HW vendors will now rapidly reposition themselves towards providing options to build best in world-class components for your HANA TDI platform.

TDI is like a buying a readymade or a custom Pizza where you can choose your personalized toppings from a list of available options. The only difference here is that the toppings are available in your data center.

A HANA TDI platform thus allows customers to leverage and use their surplus hardware and/ or existing partners. For example an existing partnership with the world’s top two Storage vendors EMC and/or NetApp can now be professionally leveraged to combine best-of-world-class components versus that of being stuck with sub-par components inside a black-box appliance, that the customer is disallowed from touching without a single vendor service contract.   

However, while this TDI option did sit comfortably with IT owners, they had serious concerns in two critical areas.   
[A] Time-to-Value and
[B] Risk mitigation for on-Premise HANA landscape.

[A] Time to Value: In a HANA Cloud option Time-to-Value is identical or close to the Appliance model. The cloud option is a level playing field for one simple reason that in a HEC model what the customer needs is [1] system uptime SLA’s and [2] security assurances in compliance to all the industry requirements for the customer. What the HANA runs on is normally not an issue with a HANA Cloud solution provider, i.e. it makes little difference whether it runs on IBM HANA or Cisco HANA – it’s in the cloud. Also the cloud providers normally have HANA platforms available for on demand consumption or subscriptions. The cloud model works to satisfy very rapid start-up needs for a HANA platform and can be delivered in under 10 minutes on AWS to 30 minutes with other HANA cloud partners.

The major difference comes in the On-Premise HANA Appliance. Most large companies so far prefer to keep their production systems On-Premises for various reasons. Here once again the customer has two options.

Option A.1 - Existing TDI combination: In this option the Customer needs to build a TDI design that has already been validated before by SAP. Just as an example the company uses EMC as their storage vendor and use Cisco for their network. They also have Cisco UCS servers available in their data centers, and now need to consider their HANA TDI build. This customer would logically choose EMC storage, with a Cisco UCS Compute as a TDI build. As we know this mix is already certified we can provide a more rapid TDI solution to the customer.  

Option A.2- Custom TDI Combination: is when the customer wants to put together a custom TDI mix that has probably never been certified together before. For example the customer wants to go with HP Compute and Net App backup and storage along with cisco network- then the mix could take slightly longer- but is very doable.This is the only instance where the Time-to-Value clause would kick in for we will first need to build the TDI, then test it and then get it certified by SAP. Once certified we can then build the same mix as many times as the customer requires. The process can take around a month which could represent  the time to value impact. But if planned and done ahead of time this bridge is just a matter of proactive planning and a sign of professional execution. Who are the prime customers for TDI - Data Centers with existing partners and components in their inventory.

B. Risk Messaging: One of the biggest risks as perceived by customers, communicated  by most of the pure appliance vendors thus far has been that – with the TDI model you are on your own. This translates into something like this “If you buy a HANA appliance with us (appliance) then the support of that HANA appliance is standard and you’re fully covered by a SAP certified appliance and our global support framework. i.e. you have a single throat to choke. However, should you choose a TDI build then you are on your own. You will need a separate support contract with SAP, another with the storage partner, another with your Compute partner and yet another with your network partner. In most of such cases when you have a problem fingers will point in all directions and the customer will be the loser’. That truly is a very big issue and extremely important and a very convincing reason to choose the HANA Appliance model despite its carrying a ‘Black-Box’ mentality and rather high support costs for any ‘black-box’ support.

The Big Risk BVA*[1] Question:  What if a HANA HW partner provided the exact same ‘HANA Support Contract’ whether you buy a HANA Appliance or a TDI, i.e. a single service contract, a single hand to shake, a single call to make whether you choose the HANA Appliance or the TDI decision.

The BIG TDI Risk Solution:  The  2014 Gartner magic quadrant for integrated systems reported Cisco in the leader quadrant for Integrated Systems.   Cisco has  just finalized a single unified  Support offering for SAP HANA customers- whether they buy an appliance or a SAP HANA TDI platform. With this proactive support option the final barrier towards choosing a  TDI model is now mitigated. 

Note: in this chart both VCE and Cisco-NetApp are Cisco Computes. This combination provides the best-of-best world class Servers from a global leader.

Some additional notations:

1.      The datacenter is transforming towards enabling the converged infrastructure for a ‘Single-pane-of-glass’ management of best in class hardware offering.  Today this is a $5B market with a 30% CAGR far outpacing the datacenter industry growth rate.
2.      Cisco servers are driving over 50% of the Converged Infrastructure market with their UCS Integrated Infrastructure offerings with their Flexpod and VCE options
3.      Cisco designed the HANA appliance based on their very successful Converged Infrastructure designs predicting that the appliance model would give way to the TDI model as SAP HANA matures

4.      Cisco is able to offer end to end infrastructure support for HANA TDI because the design is based on a design architecture that is already supported. Competitors have to now commence building their TDI support from the ground up – Cisco’s unified support model is already in place.


Takeaways:

As SAP HANA technology and platform matures SAP is opening the platform build to more open hardware decisions. With SAP’s release of the TDI support this is proof positive that SAP HANA has now matured far beyond what BWA could manage in 7 years of its lifetime.

As the TDI build and support matures TDI providers will similarly open their support contracts to become more harmonized as a standard SAP HANA Support contract. Cisco has done exactly that with their unified SAP HANA support. Now, whether a customer chooses an Appliance or a TDI platform this support decision from Cisco removes the last barrier of risk that customers, auditors or supporters had prior to today

1.       First and foremost TDI is a sign of SAP HANA maturity where they are now comfortable with open ware components for a HANA build.

2.       In August 2014 we predicted that TDI was going to be the way forward as SAP HANA matures and become more stable. Today TDI has become a reality as more and more proactive customers are choosing TDI for HANA. To see the strategic logic ask the basic question: How many customers out there are running their traditional SAP applications on black-box type appliances?  Then why not?

3.       The TDI decision today represents a no greater, or less, risk than an appliance model. However it does guarantee best in class components or components that your datacenter is comfortable with. TDI provides more power to the customer and their Data Center/Basis stakeholders.

4.       TDI allows you to leverage your existing skills and assets to the maximum.

5.       TDI allows customers and data-centers to mix and match best-in-world-class components and not get stuck to a black-box, contractual lock-in, and sub-par components at a premier rate.

6.        TDI allows customers to get out of the choke-grasp of a single vendor monopoly and launches them on a path of open-ware selections based on world class providers.

7.       Today we can confidently state that SAP HANA Appliances are on their way out and TDI is on the way in- so plan your HANA Infra with the future in mind.

8.       SAP currently allows Virtualized Production SAP environments, and with SP 9 and promises of what SP 10 is going to bring the TDI dynamic models certainly seem to be the professional choice for cloud, data-centers and customers that have a trusted SAP basis support team.
 
Start thinking TDI and release yourself from any choke-hold that a HANA appliance may represent and plan to leverage the maturing SAP HANA platform ecosystem. Plan towards getting the highest quality at the lowest cost via professional selections based mainly on your current assets and existing partnerships - which represents your in-house knowledge and experience.




[1] BVA= Business Value Attainment