My last thoughts on this blog were published some two and a half years ago, and the topic of RISE with SAP and where it best fits has evolved over time. By now, SAP RISE is familiar to the SAP marketplace and has become more understood and recognized – though how SAP markets the solution leaves some subtle and important details unclear.
SAP positions RISE as a one stop, single vendor, cloud based solution to run SAP, advertised as a simple, cost effective way to get started with SAP in the cloud, including all the necessary tools and services. Part of this offering involves migration services from ECC, an important element of the story.
Unpacking the various elements of the offering reveals a multifaceted combination of upgrade and migration services, ‘run and maintain’ operations, and software licenses for SAP customers. For SAP itself, RISE is really a go to market and business transformation plan, evidenced by how the solution is marketed and licensed.
My view is to take the perspective of the customer – from under $1b, to the mid market of $1-20b or so, and then look at the very large enterprises independently. Then, break down the story of RISE into S/4HANA migration, regular run and maintain, and finally from the perspective of SAP’s long term business as a software company. The matrix of intersections here helps answer the question “Does RISE with SAP make sense for my business?”
What is RISE with SAP?
In 2013, SAP announced HANA Enterprise Cloud as a solution to problems deploying HANA. At that time, buying SAP HANA was challenging because it required expensive specialist hardware and installation. On top of that, none of the top tier hosting or cloud providers supported SAP HANA’s requirements.
I remember meeting with the then CEO Jim Hagemann-Snabe in 2013 and commenting that if he created HANA Enterprise Cloud to galvanize the market to build HANA based clouds, it was a pretty smart move. He smiled.
Fast forward to now, all the major vendors including hyperscalers Microsoft, Amazon, and Google provide HANA based solutions through a marketplace. Additionally, demand from direct customers encouraged hyperscalers to consider SAP workloads as a targeted market, with SAP specific offerings. As a result, hyperscalers and other hosting providers broadly support S/4HANA, and SAP has effectively exited the Infrastructure as a Service (IaaS) market.
RISE has become an offering of S/4 in the cloud, a combination of infrastructure provided by an underlying hyperscaler, operations provided by a third party systems integrator / operator, and SAP licenses running on these services. It might additionally include migration services for moving to RISE for existing SAP customers.
RISE with SAP is not a product per se, it’s a combination of services and licenses from multiple parties that together deliver a solution to operating S/4 as a service and possibly managing the migration there as well. SAP’s push to RISE has as much to do with SAP’s desire to move to a recurring revenue model as something customer driven. But the net result of buying SAP as a service – software, hosting and upkeep combined - will be attractive for customers where buying software with an expense budget is appealing.
For some customers, RISE makes purchasing SAP with capital budget more complicated, spare longer term contract commitments and accounting maneuvers – it’s something to consider.
What are the components of RISE with SAP?
SAP’s own RISE homepage categorizes RISE into Cloud Solutions, essentially additional services for moving to a cloud based operation of SAP:
- Cloud Infrastructure, realistically a combination of a hyperscaler and operations services at the application layer
- Migration, services to move to S/4 including SAP and partner services to remove (or migrate) modifications and harmonize the data layer.
In practice, it’s a layer cake of cloud infrastructure from a hyperscaler, operations from a consultant including application level management and SLAs, and optionally, migration services. The value add is SAP RISE ostensibly provides a set of best practices for running SAP across the stack applied to your implementation. And, for some subset SAP customers, this is likely to be true.
S/4HANA migration and RISE
SAP has positioned RISE as a complementary and even pathway solution to S/4 migration. The acquisition of Business Process Management company Signavio is one example, and a guided migration methodology and partnership with Systems Integrators and consultants is another element of this effort. But S/4 migration is still real work for many companies – often a timeline of years and a budget of 7 or 8 figures– and RISE alone (without migration services) doesn’t do much for problems like custom code remediation where much of the migration effort lives.
The march to S/4 has been steady but slow. There’s debate regarding the percentage of customers on S/4, with commonly cited numbers in the 11 – 31% range. Observations suggest there’s some slack to be had comparing customers with S/4 in production vs. completely off ECC, but we can use either end of the estimate to better understand what migration means depending on the company.
No one debates that a fresh deployment of S/4 or migrating smaller enterprises with single instances of ECC is easier. These customers make up a significant portion of the early S/4 migration success stories. They are less likely to be heavily customized and face years of code remediation or business change from adopting new standard processes. The ‘run and maintain’ requirements are modest for these customers, and they are less likely to have multiple instances and integrations complicating a deployment in RISE.
Ironically, they are also the customers most easily poached by existing SaaS competition to SAP. If facing what’s really a reimplementation, why not survey the market and see what’s out there? SAP has some soft spots when evaluated against specific modules of best of breed solutions. Another vendor may offer a viable option with a switching cost competitive with S/4 migration.
The mid tier and large enterprises present a different problem. Arguably, the percentage of customers migrated to S/4 is less as one moves up the complexity of migration scale, and certainly plenty of the very largest SAP customers have cited migration plans measured in years and even decades.
SAP has clearly moved to S/4HANA as their core offering, and the end of support dates for ECC, extensions aside, have been known for years. Effectively, ECC is no longer receiving updates or improvements, yet there’s clearly a market delay in the full adoption of S/4 for any variety of complexity, cost, and technology issues. RISE is positioned as a solution to that, but the delay is a problem for customers and SAP because SAP has not been backporting innovation back into the Business Suite for years. The longer it takes to upgrade, the harder it becomes for customers, and the bigger the chance they invest in alternate solutions.
A set of customers will stay on ECC. Extended support is more expensive but can buy valuable time to evaluate alternative solutions. Despite SAP’s well published sunset dates, extended support will be a “quiet” option until it becomes economically unattractive, and another action is forced for business reasons. For those customers, and it might be in the thousands at current migration rates, a technical management solution will be required for managing the hardware, software and applications layers no longer supported by Solution Manager.
Who’s delivering RISE with SAP?
From an infrastructure standpoint, it’s one of the hyperscalers or cloud vendors, with SAP staff or a contracted consulting firm providing operations. To the SAP customer the advantage is a single point of contact with a single contract for running their S/4 implementation. SAP advertises additional benefits around operations including a secure environment, flexible scalability, stack maintenance and compliant systems; all valuable, but also typical of any hosted environment.
For the smaller SAP customer or new S/4 implementation, this is a solution to seriously consider. For a medium to large enterprise with multiple SAP environments, it’s much more nuanced. SAP RISE only runs S/4HANA, and it’s focused on the production aspects of doing so. That works for many use cases, but it also assumes itself as a single solution. Larger implementations and migration projects are rarely so tidy.
What about when there’s more than just RISE with SAP?
For larger SAP deployments, there’s likely multiple production instances, and for customers with z-code, plenty of N+n development landscapes, upgrade landscapes and so on. One could conceivably put all of this in RISE once migrated to S/4, but what do you do during the migration process – which is likely measured in years – and is RISE really the right place to put everything SAP? How likely is it that everything in the enterprise falls neatly within a handful of S/4 landscapes and core S/4HANA? Each bit of external solution complicates the picture of integration and operations since RISE manages through the application layer.
For the medium to large enterprise, there are typically multiple landscapes for production, and conceivably many Dev and QA systems in various configurations of N+n and service pack levels. With complicated S/4 migrations, it’s not uncommon for an S/4 upgrade to take place during the process of code remediation, triggering parallel release and update cycles. It’s hard to imagine large scale enterprises fully outsourcing this.
And, we’re not even at the point of discussion about integrations, other best of breed solutions within the enterprise outside of core ERP, and so on. RISE was never designed to manage this broader collection of solutions common in large businesses.
So, who’s running this stuff? How do we get a single view of our SAP landscape and integrated components across the enterprise? S/4 updates more often, the sunsets are on tighter timelines. Who’s provisioning and deploying all of this for the non Prod systems? Who’s keeping the existing ECC landscapes scheduled for decommissioning (eventually) updated and secure? RISE will handle the managed S/4 systems, but that leaves much of the enterprise in other hands.
How do we deal with observability across what can’t help but be a hybrid infrastructure? And, how will we hold the various service providers to account?
It's worth noting that the standard SLA for SAP RISE is 99.5%, or almost 2 days of unplanned downtime annually on top of the scheduled outages for planned service in the RISE contract. Non Production systems are managed at 95%. The service level can be upgraded to 99.9% at a significantly higher cost. My own opinion is most businesses probably do better than 99.5% presently, especially large enterprises with 24 hour business cycles.
This is where RISE with SAP might not be the best choice.
So, what’s a business to do?
Offering generic advice is challenging as each individual migration is unique, but there are some broad strokes one can consider helping inform the decision.
Where RISE makes obvious sense hasn’t changed much since introduction:
- a smaller SAP user – less than 5 landscapes – and not already a large consumer of hyperscaler services and running SAP with a negotiated contract in place.
- Or, a net new S/4 customer. Customers looking to implement S/4HANA for the first time should certainly evaluate the SAP S/4HANA Public Cloud, Single Tenant Edition (STE), and RISE with SAP.
For medium to large enterprises, RISE may well have a place, but it will depend on circumstances. If you value moving from a perpetual license model with annual maintenance fees to Software as a Service, and especially if the RISE migration services suit your needs well, it’s worth consideration.
Your existing relationship with hyperscalers and systems integrators should be evaluated, as those contracts already in place may offer a competitive option to RISE.
- If you want to keep a single contract with a hyperscaler, you can continue to do so, but not via a RISE with SAP contract.
- Likewise, if you want to keep a single contract with your chosen systems integrator, you can continue to do so, but not via a RISE with SAP contract.
RISE with SAP may add some complexity because it means you must have two partners - SAP for IaaS and some CMS, and a services partner for some CMS and AMS. For instance, SAP takes care of Client 000 SAP Basis work, but requires the customer or partner to take care of productive clients. Though unlikely to be an issue for medium to large enterprises, Client 000 access is prohibited in the smallest RISE configuration options, making some external management tool deployments more complicated.
Why would I want RISE with SAP?
RISE with SAP is quite advantageous if you are looking for a single contract and set of SLAs.
The other significant advantage is that SAP is likely willing to roll shelfware into a RISE with SAP contract. In some cases, it may be possible to reduce waste in contracts significantly.
The 22% Enterprise Support maintenance costs are a burden for yet other customers, and it suits them to push Capex into Opex.
What are some other considerations for RISE with SAP?
Some large customers prefer to contract all their hosting and services requirements directly to vendors to perform contract consolidations. In some cases, those contracts are much larger than the size of the SAP contract, and so customers could be giving away leverage with those vendors by consolidating part of their requirements on SAP paper.
There is the question of whether vendor lock in through the full stack is an issue for customers - presently they can move around contracts as they move to different providers. This may be partially mitigated by SAP allowing changes to the underlying vendors.
Another disadvantage is that it may be very difficult to have a multi cloud strategy which allows you to optimize costs based on available infrastructure options. For many larger customers, it is likely that RISE with SAP will be more expensive than tendering the services separately, because SAP will need to make a margin on services and cloud provided by other vendors.
Historically SAP positioned RISE as a cost reduction play with promises of a 20% reduction in total cost of ownership (TCO), but the claim is less at the forefront of RISE messaging today.
What is the competition to RISE with SAP?
Almost every systems integrator has a competitive offering to RISE with SAP and most have combined Application and Cloud managed services into one offering and offer this via a hyperscaler. Some have very sophisticated AIOps platforms which automate running SAP, or at least partnerships with best of breed SAP management solutions at the hardware, software, and application layers.
With Solution Manager’s planned end of life and no significant replacement for what limited functionality it did have, any seasoned SAP operations vendor has something(s) else in place already.
How is RISE with SAP licensed?
SAP tends to keep its licensed models closed for legal reasons, but we know a few things at this point.
First, SAP single sources RISE contracts and passes revenue through to other vendors to control the customer conversation.
Second, RISE contracts are subscription based, and SAP’s moves with RISE are no doubt related to increasing Annual Recurring Revenue (ARR), pleasing investors and analysts.
Lastly, SAP’s chatter leading into 2020 about consumption based models is published as the CPEA, and an option for RISE.
What are my final thoughts on RISE?
RISE is here, and it has a place within a range of SAP customers and migrations to S/4HANA. It’s not a panacea, but with as diverse an install base and range of applications as SAP core ERP, what could be?
At heart, RISE is still primarily a way to move customers to S/4HANA and provides some interesting aspects to consider for users facing a migration and considering a SaaS solution.
That said, for every day a customer delays moving to S/4HANA, there is a chance that they take a different direction - either different business investments, or worse, moving a component of the SAP Business Suite into a competitor’s cloud.
It seems likely that RISE with SAP will continue to market itself as a more cost effective move to SAP S/4HANA. What is less clear to me is how many of SAP’s key customers will want to consolidate all their SAP spend under SAP itself, or if that solution is technically practical for the largest customers.
Why is SAP So Far Behind the Market in DevOps?
SAP is fantastic at many things, but improving how customers run existing operations isn’t one of...
Syslink Xandria (now Avantra) named the best vendor for SAP landscapes in a next-generation APM market research
“The all encompassing SAP technical and business process solution enables it to provide performance...
Avantra: The Future of AIOps for SAP
It was over five years ago that I sat in SAP's Palo Alto office discussing with Hasso Plattner the...