Extensibility for S/4HANA is a topic intensively discussed in recent blogs and interviews, see for example the interview by Bernd Leukert (http://www.isreport.de/news/sap-technikvorstand-im-exklusiv-interview/ , in German) and the discussion under the following blog post(http://scn.sap.com/community/abap/blog/2015/05/29/i-just-heard-sap-are-trying-to-kill-abap-once-again#comment-591915) and the following posts by Bjoern Goerke). 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.” (http://scn.sap.com/community/abap/blog/2015/05/29/i-just-heard-sap-are-trying-to-kill-abap-once-again#comment-592078 )
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:
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:
- Extensibility artifacts must never block an SAP software update.
- 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!