As most of you certainly knew SAP published a whitepaper on the extensibility options in S/4HANA in the mid of 2015 (S/4HANA Extensibility – The new White Paper). Within this paper, the basic concepts and options for the extensibility in S/4HANA for partners and customers have been presented.
Now one year later a new version of the white paper was published (announced in a comment on the above-mentioned blog). A year is quite some time and one might think that a lot has happened in between which will influence the new version of the paper that serves as the first entry point when it comes to the extensibility of S/4HANA.
Obviously, there are some changes, but not in a direction I would have expected them and I want to highlight the changes in this blog (the pdf does not offer a change history, so you really have to compare the versions 😉 )
What about Managed Extensibility?
The first very obvious change is the number of pages: they have been reduced. For me, that was a surprise as I would have expected an increase due to the experiences that have been gathered with the options over the last year, but this is not the case. Taking a closer look at the document the most drastic change happened to the section on Managed Extensibility (= coded extensibility for SAP S/4HANA cloud enterprise edition to develop tightly integrated ABAP add-ons). This section (and all relevant references e. g. in the lifecycle sections) vanished from the document. However, it is still mentioned in the section on the “Big Picture”.
Here one example based on the overview picture in the guideline in the 2015 version …
… and in the 2016 version
Remark: The picture might make you guess that the Key User Extensibility has newly become part of the on-premise flavor of S/4HANA in the 2016 version. This was already the case in the 2015 version of the paper (and it was in the 1511 onPrem version of S/4HANA). This picture was just consistently changed as well as some further references in the paper.
One could only make guesses why this was removed from the new version. Perhaps no commercial success (yes you had to pay for that), perhaps no customer demand, perhaps too difficult to handle in the cloud. Whatever reason caused this removal, the consequence is that the extensibility options in the cloud seem to be reduced and this has to be considered when thinking about a move to the cloud.
What about The Lifecycle of Combined Extensibility Options?
The 2015 version of the paper dedicated a whole section on the topic of lifecycle management aspects of combined extensibility options. In this section, some specific scenarios have been discussed when it comes to the lifecycle management of different extensibility options that are used in parallel. This section is omitted in the new version. Although this section was not well structured in the 2015 version it offered some useful information about real-life extension scenarios. Here it is really hard to guess what caused this change.
When taking a closer look at the document you will see that some additional changes have been made, that are not that obvious at a first glance. The first one applies to the artefacts that can be whitelisted in order to access the system from outside: the option “IDocs from SOAP” is no longer on the list as you can see from the following screenshots.
This is the section from the 2015 version
And here comes the shorter section of the 2016 version
The remaining options for the whitelisting remain unchanged.
Another small change can be found in the section “Lifecycle Management for Key User Extensibility in the Cloud”. Here the principals that a solution has to adhere in order to support the extensibility in the cloud comprise custom artefacts being clash-free. This means that in order to support extensions stemming from different parties they have to have some kind of namespace-layering i. e. the sequence shall the extensions are executed has to be defined (comparable to the sorting of BAdI implementations when a BAdI can have multiple implementations). In the 2015 version, the restriction was stated that this layering is not in scope in Q1-Q3 of 2015. This restriction got extended for the complete year 2016, so this layering will not be supported within this year. This definitely has some impact on partner solution that could/should be made available in the S/4HANA cloud edition
I was quite happy to see that a new version of this central whitepaper was published, but unfortunately not too much changed within the last year. Being a positive person one can state that the extension options are quite stable which is true on a high-level. Nevertheless, I would have expected more changes due the on-going experience with the solution and as a consequence with these options.
In addition, I would have hoped that some more word would be dedicated to partner solutions. It is obvious that partners can use the extension options offered by S/4 as a customer can. But this is definitely not sufficient for partner add-ons. One important aspect is the layering of the solutions (here at least we know that this is not supported in the cloud). But an even more important aspect is that if I want to build an add-on on S/4HANA I also want to offer the extensibility option to my customer e. g. my add-on shall also offer the option of key-user extensibility. This question remains unanswered also in the new version. So let’s see if the next version (or other papers) will bring more answers on these topics.