4 Key Questions Your Organization Should Ask When Choosing a Support Option for Your SAP Hyperscaler

With the hyperscalers hitting prime time in the market, organizations are relinquishing any reservations they once had about the public cloud.  As they plan to migrate their workloads to the cloud, companies need to understand their support options and make a directional decision on how they will support their hyperscaler investments prior to beginning the migration to the hyperscaler.

However, it has been my experience that once an organization begins to consider support, they begin to ask several critical questions, including:

• What are our support options?
• What is the right support option for our organization?
• What are the contractual and financial considerations?
• What model is being chosen by most organizations?

These four common questions come from our clients surrounding hyperscaler support options and will help ensure that your organization feels equipped to pick the best model that is best suited for your needs and objectives.

1. What are your support options?

We have defined four primary support options customers have to choose from for managing their SAP workloads with a hyperscaler.  Within these support options, there are three specific components we have noted within the SAP hosting space as it pertains to the hyperscalers: infrastructure, infrastructure services, and SAP hosting services.

In each of the options, your infrastructure will be delivered through a hyperscaler, either Google, Microsoft, or AWS.  The key to understanding the different models is in understanding who’s managing the infrastructure, and who maintains the contractual relationship with the hyperscaler.

There are several hybrid components within each model.  However, to keep it simple, these are the four models we see most often:

• “Do It Yourself” Model (DIY): Under this model, both the infrastructure management and hosting services are being delivered by the customers themselves.  Additionally, the contractual relationship between the customer and the hyperscaler is a direct relationship – no third parties support your contract.
• “Do It for Me” Model (DIFM): Under this model, the contractual relationship is still direct between the customer and the hyperscaler.  However, we transition the infrastructure management and hosting service to a third-party support provider who is engaged to deliver the SAP hosting and infrastructure services.
• Professional Model (PRO): With the professional model, a third-party support provider is still responsible for delivering the infrastructure management and hosting services.  The key difference in the professional model is that the contractual relationship has now shifted to be directly between the hyperscaler and the third-party support provider.  The associated contract provisions and terms have now become a pass-through to you as a customer.
• SAP RISE / HEC Model (SAP): Under the SAP HEC and SAP’s latest RISE model, you have one contract with SAP, and your hosting services are being underpinned by one of the three hyperscalers. RISE is presented in one commercial construct encompassing software, infrastructure, and technical services delivered by SAP and the hyperscaler.  This is comparable to the SAP HEC model but bundles the software into your contract as well.

To understand these options, there are three key elements to consider: who is delivering the physical environment, where the environment is located, and who is supporting both.

First, consider who is delivering your infrastructure.  Under these models, it will always be one of the hyperscalers, but the hyperscaler you choose could still impact what model will best fit your organization.

Next, you want to consider who is providing the support to your environment, whether that’s internally delivered by your organization or externally delivered through a third-party support provider.  Lastly, you need to consider how you want the contractual relationship with the hyperscaler to be managed, whether that’s directly with your organization or through a third-party support provider.

2. What is the right support option for your organization?

To determine the best support option for your organization, there are a few key considerations and questions to ask yourself.  First, consider your organization’s internal maturity, especially with managing cloud and ERP workloads.  The more internal maturity your organization has, the more appealing the DIY and DIFM models should be to you.  These models require you to have a greater understanding of your environment while affording you more control over that environment, and a willingness to take on the management responsibility to ensure the environment is architected for performance while capturing the commercial advantages afforded by the hyperscalers.

Your organization should also consider what your vendor management bias looks like and assess your relative maturity level of managing a multi-vendor environment.  We often see that some customers want to keep it simple – they just want one vendor to manage.  For organizations looking for that simplicity, they’ll trend towards the professional and SAP models.  For customers equipped to manage a multi-vendor environment, the DIY and DIFM models remain appealing and afford them a degree of commercial flexibility and transparency not currently afforded by SAP.

One of the most important considerations for your organization to work through is your business and IT roadmap.  Your organization must ask itself if your hyperscaler decision is based on a broader digital transformation roadmap or focused primarily on your SAP needs.  If the former, you’ll likely want to maintain commercial and contractual control limiting your support option to the DIY and DIFM models but delivering the requisite flexibility required to support a broader strategy beyond SAP.

Lastly, consider your existing supplier relationships, whether that’s at the hyperscaler level or the third-party service provider level.  You’ll want to understand the size and scale of those relationships and which support option will help maximize those relationships.

