White boarding SAP S/4 HANA

Dick Hirsch Profile picture for user rhirsch May 17, 2015
Dick Hirsch whiteboards SAP S/4 HANA so that CTOs don't have to.

S4HANA - logo
(via SAP)
Two years ago after the release of the HANA Enterprise Cloud (HEC), I wrote a long blog entitled “Understanding the HANA Enterprise Cloud:  An initial whiteboard”. This year’s Sapphire Now conference just ended and I want to try and do something similar regarding SAP’s cloud-based offering - S/4 HANA.   I’ve written stories about S/4 HANA in the past but after a myriad of discussions at this year’s Sapphire and I want to take another shot at presenting my understanding of the product.

Caveat:  I’ve heard SAP’s descriptions regarding the new offer in various keynotes, press conferences, sessions, etc but I’d like to start from scratch and create my own story; therefore, the terms I use here may be different than those currently used by SAP to define S/4 HANA – especially since this messaging may have caused confusion amongst customers

A foundation

S/4 HANA is based on a single code-base that is the foundation for all “editions”. In the past, there were three editions of S/4 HANA (OnPremise, Managed Cloud and Public). At Sapphire Now, this was reduced to two editions (OnPremise and Cloud).  In my opinion, “OnPremise” isn’t really correct, so I’d like to use the term “Private”.  The distinguishing characteristic between the “Private” and “Public “editions is the degree of “SaaSiness” (typical characteristics of SaaS applications  including subscription-based pricing).

Note:  I’m examining the degree of “SaaSiness” within the scope of S/4 HANA – I’m not using it as a standard in comparison to other non-SAP SaaS applications.  There are definitely other “purer” SaaS applications in the market but such a comparison isn’t the focus of this piece. 


Although there are theoretically pure “Private” and “Public” versions of S/4 HANA, company-specific manifestations will probably emerge that combine various characteristics of each extreme.   For example, one SI may allow greater customizing for customers at the expense of a weaker SLA or at a higher cost. Furthermore, a company / SI could have multiple S/4 HANA-related offers to meet the needs of different customers / business requirements.

Pretty hypothetical, huh.  Let’s try and apply it more concretely to the private edition of S/4 HANA and add additional information regarding the involved hosting entity and an example.

The deal with HP regarding S/4 HANA was just announced and is similar to HP’s already existing offer to provide HEC environments for its customers.

The offering combines SAP S/4HANA, the next-generation business suite designed to help customers Run Simple in the digital economy, with HP Helion, HP’s enterprise cloud platform for deploying, managing and utilizing workloads in hybrid IT environments. Expertise in advisory, application migration and implementation services from both companies will help customers determine their ideal roadmap to SAP S/4HANA.

One of the first S/4 HANA customers - Florida Crystals - is using the Virtustream cloud for their installation.   Another early S/4 HANA customer - La Trobe University in Australia – is using SAP’s HEC for its installation.  Thus, most of the initial S/4 HANA customers (there are over 400) are using the product in a “private” setting rather than a “public” setting. Indeed, I have yet to hear of a customer running one of three S/4 HANA editions in the public cloud.

My assumption is that the existing ecosystem of SIs / hosting partners will quickly move to offer the private scenario to customers.   This trend might not be advantageous to SAP since many of these projects may repeat the sins of past SAP implementations. Den Howlett has already described, one problem regarding S/4 HANA will be moving SIs away from such private environments.

From the SI’s perspective, keeping the customer in an on premise deployment will likely mean a continuation of the expensive implementation models with which SAP’s history is littered. It also means that S/4 HANA on-premises customers only see one upgrade per year. I’d also venture to suggest that even if customers are willing to make the transition, they are less likely to do what SAP wishes and that is simplify their landscapes.

In such private installations of S/4HANA, customers are able to retain their customizations and will probably be able to run most existing applications due to the support of “legacy” APIs via database views.  Notice that I use “be able” instead of “should”.  Fundamentally, S/4 HANA is about innovations that SAP wants to provide to as many customers as possible. The ability of SAP customers to easily / quickly use these new features is directly correlated with the degree to which the involved systems are customized / best practices are used.  Upgrades are less painful if a high-degree of standardization is present.  This necessity is present regardless of whether the customer is moving to a S/4 HANA installation in the SAP Public Cloud or planning to use S/4 HANA in an OnPremise environment.

SAP has a high degree of governance in the environments (public and private) that it hosts. In those environments hosted by other parties, SAP has less governance to assure standardization unless such restrictions are included in licensing / contractual agreements.

Let’s shift to the Public edition.

 Currently, the only SaaS version of S/4HANA is that from SAP.  However, there is no reason why a partner couldn’t duplicate this offer for its customers – even exploiting HANA’s multi-tenancy feature included as part of SP9.  Since the S/4 HANA code base is already present, such partners would just need to apply the associated restrictions (system set-up via guided configurations, no IMGs, common SLA, etc).   If such partner-based SaaS offers also retained the quarterly releases as proposed by SAP for its public cloud offer, then this healthy competition would do much to promote S/4 HANA’s establishment as an innovative platform.

Yet, this competition may not be easy as I just suggested.  SAP has three different editions in the public cloud:

  • SAP S/4HANA, cloud marketing edition – for the marketing line of business
  • SAP S/4HANA, cloud project services edition – for the professional services industry
  • SAP S/4HANA, cloud enterprise edition – for a full ERP scope

