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.
массажный матрас Yamaguchi
ReplyDelete