Generally, we’ve recognized a support continuum where organizations with a high degree of internal maturity and a desire to maintain control over their environment will go for the DIY model.  Moving down the continuum, organizations where SAP is a component of their broader hosting strategy, there are existing vendor relationships and the organization requires model flexibility, so they will choose the DIFM model.  Finally, organizations that lack internal maturity or the desire to keep it simple will land on the professional or SAP models.

At the end of the day, there is no right or wrong support option – there’s just what is right for your organization based on your internal biases and internal level of maturity.

3. What are the contractual and financial considerations?

Interestingly enough, as we’ve supported clients with their hyperscaler support model decisions, we have seen varying financial models, even with the same vendor across clients of similar size, scale and objectives.  These models include fixed fees tied to a volume of assumed support similar to that of an IT managed services deal (i.e., ARC/RRC, deadbands) and variable models tied to the specific number of virtual machines and system IDs supported.  Regardless of the model proposed or desired, there are two key areas to consider: degree of transparency and degree of flexibility.

Each of the support models offers differing degrees of transparency and flexibility.  Generally speaking, the most commercial transparency and support flexibility are obtained via the DIY or DIFM models, primarily due to the direct contractual relationship with the hyperscaler.  Instead of the hyperscaler fees being a pass-through from the managed support provider, as in the PRO model, you have complete line of sight to the rates, investments, credits and the ability to modify change support providers without impact to the hyperscaler or the need to undergo the hyperscaler version of a data center migration.  While the DIY and DIFM models offer the most transparency and flexibility, they do come with increased accountability on behalf of the customer.

Where the DIY and DIFM models are the most transparent and flexible, the SAP offered options are the least transparent and flexible.  SAP will provide limited-to-no transparency into the underlying cost components and offer a “we’ll figure it out” model in regard to the cost of service and infrastructure volume growth.  Unlike the models where the customer has a direct contractual relationship with the hyperscaler, there is no ability to commercially optimize the unit rates.  SAP will provide a consolidated base rate and that base rate will grow year-over-year without corresponding increases in service performance and/or volume.  Even though the underlying infrastructure is with one of the hyperscalers, if a client chooses to subsequently go with another model, it will require an infrastructure migration and a new set of setup/implementation fees.

Thus, it is exceedingly important for an organization to assess their current maturity level and flexibility needs into the future and select the model that is best aligned to drive the requisite level of commercial transparency and support flexibility to suit their needs now and into the future, otherwise be faced with compounding costs and unnecessary pain and suffering.

4. What model is being chosen by most organizations?

At the outset of an organization’s decision-making, we generally see them gravitate toward either the DIY or SAP models.  The DIY starting point is for organizations with a high degree of internal maturity with cloud solutions or those that are unaware of the complexity of the solutions and are relatively unaware of their available support options.

Under this model, the customer captures any commercial benefits but is solely responsible for hosting and supporting their hyperscaler and thus assumes a fair amount of risk.  As a result, those that are unaware of the complexity then generally shift towards the DIFM model to alleviate that responsibility and minimize their overall support risk.

Other customers with an overwhelming desire to keep it simple land at a different starting point.  They may have an SAP hosting strategy that is not part of something broader and they only want to manage one vendor and one contract, so they generally choose the SAP model as a starting point.  However, as we discussed, the level of transparency you will get with that option is limited at best, and you are now signed up to be on SAP’s path, limiting the decision options and general flexibility your organization has moving forward.

Because of these limitations, organizations will shift towards the PRO model and eventually to the DIFM model.  The organizations making this shift may already have a large, pre-existing relationship with their hyperscaler that they want to maximize, encouraging that organization to leverage the DIFM model while still gaining transparency and control over their environment.

We do not want to place a major emphasis on the DIFM model or say that most organizations are going with that model.  We have just noticed that the customers we support ultimately have landed or are trending towards this approach regardless of their starting point, and there are several benefits to leveraging this type of environment.

Bottom Line

At the end of the day, it is up to your organization to determine what support model will best suit your needs and capabilities.  In order to determine this, it is critical that you understand what options are available, what option best aligns with your internal level of maturity and biases, and the contractual and financial pros and cons of each.  Having a complete understanding of these considerations will position you to make the right decisions regarding the support of your hyperscaler investment.