A partner such as HP could offer S/4 HANA in their public cloud and compete with SAP’s “cloud enterprise edition”. The two other cloud editions from SAP, however, represent a unique mixture of SAP cloud assets (Hybris, etc.) and are much more difficult to copy.

This move to multiple cloud editions is in line with the new companies such as Infor and NetSuite who are snapping at SAP’s heels. They have discovered that customers want the ability to deploy a more focused cloud solution based on departmental demands rather than an all encompassing solution that is time consuming and expensive to configure. [SOURCE]

You can expect partners to follow this trend and create their own industry-specific S/4 HANA editions. For example, imagine IBM creating insurance-specific mobile apps with Apple associated with a public cloud-based S/4 HANA that has been customized to focus on the needs of insurance companies.  Such S/4 HANA instances could be located in IBM-hosted private cloud but industry-specific standardization might permit a public cloud scenario with the associated lower costs.

The single code-base

The fact that S/4 HANA is based on a single code-base is a critical component in its strategy.   This code-base contains all components ranging from Simple Finance, Simple Logistics (which actually contains a very wide feature set including SD, MM, IM), and Industry applications. How does this single code-base work in private AND public environments?

Specific to the environment, modules are either enabled or disabled via configuration depending on whether they meet the particular characteristics of that environment.


The Public Cloud environment has certain restrictions for example, regarding printing, that must be considered when particular components are running in such settings.

For example, as announced at last week’s Sapphire, there are now 25 Industries which are represented in S/4 HANA. These applications have yet to “reimagined” - ie data simplified and processes altered to reflect this change. Currently, SimpleFinance is the only module which has totally made this transition. The Logistics module is partially finished and should be available in the next release for private settings (ETA 10/2015).

Is being a legacy vendor such a bad thing?

Usually, the identification of a company as a “legacy” vendor with on-premises roots is considered derogatory and, in today’s cloud-hyped world, something to be avoided. Yet, the reality of enterprise software is that hybrid environments combining o-on-premises and cloud assets are to be expected for at least the next decade if not longer (due to security, compliance or other concerns).

SAP recognized this trend early and promoted its ability to meet the associated business requirements. Recently, however, such hybrid scenarios are infrequently depicted. In particular, S/4 HANA discussions rarely include such possibilities. Yet, the common codebase in S/4 HANA enables SAP to optimally support such scenarios since private and public versions share a common semantic root making integration much easier for example, via SAP’s Data Replication Server. I realize that the two environments might be based on different S/4 HANA releases remember that the two environments have different release cycles but integration tools such as HANA Cloud Integration or SAP PI should help alleviate such gaps.  


Ideally, the customer would be able to put those processes that are standardized into the public cloud while retaining differentiating process in private environments where increased customization is permitted /promoted. SAP’s challenge in this area will be to find incentives like lower cost, easier/earlier access to innovation, etc that will motivate customers to move to the public cloud. Due to the use of one code base, the underlying feature set is largely the same – negating this argument as the main motivator for public code usage.

NoteTheoretically, many of the integrated industry solutions might also run in ECC 6.0 rather than in a private S/4 HANA setting since they have not yet been reimagined. SAP determines which applications are simplified based on market forces/customer demands. The focus is currently on the simplification of the core ERP modules. Once finished in this area, SAP will move on to industry applications. Once an industry application has been “simplified” then it is no longer able to run on ECC 6.0.

My take

“Simplification/Run Simple” was a major focus at this year’s Sapphire and I hope this post helps to 'simplify' (sic) the understanding of the S/4 HANA’s architecture.  There are a variety of other very important topics such as motivating customers to migrate to S/4 HANA that are critical for the product’s success which I’ve left to others to examine in more detail.

Some have suggested that there is a certain reluctance in customers to move to the new platform. In my opinion, SAP too often associates the fundamental database-related advantages of HANA such as increased speed with the new offer. To a lesser degree, generic cloud-related benefits like subscription-based pricing, quarterly release cycles, etc are promoted as well. In my opinion, there needs to be more emphasis placed on the process-related benefits of re-imagining the various modules – especially when integrated with the various other cloud/SaaS assets - Ariba, FieldGlass, EmployeeCentral, etc. that SAP owns.

At the Sapphire Now conference, I ended up visiting the booths from Jonathan Becher, SAP's Chief Digital Officer and his team multiple times. I was fascinated by the announcements of the new SAP Store, more important than you might think, Lumira in-app purchases and a new CRM offer called “SAP Digital for Customer Engagement”.

Most intriguing was the associated shift of the purchaser of SAP software towards an end-user who buys SAP software with his credit card and configures the environment without the involvement of corporate IT.

Such environments are not necessarily for individual usage scenarios but also could be made available for a group division, work group, etc.  Combined with S/4 HANA’s public cloud setting, innovative industry-specific micro-applications might be possible that individual LoB buyers could purchase via the new SAPStore and configure on their own. This vision and the role of the HANA Cloud Platform as the extensions-platform is still far from reality but SAP is bringing the necessary pieces into position.

Disclosure: SAP is a premier partner and covered most of the author’s T&E for attending SAPPHIRE Now 2015

Images via Dick Hirsch

A grey colored placeholder image