S/4HANA Consumption Options – Key Input to your S/4HANA plans
In my day job as a SAP Architect driving innovation and digital transformation, I spend quite a bit of time helping customers to understand how S/4HANA is different from SAP ECC so they can build the business case to move.
One of the key areas where it can be very different is how you manage (or actually don’t manage) the infrastructure, software installation/patching, configuration and extensions (custom code).
I think you have 4 basic options and I have summarised these below :-
Other : In this option you pretty much carry on the way you are in now with ECC especially if you convert your current ECC system to S/4HANA. You could choose to start adopting Best Practice config (this is predefined config from SAP that they manage like it was code – they are called Scope Items) but this is only really an option if you take a Greenfield approach. You could also look to adopt the new ways to extend the solution (In App and On-Top in SCP). At the infrastructure end you could take this as an opportunity to move to the cloud using one of the certified hyper-scale cloud providers like Microsoft Azure, AWS or Google Cloud Platform. You also typically have a perpetual licencing model.
- Pro – Low change profile / Continue to run your own custom code (depending upon the code this could be seen as a Con)
- Con – Low change profile (innovation at on premise (years) speed) / Have to acquire skills to run SAP HANA
HANA Enterprise Cloud : In this option you get SAP to provide the Infrastructure (in turn they may sub-contract this but your contract is with SAP) and depending upon the contract you sign they can provide different levels of Basis, Application and other support (see this link for details). Beyond this the options are very much the same as the “Other” option above. My experience is that you typically have a perpetual licencing model but I understand subscription is available.
- Pro – Low change profile / SAP Provide skills to run SAP HANA
- Con – Low change profile (innovation at on premise (years) speed) / Have to work within very structured SAP HEC SLAs
(Public) Cloud – Single Tenant : In this option you have to start Greenfield and SAP manage software upgrades (at least one per year with the option for 2 – UPDATE As of 2019 SAP provide 2 optional upgrades per year with a forced upgrade every 4 years) and infrastructure. You can choose to adopt SAP Best Practice configuration (recommended) and where this isn’t yet available for the S/4HANA feature you need you roll your own config or you can bring your own config. Given you have to go Greenfield it makes sense to only extend using the new approaches but you can also bring your own ABAP code / add-ons. You have to have a subscription license.
- Pro – Upgrades pushed at least one per year / Can go beyond Scope Items
- Con – Have to do Greenfield / Have to work within very structured SAP Cloud SLAs
(Public) Cloud – Multi Tenant : In this option SAP manage everything except the extensions which have to be done in the new ways (In-App or On-Top). The key difference here is the strict usage of Scope Items– If it isn’t a Scope Item it doesn’t exist ! This can be confusing for SAP config experts, as some of the options available in the On Premise version are not available in the Multi Tenant Cloud. Sometimes this is because SAP haven’t yet delivered those features as Scope Items, but in others it is a deliberate decision by SAP as those features are considered “edge” use-cases and as such they will never be delivered – keep a close eye on the 3 year roadmaps. So whilst the S/4HANA code base is the same, what you can get at isn’t. The key upside with this option is that deployment is quicker (as we have fewer choices to make) and we get updates/innovation every quarter.
- Pro – Maximum adoption of new features / Faster deployment
- Con – Have to do Greenfield / Have to work within very structured SAP Cloud SLAs
In the end (as discussed in this blog), I think the vast majority S/4HANA customers will run S/4HANA in the Public Cloud Multi Tenant model (potentially with multiple tenants) so I recommend that decisions are made from the perspective of
“Why can’t we move to the S/4HANA Public Cloud – Multi Tenant ?”
When you come up with reasons that you can’t, bring them to SAP as they will be keen to remove anything stopping you – or comment on this blog / contact me and I can feedback via the SAP Mentor S/4HANA Focus Group.
Thanks Owen Pettiford for the great blog. This and your previous blog helps me in clearing loads of doubts. So eventually it has to be Cloud sooner or later. I have two concerns which i have based on my little bit of understanding of the cloud
1- I have seen two three conversations on twitter by Phil Cooley where multiple clients were impacted on cloud globally because of changes deployed, so things like these will have spiral effects. I believe with time this problem shall get resolved.
2- Security and data privacy of multiple clients. Imagine a hacker attack and this will lead to compromising all the data/accounts etc. I believe SAP must be bringing here cool innovations as other spaces.
Both great points, the flip side is when it is done right these just need to be done once (by SAP) instead of over and over again by each customer.
Thanks Nabheet Madan one of my key sayings is that just because it is cloud does not mean there is no downtime. Every system no matter what it is normally has some sort of downtime. Cloud is no different, and this is ok by the way :-). I am guessing Owen Pettiford that the Other option also covers On-Premise installations or is this only Cloud options.
Phil Cooley - I couldn't agree more - one of my friends describes cloud as "someone else's server" - which is is bit simplistic but makes the point that any software still needs to run on something physical and when you go cloud you are relying on your cloud provider to do stuff for you.
With the current complex On Premise set ups many clients have, the client needs to provide many things e.g security, disaster recovery, high availability, load balancing, power/UPS etc etc etc
When cloud works well the cloud provider does these things well ONCE and everyone benefits from the economies of scale e.g Power Station vs Local Generator.
SAP provide a lot of information about what they do at the SAP Cloud Trust Center
Thanks Owen Pettiford - I'm still gobsmacked at how many on-premise installations are going on. Surely we've come further along to know that most companies don't actually maintain their systems correctly. Why would moving to S/4HANA on-premise change that?? For me, mucking around with VPN's still in the new world is crazy and extremely time consuming. Bring on cloud I say!
Yes - OTHER includes On Premise deployments to hardware sourced by the client or other partners
Many doubts got cleared. I believe HEC (HANA Enterprise Cloud) can be best option in terms of flexibility, custom code and low cost of ownership for infrastructure.
I recommend that each step taken, takes you closer to S/4HANA Public Cloud - Single Tenant.
HEC can help in this journey from both an infrastructure and a license model perspective - so a good start.
Sorry I meant S/4HANA Public Cloud – Multi-Tenant.
Owen Pettiford ..
Advocating the move to the cloud is a bit little more difficult than that...lowering TCOs and having access to cutting edge innovations available quarterly is enticing but am afraid not enough to build up the story..
A lot of big enterprises have been living in parallel custom solutions to the extent that they don't even remember what the standard fit looks like...both enterprises and SI's to take the blame equally to bring it to this point.
Moving to public multi-tenant would require a massive overhaul of the processes and business's ways of working. Simple gaps(or maybe gap in my knowledge) around capabilities to enhance objects using in-app extensibility but not providing capabilities with equivalent enhancement in Migration Cockpit objects leave consultants puzzled.
SAP's engagement in educating the technical knowhow's to the wider community has been brilliant but I guess a push is required to educate and provide the frameworks for real discussions with business stakeholders below the executive layer.
I don't think it will be easy, just as the move from Mainframes to Client Server wasn't easy.
I'm sure if blogs had existed back then the same comments would have been made.......
5 years later the people running R/2 looked like dinosaurs.
I am recommending that people should be aware of the final destination before putting their roadmap together so each step can be towards that goal - S/4HANA Public Cloud – Multi-Tenant.
Anything else will end up being a regret cost to the business.
This is perhaps made worst by the fact that some of the organisations being asked for advice have a vested interest in keeping stuff on premise and complex #JUSTSAYIN
Typo with (Public) Cloud - Single Tenant - should be Private?
S/4HANA Cloud - Single Tenant = Product formerly know as S/4HANA Public Cloud - Private Option
Well a few differences to the license model and what you can do but basically the same - unless things have move on again 🙂
This is a great blog, Owen! It makes the different deployment options crisp and clear. If I may add that the deployment options can be complemented and further extended on demand by our in house managed services organization for complete functional management of applications, security, data and testing.
Patrick van Donselaar Thanks for the link - I have added to the main blog.
Thanks so much for that Owen!
Can you point out the difference between
(Public) Cloud – Single Tenant VS HANA Enterprise Cloud
the way I see it if a customer is willing to give all basis work on HEC senario. I cant think of any differnce on STE and HEC. apart from the 2 upgrade cycles.
The key difference I see is that with STE you can't do modifications to SAP code AND you can't convert and existing system into STE.
Lot's of more details that SAP can provide during detailed planning.
Thanks a lot of the quick reply. are you referring to modification to the standard code using a key ?
does that mean customer can do enhancements on top of it ( STE ) which are not standard code modifications ?
Ì`m the Solution Owner for SAP S/4HANA Cloud, single tenant edition.
Yes Owen means modifications to the standard code using a modification key. The customer can do enhancements on top of that (z objects, ABAP coding, etc) as long as they do not change SAP coding.
Thanks Katharina for the clarification
Is the customer allowed to use SAPGUI on SAP S/4HANA Cloud, Single Tenant edition (now known as Extended edition)?
Also, can we take leverage of RFC protocol to interact with external component(s)?
Per my current understanding SAP is offering 3 options as of today:
S/4HANA Cloud, STE
Where is S4HCPO (Cloud Private Option)? HEC agreement site still says about CPO along with STE which confuses me. I understand S4HC-STE is new name of S4H CPE(Cloud Private Edition) not CPO (Cloud Private OPtion). Can I say S4HCPO is also an additional offering which lies between S4HC-STE & S4H-HEC? If yes then how it is different from STE? Can somebody from SAP clear all of available offerings as of today?
Moreover please review this as well.
Hi Mukul, what is the source of the table you have there? Has this been verified by the S/4Hana Team?