It has happened more than once seeing persons involved in SAP HANA opportunties,
that without realizing, built unfair doubts and concerns in their customer’s minds
regarding whether adopting SAP HANA is really the best option for a specific business
challenge, and whether it is mature enough to support mission critical applications.
The result was a miss perception of the achievable values in terms of both CAPEX and specially OPEX when implementing and running a SAP HANA landscape.
This has led in some cases for SAP HANA adoption projects
to be halted, postponed or even canceled.
Among the different situations I’ve observed, one aspect
has been repeating itself: relates with the Data Center integration of SAP
HANA, and its operations practices.
I would argue that it has happened for 2 reasons:
1. those
persons talking with the customer have no clue what it is like to manage and
operate a datacenter supporting aggressive Service Level Agreements in support
to Business Critical applications, neither the costs involved in that, neither of all the options currently available to SAP HANA;
2. customers managing business critical applications in support of aggressive SLAs know that changing people and processes is always more costly than implementing a new technology, and so they always look beyond the high level characteristics of that new technology, down to its
implications on operations cost and risk down the road. And if they find no trustworthy options may decide for a postponement or "additional research" before making a commitment.
In the last couple of days, EMC announced the availability
of certain functionalities for use with SAP HANA, that I believe will
revolutionize the way many customers have been facing SAP HANA deployment
options until today, and that will simplify the Datacenter operations of SAP HANA
systems, contributing to lower operations cost, less risk, and better lifecycle
management options.
This announcement further confirms the high level of maturity that SAP HANA software has reached since its announcement in 2010, and enhances the choice available to customers looking into HANA as a platform for their mission critical applications.
This announcement further confirms the high level of maturity that SAP HANA software has reached since its announcement in 2010, and enhances the choice available to customers looking into HANA as a platform for their mission critical applications.
I’m not sure whether most people involved with SAP HANA opportunities around the world are
fully aware on how this announcement could help overcome the concerns many SAP
customers have been expressing, as well as how much it could impact the costs
associated with change, risk and operations management of SAP HANA systems in a
mission critical datacenter environment.
So, through this blog post I’ll share what I’ve learned
from the customers I’ve been meeting in regards to their decision process, and
will explain why this EMC announcement is so ground breaking, trying also to
explain the relevance of the technical solutions announced in terms of their
impact on datacenter operations, tying into the potential impacts in achieving overall lower OPEX out of running SAP HANA system landscapes..
I will also further explain why I believe the SAP HANA appliance model will become obsolete, by exposing the case of Converged Infrastructures as a factory built infrastructure stack that can be shared both among HANA and non-HANA workloads, contributing also to drive down HANA projects CAPEX.
2015-05-01 Update: SAP has come to agree with all my arguments here, and the evidence of that can be found on the "New HANA Economics" presentation, that I would strongly suggest you to go through. Having this presentation been build to support the arguments that running SAP applications on HANA is more cost effective that running them on Oracle, the same reasoning also supports all I'm arguing on this blog post.
Setting the scene
As more customers adopt SAP HANA systems, its use
scenarios also expand.
While many customers realize the potential benefits of
integrating this technology into their applications portfolio, many still
struggle either to achieve a positive ROI business case for its adoption, or
get concerned with the limited datacenter integration options available, which
most of them know will be a key factor driving up IT Operations, Risk and
Change management costs.
In this perspective, some even say that the variety of
options in terms of datacenter integration of an application, are a good sign
of its maturity. This leads to the consideration that SAP HANA still lacks the maturity
as a product to reach the prime time of Business Critical applications in many
of customer’s datacenters.
I heard a wise CIO once saying, that for his mission
critical applications we wanted “the almost latest technology” as testing new
things with its core business, is a risk that has cost the job to many.
Having persons involved in SAP HANA project opportunities pushing for the “pitch”
they were taught and presenting unreal and very limited options in regards to datacenter operations, without fully
understanding the variables customers consider when running Proofs of Concept,
may sometime do more harm than good in helping customers make their decisions.
Figure 1: SAP
HANA Tailored Datacenter Integration for Enterprise Storage enables sharing the
same storage infrastructure for SAP HANA and non-SAP HANA applications.
I’ve once written that I
believe the SAP HANA Tailored Datacenter Integration program would make the
appliance model obsolete, not only by driving further choice and openness
to customers, but also by making easier for SAP partners to bring their A game
to the table.
Recent announcements further confirm this, by further expanding SAP HANA's Datacenter integration options, and through that, providing more choice to customers, further showcasing its current high maturity levels.
Recent announcements further confirm this, by further expanding SAP HANA's Datacenter integration options, and through that, providing more choice to customers, further showcasing its current high maturity levels.
EMC has just announced the release for productive use of
the replication (synchronous, asynchronous, concurrent and cascade), cloning,
snapshot and consistent split technologies embedded in their VMAX arrays, for
usage in production with SAP HANA Systems both in physical as well as
virtualized configurations.
These technologies will enable major cost savings and “de-risking”
of SAP HANA implementations, and SAP resources involved in “ HANA DataCenter related”
discussions should at least be aware of these things.
So, let me try and shed some light over a different
perspective in regards to the "why" customers may value these new possibilities, in order to help you expand your understanding of the currently available possibilities to integrate SAP HANA into existing datacenter practices.
Why customers consider implementing SAP
HANA
Today, with globalization, companies need to be faster and
more precise than ever in their business decisions.
This is taking many organizations to decide for the
adoption of SAP HANA, the new In-memory Database from SAP, as a way to
accelerate the way the company is operating.
With the increased adoption of SAP HANA by customers
globally, the variety of use cases also expands, leading to increased situations
where SAP HANA will become the primary persistency of Business Critical
Applications.
Business Critical applications, due to its relevance to
company’s business, usually imply more demanding technical requirements, which
lead to increased overall costs associated with its implementation and
operation.
Those technical requirements are usually related with
aspects like:
·
Availability;
·
Recoverability;
·
Data Protection;
·
Performance.
Nevertheless, companies don’t buy technology just because
it is the fastest, or the best in any particular characteristic in the world.
Figure 2: Example of balancing factors in customer’s decision
process related with new technologies adoption.
The best managed organizations (and the ones more subject
to fierce competition) make decisions on a balance between the expected Business
Benefits and the Costs associated with those technologies, evaluating carefully
what is the reasonable Return on Investment to be achieved.
And what I’ve observed is that many organizations evaluating
SAP HANA adoption projects, considering only some of the limited options available in the past, has made it impossible for many of them to solve this equation, in a way that they reach a comfortable positive ROI result.
Questions that delay SAP HANA adoption
This happens as most organizations undertake a decision
process that involves asking (and getting facts supported answers) to a number
of questions other than just simply finding whether SAP HANA is the fastest
thing they have ever seen. Examples are:
·
What Technical Requirement must be meet to
support the intended Business use of SAP HANA?
·
What will be the investment needed to implement
SAP HANA?
·
What will be the operational implications in
terms of cost and risk of meeting the Technical Requirements based on the
various Implementation Options?
Figure 3: examples of aspects evaluated by organizations in the
process of deciding for SAP HANA adoption
After evaluating all these needs, customers must reach a
positive ROI scenario to move forward with their purchasing decisions.
Usually, setting up Proof of Concepts have the goal to
confirm that HANA has the capability to speed up the Business Processes to the
expected levels, but also the goal to gather knowledge that enables responding
in an “evidence sustained way” to questions like the ones on the figure above.
I’ve heard from our customers that in many cases
where negative ROI is reached and the purchasing decision is halted, the key
factors contributing to drive up the cost are associated with risk, change and
operations management.
In fact, in most customer scenarios the cost of operating
a certain business application on a 5 year period is far greater than the
investment required to implement that application, and we see this same
feedback from customers when discussing SAP HANA adoption projects.
When evaluating more than just the CAPEX part of a SAP
HANA Adoption project, unfortunately I’ve found quite some customers where the calculated
Total Cost of Ownership (TCO) of a SAP HANA solution (the OPEX part of the
equation) simply led to a negative ROI business case, having as a consequence
the mandate to find other alternatives that are able to provide that positive
ROI business case, or simply halting, canceling or postponing the SAP HANA
related projects under evaluation.
This is quite unfortunate as today's reality provide far greater options and openness that it was possible 1 year ago, and many times that information is not made available to customers.
This is quite unfortunate as today's reality provide far greater options and openness that it was possible 1 year ago, and many times that information is not made available to customers.
Customer experiences in Driving Down
cost of operations
A key factor driving down costs associated with risk,
change and operations management is to have known and consistent practices
& technology solutions across the technology stacks used to support those
business applications.
Figure 4: Key factors driving cost associated with SAP HANA risk,
change and operations management
In fact, is today an accepted principle that standardizing
the technology and processes across the datacenter, represents a huge cost
saving factor.
Why? For many reasons! But let me highlight some.
Having standard technologies across the datacenter:
·
drives less cost on spares;
·
enables pooling of similar resources driving
higher utilization levels, and through that lower costs;
·
simplifies automation, as the automation tools
and procedures can be used across more similar components;
·
enables economies of scale;
·
drives less dispersion of skillsets and through
that more expertise, which has as consequence the ability to manage risk
better, as well as dedicate more resources to service improvement and
innovation;
·
Enables higher automation levels, which release
IT personnel to further engage in supporting strategic business initiatives.
In summary, reducing the IT Datacenter Portfolio dispersion
drives simpler change processes, lower risk of operations and overall less cost
for the whole Datacenter operations.
To make me look smarter, let me put this in an equation:
ROI = Business Benefits – TCO
TCO = CAPEX + OPEX
Considering that OPEX for a solutions on a 5 years period
can easily be 4 times the CAPEX for that same solution, from these very simple
formulas, you can easily understand that any reduction in OPEX will have a
significant impact in the expected ROI of the project.
Further explaining the case for
cross Datacenter standardization
The fact that operation costs account for the largest
chunk of costs in the Total Cost of Ownership of a Business Application, gets
further relevance if we remember that all organizations have multiple
applications to fulfill their business needs, which is a contradicting force to
the standardization case I’ve just made.
Application choice is in fact driven by its capacity to
provide the business functionality required, which often makes companies
disperse their application portfolio across multiple vendors.
So, as application functionality drives dispersion, and in
consequence drives cost up, companies look more and more to reap their needed
IT budget savings out of the infrastructure stack.
Remembering again that no single customer has only SAP
applications in their datacenter, makes further the case to ensure that the
datacenter and infrastructure integration practices are the most common
possible across all applications.
This principle is one of the key driving forces behind
today’s large consensus behind the movement to “Cloud Computing”, being in its
Public, Private or Hybrid flavors.
Figure 5: the key steps towards implementing a Cloud Enabled
Infrastructure
(NOTE: I know that Virtualization also plays a key part in
all this reasoning, but I’m leaving it out on purpose, as the sole benefits of
virtualization are so huge, that I thought it would deserve a blog post just
for itself.)
In the past having all the standard datacenter architectures and processes shared between HANA and non-HANA workloads was not possible. But has HANA matures, new options have become available, making this a possible option today.
In the past having all the standard datacenter architectures and processes shared between HANA and non-HANA workloads was not possible. But has HANA matures, new options have become available, making this a possible option today.
Diving into the relevance of EMC’s
announcements
EMC has been known for years by its mission critical
capabilities embedded in the Symmetrix VMAX arrays. In fact, according to some
analysts, EMC accounts for the largest installed base of SAP systems running on
top of their arrays.
This means that most of SAP’s customers will already have
EMC functionality to protect and manage their existing mission critical SAP
systems.
So, being able to manage the same datacenter technologies
and procedures, will represent for many of these customers a very low startup
cost to add “just another application” on top of their existing setup.
In fact, in many customers, the combination of the multiple
technologies of the array provide “out of the box” High Availability, Disaster
Recovery, Data Protection, LifeCycle Management and Automation capabilities to
all applications that sit on top of it.
For many customers, not being able to leverage these
capabilities, and being forced by the past SAP HANA deployment option that limited HANA to be available through a dedicated appliance, meant to build a new silo in the datacenter,
with a complete new set of Datacenter Components, its unique set of processes
and management tools, represented such a startup cost and risk, that just killed
the business case for SAP HANA adoption.
For all these customers, the good news are that the SAP HANA Tailored Datacenter Integration (TDI)program has been Generally Available since November 6th, 2013 providing more options in terms of SAP HANA deployment options, and removing the restriction of having HANA only available through a dedicated hardware appliance.
As part of the SAP HANA TDI program, EMC’s has tested and proven the EMC VMAX technology for usage with SAP HANA, and has released for productive use the following functionalities of the VMAX arrays:
As part of the SAP HANA TDI program, EMC’s has tested and proven the EMC VMAX technology for usage with SAP HANA, and has released for productive use the following functionalities of the VMAX arrays:
·
EMC SRDF S/A/STAR
·
EMC TimeFinder Clones / Snapshots
·
EMC Enginuity Consistency Assist
This enables organizations to leverage those technologies
for all their Business Critical applications (including SAP HANA) in a standard
and consistent way, and through their use, to drive up SLA’s while driving down
operations costs and risks, which will contribute to the reaching of better ROI
in SAP HANA adoption business cases.
Figure 6: Key benefits for SAP HANA customers from the adoption of
the EMC VMAX storage for their HANA solutions
EMC has a set of built in capabilities in the EMC
Symmetrix VMAX storage system, that enables organizations to setup an
architecture for SAP HANA, that provides “near-zero data loss” and “near-zero
data unavailability”.
With SAP announcing the support to run SAP HANA in
Production virtualized with VMware, the benefits of running a virtual
datacenter can now also be leveraged by SAP HANA.
The characteristics of the EMC VMAX presented above,
represent a solid foundation not only to support SAP HANA setups in a shared
physical infrastructure, but also for the setup of a virtual Datacenter, one
that through the combination of the EMC VMAX and VMware vSphere capabilities,
provide out of the box a set of availability, flexibility and lifecycle
management features that can be leveraged between SAP HANA and other SAP or 3rd
party applications at a lower cost than silo based architectures like the old SAP HANA appliance model represented (but
let’s leave the virtualization part for another blog post).
Explaining the value of all these
EMC News for SAP HANA
For those of you not familiar with the EMC technology
naming, let me take some paragraphs now to map the relevance of those
technologies to SAP HANA operations challenges.
Figure 7: Mapping of EMC VMAX Functionalities to SAP HANA Data
Center Integration needs, driving up the SAP HANA Platform Resilience and
Manageability
The functionalities of the EMC VMAX enable the expansion of
SAP HANA datacenter readiness, by :
·
Simplifying High Availability:
o The
EMC VMAX has building characteristics that provide up to 6 9s availability,
like the replacement of most parts without downtime;
o The
usage of the SAP HANA Storage Connector for Fiber Channel (aka SAP Block API),
enables transparent and non-disruptive HANA node failover in case of a single
server component failure;
·
Consistent practices for DR for SAP HANA and all
other applications:
o SRDF/S
enables synchronous replication across storage volumes, ensuring an RPO of the
last committed transaction, as even the log files are replicated (enabling as
well a point in time recovery on the secondary site, if needed);
o SRDF/A
enables asynchronous replication of the SAP HANA Data and Log volumes over
large distances, enabling SAP HANA to have the SAP DR practice as all your
other applications;
o SRDF/Star
enables multiple scenarios of cascading and concurrent replication to comply
with the most demanding data protection requirements combining simultaneous
synchronous and asynchronous modes to multiple different destinations.
·
Improved Backup Capabilities
o Through
EMC TimeFinder it’s possible to build consistent disk based clones of SAP HANA Systems;
o Through
the integration with SAP HANA Snapshot functionality enable to do point in time
recoveries of SAP HANA using the HANA Studio, using as a starting point a
storage snapshot (available as of SAP HANA 1.0 SPS 07);
o Deliver
restartable copies of SAP HANA through HANA’s snapshot capabilities (available
as of SAP HANA 1.0 SPS 06);
o Backup
productive systems through a snapshot taken at a remote replicated site through
the integration of EMC’s TimeFinder with EMC’s SRDF and SAP HANA Snapshot based
backup functionality;
·
Simplified Quality Assurance System Refresh
o Use
storage snapshots to build a restartable image of SAP HANA systems without need
to stop production, and be able to convert those snapshots to full clones if
needed;
o Be
able to perform the operation referred on the previous point either on the
productive site, or on one of the sites to which the system is replicating
using EMC’s SRDF;
o Automate
the storage clone and the mounting of the new cloned volumes through the usage
of EMC’s Replication Manager software;
·
Simplified test scenarios in virtualized
environments
o Through
EMC’s VMAX integration with VMware vShpere’s VAAI, take storage based snapshots
or clones either locally or remotely, through the use of a combination of EMC’s
TimeFinder Clone/Snap with EMC’s SRDF, to enable consultants to build very fast
a copy of production for error regression debugging;
·
Simplified test scenarios in physical
environments
o Take
clones of productive systems and easily build clones of clones, or convert
snapshot to clones either locally to the production datacenter or remotely on a
replicated site for regression testing of errors in production, through the
integration of SAP HANA’s Snapshot functionalities with EMC’s TimeFinder, EMC’s
SRDF, using EMC’s Replication Manager to automate the pre and post-split steps
to very quickly the new test HANA system;
·
Secure DR Testing
o Through
the integration of EMC’s SRDF and EMC’s TimeFinder technology, you can build a
full clone of your production environment, and mount it on servers for DR
testing, without interrupting replication of your productive environment, and
through that enabling DR testing without risking production protection;
·
Cross application consistent backup
o In
the cases where multiple applications are interdependent, and the loss of data
in one fatally affects the others (which is the case for example of the use of
SAP HANA as a sidecar to a SAP ERP System with the usage of SAP SLT for trigger
based replication, where a loss of data in the ERP implies the full reset of
STL and full reload of HANA leading to multiple hours of recovery), the integration
of EMC’s TimeFinder Clones or Snaps with the Eginuity Consistensy Assist
enables to federate the disk volumes of multiple systems for backup purposes,
and to recover them to the exact same point in time consistently, avoiding the
need for the HANA System reload;
·
Cross application consistent Quality Assurance
landscape refresh
o Using
the same technologies referred in the previous point, enable the consistent
build or refresh of a quality assurance environment, ensuring that a federated
environment is refreshed at the exact same point in time (usefull for example
in the case of a refresh a a Q&A environment composed by connected ERP, SRM
and BW systems, eliminating the need for functional teams to align the systems
data after the technical refresh, and trough that speeding and simplifying test
plans).
A brief look just at replication as one example
To further illustrate the benefits above, let me look at
the example of setting up a disaster recovery architecture and associated
procedures.
I have to say that when I started my career I was a huge
fan of database software replication as a way to build disaster recovery
configurations.
It was so cool! I had to script a lot of stuff, and you
just needed a dumb on the other side.
So, back then, I couldn’t understand why anyone in their
perfect mind would choose to do hardware based replication using the storage
systems replication capabilities.
I came to understand it the “very hard way” some years
later, as I came to manage the operations team of a customer (had all the
system administrators and operators reporting to me with application
availability SLAs with HUGE penalties for any downtime that exceeded 1 hour).
Having an "explosion" reported on the primary datacenter, I had to activate
the disaster plan, and get the team working on the Disaster Recovery Systems
activation.
Through that very long Saturday night that I spent “awake”
managing firefighters, policemen, the customer and my team, I got a very
extensive understanding of Murphy’s Law:
·
As DR activation involved scripting, I came to
find out that although all our governance procedures, there were changes made
in the production system, that weren’t applied in the same way on the DR site, which represented an impediment to get some critical systems up and running;
·
I also came to understand that sometimes when
activating a DR plan you don’t have your best resources available;
·
It may also happen that your most skilled
resources do not react well under the pressure of a real disaster situation;
·
As the DR was based on database level
replication mechanisms, there were some critical files at the filesystem level
needed to get some business critical processes running that weren’t there…
Well, I have to say that this event changed my
understanding of Disaster Recovery planning, and made me appreciate hardware based,
comprehensive, automated and complete replication solutions.
Figure 8: analysis of what is, and is not, included on the SAP HANA
System replication.
So, allow me to also apply this learning to SAP HANA.
Last week I was at a customer event, and not surprisingly,
the majority of customers had very experienced people from operations there to
meet me, which had been involved in operations for many years.
So, for these guys, this is so obvious, that you don’t
even need to explain it. One of those cases was a manufacturing company that
had a failure on their production system and was out of business for almost 2
days.
The customer mentioned that this event had as consequence:
·
Full stop of production as they managed all
production planning and supply chain trough SAP;
·
Loss of Revenue for not having their product on
the shelves of supermarkets;
·
Major costs of restarts of the production plant
as a stop implies that product will be such on the pipes and raw material
having a short live period had to be through into the garbage.
This customer commented that all the ones involved in the
architecture and management of the IT components responsible for this failure are
no longer with the company.
Sometimes I may look like an
alien on the eyes of colleagues that having SAP HANA application knowledge, never were in front of datacenter operations for critical systems. These experiences leave you learnings that last for a
lifetime, and these learnings are the ones that make it for solutions that were
not the most obvious choice in certain eyes, to actually be adopted by many of your
customers.
For this customer, being able to leverage the EMC technologies they have purchased after that failure is a key decision factor in the adoption of SAP HANA, and these news were very well received, having contributed to kick start preparations to start migrating existing applications from Oracle to SAP HANA.
For this customer, being able to leverage the EMC technologies they have purchased after that failure is a key decision factor in the adoption of SAP HANA, and these news were very well received, having contributed to kick start preparations to start migrating existing applications from Oracle to SAP HANA.
It’s all about the TCO!!!
Still, at this stage, some might argue that having the SAP HANA System Replication make all these functionalities of storage arrays irrelevant in the HANA space.
Well, if it wasn’t clear yet, it's all about the TCO!!!
Licensing costs or even the total CAPEX of the solution
only represents one part!
Change, Risk and Operations management may be more
difficult to calculate at the starting point of a project, but an experienced
customer will never leave them out of their TCO calculations.
And that is why it is so important to make customers aware of what possibilities are out there.
And that is why it is so important to make customers aware of what possibilities are out there.
So, other than doing just a simple CAPEX costs analysis, I’ve tried
to make an exercise that exposes other variables that may be relevant to a lot
of other customers.
Figure 9: Example of a possible alternative analysis of SAP HANA DR
Options.
Through the table above, I do not have the presumption of
being right on all my classifications.
The point is to showcase that there are other variables that
are relevant for many customers which imply consequences on the TCO equation, and so should be considered whenever they are relevant for a specific customer SAP HANA implementation scenario.
For example:
·
Being able to replicate all the data inside a
system, and not only the data inside the database, may provide increased reliability in DR activation;
·
The possibility to use the same replication
technology for all applications in the datacenter, may simplify DR activation and get the business processes running faster, as most business processes do not work with only 1 application online;
·
The possibility to ensure a consistent backup
and restore across different applications, may be key to minimize the impact of logical errors (I have more than one
customer scenario where this is a must to ensure consistent recovery of ERP,
SLT and HANA when in a sidecar scenario, and avoid the need for a full HANA
reload in case of any failure);
·
For many customers having a Recovery Time Objective
of a couple of minutes is an easy trade off against having all the other
aspects I’m referring on the previous bullets;
·
Some customers will not consider a technology
for business critical applications that does not enable the testing of the
Disaster Recovery plan without losing protection during that test;
·
For some customers not having the need to have
active standby servers, may represent a significant cost avoidance not only in
terms of CAPEX, but also in terms of OPEX as there are less OS images to
manage, patch, etc.
What about the reason some customers love appliances?
Up until now I’ve been talking all about TCO reduction as a
key factor driving up SAP HANA adoption.
My main focus has been the OPEX part of the equation, but
there are also customers concerned with the CAPEX part of it.
This is where having shared infrastructures for HANA and
non-HANA applications come into play.
Again, virtualization of SAP HANA systems with hypervisors
like VMware is also very relevant to this discussion.
But one factor that intrigued me from the start was some
discussions I’ve observed where some argued against my blog post foreseeing the end of the appliance model for SAP HANA, that there are a lot of customers that
do want to buy an appliance.
Before closing this blog post, I wanted to touch briefly
this point.
Has anyone of you taken the time to ask questions to your
customers and try understanding why those customers liked the appliance model?
Well, I took the opportunity of the many customers meeting
and events I’ve attended over the last year to ask the question, and the
response I got surprised me completely.
I got answers like:
·
I’m not an IT engineering company, don’t want to
build systems on my own;
·
Engineering and integrating IT infrastructures
on my own takes so much time and resources, that I want to get it already
built;
·
It has happened to me buying components with
factory defects that took me weeks and even data loss before I could find out
the exact cause of that failure;
·
With all the SLAs the different teams have in my
IT organization, from getting a system into my datacenter up to the moment I’ll
be able to logon to the operating system and install an application, will take
me no less than 3 months;
·
I want a single neck to choke in terms of
infrastructure support problems;
·
I want a single provider to be responsible for
the patching and integration of all the infrastructure components…
Well, the point is that none of the answers were SAP HANA
specific!
So, I asked again:
·
What if you could have all that, but in an
infrastructure that could be shared with all your other applications in the
datacenter, and so avoiding building another silo?
Most customers answered without hesitation: that would be
perfect!
But then argued that such a scenario was not possible, as
all vendors are moving to single stack, siloed solutions, and so “between the
fire and the pan”, they would rather go for those appliances.
I realized then that most of those customers were not
familiar with the concept of converged infrastructures.
I would compare “Converged Infrastructures” with what has
been the work of auto manufacturers over the last years:
·
They produce an end product ready to be used: a
car;
·
They do not manufacture every single component
of it;
·
But they provide warranty and integrated support
to the full solution: the car as a whole;
·
They engineer the system, specify it, and
procure the production to partners;
·
They are then responsible for the physical
assembly as well as the logical configuration of the product (for example
setting the default language for the electronic systems – GPS, car audio, etc)…
Figure 10: an example of a comparison of the value of a Converged
Infrastructure for SAP HANA, against some of the currently available appliance
offerings in the market.
Again, I do not have the pretension of having covered all
the key variables in my analysis above. My goal here is to show that depending
on the usage scenario of SAP HANA, and on the specific customer situation,
there may be other variables that matter.
IT is evolving, and in the same way are evolving IT
Infrastructure providers.
It’s my perspective that the maturity state IT has reached
as enabled IT infrastructure providers to evolve from single component
delivery, where customers were responsible to assemble and support the full
solution, to a scenario where a provider provides already a “ready to drive”
solutions, and one that can be driven by multiple persons (run multiple applications), as opposed for one
that can only have a single unique designated driver (single application silo).
Converged Infrastructures provide to SAP HANA customers the
best of the SAP HANA appliance model in a shared “factory built”
infrastructure.
When making this comparison I’m referring to VCE’s VBlock Systems,
which incorporate from factory all those EMC technologies I’ve been referring
through this blog post, and so enlarging the Datacenter Integration options of
SAP HANA, while driving down risk and complexity associated both with the SAP
HANA Implementation Projects (the CAPEX part), as well as SAP HANA operations
(the OPEX part).
Conclusion
I believe all of these are great news to come out on the
week is happening the SAPPHIRE 2014 in Orlando, as these announcements are an
evidence of the maturity levels SAP HANA has reached, which prove it as a
technology ready to reach the prime time of mission critical applications in
our customer datacenters.
I hope that people advising customers on SAP HANA Datacenter Integration and its impact on operations learn about these new possibilities, in order to present the realistic view of today's SAP HANA openness and Datacenter Readiness in it full scale..
Fortunately there are many around the world that have understood the importance of being up to date on the datacenter integration options of SAP HANA (not only from SAP but from partners as well), and I’ve
been very privileged to be some SAP employees in customer events and
discussions where this topics were openly approached and discussed, having
those discussions contributed decisively to help those account teams bring to
successful closure SAP HANA deals that were “on the hoven” for quite some time
without progress.
Also, all these news are another evidence of the major focus
the EMC Corporation is putting in further enhancing the SAP HANA datacenter
readiness, and through that also drive its increased adoption.
What I’ve touched here represents only a small part of all
the things EMC has been working on, and there are a couple of things I know for
sure:
·
The best news from EMC are yet to come (DSSD
acquisition coming to market, and others…);
·
Competition will only increase on the SAP HANA
space, having competitors running fast to catch up on this announcements, which will further increase the Datacenter Integration and Openness of SAP
HANA, contributing for an accelerated pace of HANA adoption over the coming
years.
If you were brave enough to read through all this very long
email post, do not hesitate to get in touch with me for comments or questions!
All perspectives will be highly appreciated.
For reference, check out the following links:
No comments:
Post a Comment