S/4HANA Extensibility – The new White Paper

This blog is outdated. Please read my new blog here: New Extensibility Guide for S/4HANA is available

Extensibility for S/4HANA is a topic intensively discussed in recent blogs and interviews. It is heavily debated which extensibility capabilities are available for S/4HANA. A comprehensive view on S/4HANA Extensibility can be now found in a white paper that SAP published in 2015 and updated recently: http://go.sap.com/documents/2015/07/2ad59b27-347c-0010-82c7-eda71af511fa.html (new: link to the new version as of September 2018)

Of course, I recommend reading the paper, but as an appetizer, I want to rephrase some of the central points of the paper under the question “What changes”?

What are the changes for the on premise version?

Short answer: Nothing. You can use all extension techniques that you know from the Business Suite. Longer answer: you can use the techniques designed for the cloud and SAP recommends doing so. I will come to this point later, but let us discuss the cloud story first.

What are the changes if you decide to move to the cloud version?

First of all – to avoid confusion – let us recall Bjoern Goerkes answer in the aforementioned discussion: “SAP does not want all customers to be in the Cloud. It’s the market that’s tilting towards Cloud over on-premise in more and more application areas. It’s customers who want to be there with parts of their solutions. Not all customers. And not with all their solutions. But significantly many. That’s why SAP offers choice to customers to the possible extent.”

Now let us come back to the question:

A) SAP offers two flavors of extensibility in the cloud, which are complementary and can be combined:

1. Side-by-side extensibility is the capability to extend the applications by new functionality implemented on HCP – in Java and server-side JavaScript are the current development languages. Developers are the target group; the current tool set is SAP Web IDE (for frontend & backend JavaScript, and HANA development) and Eclipse (Java). What is about ABAP in HCP? Bjoern answered: “From a purely technical perspective, one could of course imagine to put an ABAP stack “into” Hana Cloud Platform (HCP) — it’s all just turing-complete software ; ). But it wouldn’t comply with the cloud operations and lifecycle principles and requirements that HCP as a PaaS requires.”
2. In-app extensibility is the capability of extending the existing S/4 HANA applications which are implemented to the vast majority in ABAP (backend) and JavaScript (Fiori frontend) inside the ABAP stack. The target group is the business expert in the company or from a consulting partner (aka key user, thus also called key user extensibility), the tool set consists of web-based apps for end-to-end creation of extensions, for example custom fields, custom logic, etc. See: The Key User Extensibility Tools of S/4 HANA

B) The lifecycle management requirements dominate the extension process

In the cloud version, SAP defines the tact for software updates. For example, SAP ships a major update every quarter, regular fixes every two weeks and urgent fixes asap (just to give some example timelines from existing cloud products). For extensions, this means:

1. Extensibility artifacts must never block an SAP software update.
2. Extensibility artifacts must continue to work after an SAP software update without manual work; in other words: SAP software updates do not depend on the reaction by the customer.

All extensibility capabilities in the cloud must fulfill these requirements. This means, for example, that modifications to SAP objects are forbidden.

C) As a consequence of point B, extensibility artifacts use released, stable SAP extension points and APIs only. This has to be enforced by checks on customer side. On SAP side, checks must prevent incompatible changes to objects that are marked as extensible and have been delivered once. A deprecation mechanism must be available.

Points B and C are valid for side-by-side and for in-app extensibility.  In the on premise world, typically the extensibility requirements have clear priority – lifecycle management has to follow. In the cloud model, the relationship is just the opposite. Lifecycle requirements comes first, it dictates the limits of extensibility. (Side note: the SAP HEC offering does not follow this cloud paradigm, but the S/4 HANA cloud does.)

Only a limited set of extensibility use cases and APIs are supported for the first S/4HANA cloud version. However, there will be a high demand from customers for additional extensibility use cases. The existing extensibility concept of S/4HANA proposes that a SAP shared service center may fulfill additional requirements as long as they are not available in the standard extensibility tools.

What changes for the on premise version (cont.)?

As mentioned, SAP recommends that you use the techniques designed for the cloud also on premise (see for example Bernd Leukerts answer in the aforementioned interview). Why? Going forward in this direction, on premise customers can benefit from the tools that are designed for the cloud to reduce their TCO. Why now? The migration to S/4HANA means that you anyway have to touch your code (see the article featuring Rudolf Hois http://www.news-sap.com/users-guide-journey-sap-s4hana-six-steps/ for a comprehensive overview). So it is a good time to change to state-of-the-art extensibility techniques in this project!