Following on from my blog on what S/4HANA On Premise edition was all about, I am now going to explain what S/4HANA public cloud is all about. At the time of writing we have 3 different cloud editions, one for marketing, one for professional services and one for Enterprise Management. I expect the number to grow with various pre-packaged editions for various industries and lines of business. These various packages will either limit the features you can access and / or come with content to accelerate implementation.
In this blog I am going to focus on Enterprise Management, but technically the other editions are based on the same ABAP/HANA technology platform and will have the same restrictions / features.
As I did before I have split the topic into 4 separate areas :-
- User Interface
- Business Logic
I will discuss each one in turn – looking to explain how they work in S/4HANA Public Cloud.
Access to S/4HANA Cloud is via the Fiori LaunchPad with no access via the SAPGUI fat client. The Fiori tiles that you see are controlled via authorisations and divided up by functional role. Some of the tiles will start Fiori Apps (HTML5) and some will start classic WebGUI transactions. Some of the Fiori Apps have been enabled for Key User Extensibility, where fields can be added / hidden etc. For any “new” apps these must be built on top using HANA Cloud Platform.
Owen Recommends : Start to understand how you can use BUILD/Web-IDE to build apps on top of API’s using the HANA Cloud Platform
The business processes and the associated logic are configured using Guided Configuration using a Model Company as the basis for your system. The idea is to try to fit your company to “standard” model one. New features are added to the system every quarter and these are pushed into the system – so you can’t pick a choose when to take them.
You will not have access to the classic Implementation Guide (IMG) and SAP have restricted the options available in the Guided Configuration to keep down implementation effort. For someone used to classic SAP this will be a big difference.
Very limited business logic can be added in specific places but only a restricted sub-set of the ABAP programming language is allowed so you can’t impact the rest of the system. If you want to write any major custom business logic then HANA Cloud Platform is the recommended solution.
Owen Recommends : Start to understand how you can use HANA Cloud Platform to build custom business logic on top of API’s
Owen Recommends : Start to explore the range of features that are available in S/4HANA Cloud and how these are configured using Guided Configuration.
The S/4HANA Cloud edition uses the same simplified data model as the on premise S/4HANA. However no direct access to the database is allowed and as this is a public cloud model database size, back up and DR are all covered by SAP. So you get the benefits of HANA without having to understand it.
To interface into/out of S/4HANA Cloud you need to use the White Listed APIs. You will not be able to write any business logic for pre / post processing for interface files, so this will drive the need for middleware. HANA Cloud Integration is the recommended solution to encapsulate any pre / post processing.
Owen Recommends : Evaluate how S/4HANA can be integrated to using pre-packaged content in HANA Cloud Integration (as noted by Maarten you can also use SAP PO for this integration).
All of the above differences are designed to lower the TCO associated with S/4HANA. Some customers will love having the robust “digital” core SAP is famous for without the hassle of having to run the system, others will find them too restrictive and will accept higher costs for increased flexibility/control. I guess the key is making sure you actually need the flexibility/control in the first place and/or making sure you can’t achieve the flexibility you need using HANA Cloud Platform to build on top.