SAP fist proposed the use of ‘Side-by-Side Extensions’ in July 2015, with the publication of its white paper on “S/4HANA Extensibility”. What is most interesting to note about discussions on the topic in those early days, is that SAP only ever mentioned the use of APIs to read data from, or to change data in an underlying S/4 system. They failed to discuss the fact that Side-by-Side Extension applications will sometimes need to be triggered by S/4 itself, for outbound logic flows. More recently however, we are belatedly informed by SAP that ‘Business Events’ triggered within S/4 (e.g. ‘PurchaseOrder.Created’) can and should be used to trigger any necessary ‘Side-by-Side Extensions’. It should be noted in this context, that SAP’s ‘Event Enablement’ Add-on was not released for S/4HANA until June 2021.
In other words, in the early days of ‘Side-by-Side Extensibility’ discussions, SAP appears to have been completely unaware that what it would eventually propose from 2021, was (vanilla) ‘Event-Driven Architecture’ (EDA). EDA remains today the best architecture we have to build ‘Distributed Applications’: single Applications that are composed of a number of distinct ‘Software Components’ – often running on distinct platforms, maintained by different teams, and written in different programming languages. In any well-designed ‘Distributed Application’, significant changes in (business) state will be published as Events (e.g. ‘PurchaseOrder.Created’) by the owner ‘Software Component’, and any other Software Components interested in those Events will be informed of them by a Broker, and will execute the desired logic whenever those Events occur: exactly as per ‘Side-by-Side Extension’ applications today.
As you can perhaps see from the above schematics, SAP’s latest idea is apparently to destroy the ever-growing EDA movement, and to instead counsel developers to make extensions directly upon a single ‘Stack’ (by embedding a second, identical ‘Steampunk’ ABAP Application Server in the same Stack as the S/4 ABAP Server itself). By doing so, we are assured that we will once again be able to build “tightly-coupled extensions”, and will no longer be restricted to “loosely-coupled extensions” that are built using (asynchronous) events. As such, SAP’s big new idea is to make the (synchronous) Monolith great again.
In an official video on Embedded Steampunk, we are informed by Boris Gebhardt of SAP that “We had really an issue that for tightly-coupled extensions, we had only the Key-User Low-Code/No-Code offering, so if you really have the need ... for a tightly-coupled extension which can't run Side-by-Side, then there was a gap in the Cloud. And that is now closed by Embedded Steampunk”. Boris goes on it the video to inform us that “The scope which we [will] try to cover with APIs and BAdIs is the S/4HANA Cloud scope, so don't expect that you will now get for each of the On-Premise-only modules your API. We will be focused on the Core ERP S/4HANA Cloud scope”. Not only does this mean that Side-by-Side Extensions will remain entirely necessary well into the future for all of those SAP modules not falling into the “Core ERP S/4HANA Cloud scope”, it also exposes the “tightly-coupled extensions” argument as no more than a marketing talking-point. If there really is such a beast as “a tightly-coupled extension which can't run Side-by-Side”, why on Earth can they only be found in the world of “S/4HANA Cloud”?
More obviously, the entire foundation of SAP’s – rather recent – UI5 technology is ‘loosely-coupled’ (i.e. ‘asynchronous’): (a) the user launches an App in their local browser (on their PC ‘Stack’), (b) they are redirected to and authenticated by BTP’s ‘Cloud Identity Services’, (c) the Front-end JavaScript code is read from the UI5 Repository (which will most often today be hosted on either their Gateway Hub or BTP ‘Stack’) via 'Asynchronous Module Definition' (AMD) APIs, (d) an – asynchronous – OData API call is made to the Back-end ABAP code, and (e) the data is eventually returned to the Browser, and displayed to the user. If ‘loosely-coupled extensions’ are truly so inadequate, the entire foundation of SAP’s UI5 is built upon sand.
A second talking-point can be easily spotted in a September 2021 Blog by Harald Kuck, also of SAP. In his Blog, Harald informs us that “Extending the ERP core Side-by-Side is great for many use cases. But not for all of them. Think about custom code that needs to run close to the app that is being extended. Within the same context, calling ‘Local APIs’, e.g., to avoid huge data replication, or to run within the same logical unit of work (database LUW)” – just like the Monolithic applications of yesteryear. I’m sorry Harald, “huge data replication”? SAP suggested as far back as 2015 the use of HTTP-based API calls when making Side-by-Side Extensions, in order to recover the necessary data to execute the distributed logic. At that point in time, the term “Local APIs” (or ‘Whitelisted APIs’ for that matter) didn’t even exist. What’s more, regardless of what type of API you call to read the necessary data, and you can call it what you will, there is in no case any need for “data replication” (“huge” or otherwise). Had there been, SAP might not have suggested the use of (External?) APIs by Side-by-Side Extensions in 2015, and it would probably have mentioned “data replication” constraints since that time.
For a third talking-point, we read in the same Blog just mentioned, that “With Embedded Steampunk in S/4HANA On-Prem ... we want to support the transformation of these systems to a cleaner core”. This is another talking-point that can be readily dismissed with a simple question: If you want to keep you core clean, should you (a) add a second, redundant AS ABAP onto your S/4 Stack (“Internally, S/4HANA Cloud and Steampunk share the same ABAP Platform code line”), or (b) have S/4 publish all of its Business Events to an external broker, and have any interested subscribers perform the desired (distributed) logic on a completely separate Stack, using any vendor of their choice?
For a fourth and final talking-point, we hear from Karl Kessler in a more recent video from 17 February 2022, that the reason SAP thinks “Embedded Steampunk is so powerful” is because “now, inside the S/4HANA Cloud system, you can debug your code, and that was not possible with Key User Extensibility”: with ‘In-App Extensions’. Before Embedded Steampunk, “there was no single stepping through the code” when debugging BAdIs, we are reminded. Interestingly, Karl makes no mention whatsoever of ‘Side-by-Side Extensions’ when discussing “the biggest difference by far” with Embedded Steampunk, as these must always be built – and debugged – on entirely separate platforms: debugging of these extensions has therefore been possible since the very beginning. In other words, if you had built ‘Side-by-Side Extensions’ in the past rather than ‘In-App Extensions’, then debugging was never an issue that you ever would have confronted. Add to this another comment by Harald Kuck from the earlier video that was already mentioned, and you may even wonder why we’re talking about ‘Embedded Steampunk’ at all: “Most of our customers – or almost all of them – are still sitting On-Prem”.
I believe that ‘Embedded Steampunk’ should be called out for what it is: the abandonment by SAP of its declared embrace of ‘Event-Driven Architecture’ – EDA’s jettison by an ERP empire that has grown uncomfortable with their customers using any platform of their choosing to implement extensions to their Core ERP. Having said that, I do not believe that those of us backing the EDA revolution have much to worry about. As Harald himself writes, “there are two risks for SAP. Number one, we can be too conservative and stick for too long with outdated concepts that are no longer required”. Indeed, the Monolithic ERP is already being eclipsed by the ‘Distributed Planning System’ (see my earlier Blog: The ERP is Dead. Long live the ‘Distributed Planning System) – by Distributed Applications built using ‘Event-Driven Architecture’.
SOURCES:
Embedded Steampunk
https://community.sap.com/media/hands-on-sap-dev/embedded-steampunk
Steampunk is going all-in
https://blogs.sap.com/2021/09/30/steampunk-is-going-all-in/
Delve Into the Latest on ABAP | SAP TechEd in 2021
https://www.youtube.com/watch?v=pLrcjra4Svs
In other words, in the early days of ‘Side-by-Side Extensibility’ discussions, SAP appears to have been completely unaware that what it would eventually propose from 2021, was (vanilla) ‘Event-Driven Architecture’ (EDA). EDA remains today the best architecture we have to build ‘Distributed Applications’: single Applications that are composed of a number of distinct ‘Software Components’ – often running on distinct platforms, maintained by different teams, and written in different programming languages. In any well-designed ‘Distributed Application’, significant changes in (business) state will be published as Events (e.g. ‘PurchaseOrder.Created’) by the owner ‘Software Component’, and any other Software Components interested in those Events will be informed of them by a Broker, and will execute the desired logic whenever those Events occur: exactly as per ‘Side-by-Side Extension’ applications today.
As you can perhaps see from the above schematics, SAP’s latest idea is apparently to destroy the ever-growing EDA movement, and to instead counsel developers to make extensions directly upon a single ‘Stack’ (by embedding a second, identical ‘Steampunk’ ABAP Application Server in the same Stack as the S/4 ABAP Server itself). By doing so, we are assured that we will once again be able to build “tightly-coupled extensions”, and will no longer be restricted to “loosely-coupled extensions” that are built using (asynchronous) events. As such, SAP’s big new idea is to make the (synchronous) Monolith great again.
In an official video on Embedded Steampunk, we are informed by Boris Gebhardt of SAP that “We had really an issue that for tightly-coupled extensions, we had only the Key-User Low-Code/No-Code offering, so if you really have the need ... for a tightly-coupled extension which can't run Side-by-Side, then there was a gap in the Cloud. And that is now closed by Embedded Steampunk”. Boris goes on it the video to inform us that “The scope which we [will] try to cover with APIs and BAdIs is the S/4HANA Cloud scope, so don't expect that you will now get for each of the On-Premise-only modules your API. We will be focused on the Core ERP S/4HANA Cloud scope”. Not only does this mean that Side-by-Side Extensions will remain entirely necessary well into the future for all of those SAP modules not falling into the “Core ERP S/4HANA Cloud scope”, it also exposes the “tightly-coupled extensions” argument as no more than a marketing talking-point. If there really is such a beast as “a tightly-coupled extension which can't run Side-by-Side”, why on Earth can they only be found in the world of “S/4HANA Cloud”?
More obviously, the entire foundation of SAP’s – rather recent – UI5 technology is ‘loosely-coupled’ (i.e. ‘asynchronous’): (a) the user launches an App in their local browser (on their PC ‘Stack’), (b) they are redirected to and authenticated by BTP’s ‘Cloud Identity Services’, (c) the Front-end JavaScript code is read from the UI5 Repository (which will most often today be hosted on either their Gateway Hub or BTP ‘Stack’) via 'Asynchronous Module Definition' (AMD) APIs, (d) an – asynchronous – OData API call is made to the Back-end ABAP code, and (e) the data is eventually returned to the Browser, and displayed to the user. If ‘loosely-coupled extensions’ are truly so inadequate, the entire foundation of SAP’s UI5 is built upon sand.
A second talking-point can be easily spotted in a September 2021 Blog by Harald Kuck, also of SAP. In his Blog, Harald informs us that “Extending the ERP core Side-by-Side is great for many use cases. But not for all of them. Think about custom code that needs to run close to the app that is being extended. Within the same context, calling ‘Local APIs’, e.g., to avoid huge data replication, or to run within the same logical unit of work (database LUW)” – just like the Monolithic applications of yesteryear. I’m sorry Harald, “huge data replication”? SAP suggested as far back as 2015 the use of HTTP-based API calls when making Side-by-Side Extensions, in order to recover the necessary data to execute the distributed logic. At that point in time, the term “Local APIs” (or ‘Whitelisted APIs’ for that matter) didn’t even exist. What’s more, regardless of what type of API you call to read the necessary data, and you can call it what you will, there is in no case any need for “data replication” (“huge” or otherwise). Had there been, SAP might not have suggested the use of (External?) APIs by Side-by-Side Extensions in 2015, and it would probably have mentioned “data replication” constraints since that time.
For a third talking-point, we read in the same Blog just mentioned, that “With Embedded Steampunk in S/4HANA On-Prem ... we want to support the transformation of these systems to a cleaner core”. This is another talking-point that can be readily dismissed with a simple question: If you want to keep you core clean, should you (a) add a second, redundant AS ABAP onto your S/4 Stack (“Internally, S/4HANA Cloud and Steampunk share the same ABAP Platform code line”), or (b) have S/4 publish all of its Business Events to an external broker, and have any interested subscribers perform the desired (distributed) logic on a completely separate Stack, using any vendor of their choice?
For a fourth and final talking-point, we hear from Karl Kessler in a more recent video from 17 February 2022, that the reason SAP thinks “Embedded Steampunk is so powerful” is because “now, inside the S/4HANA Cloud system, you can debug your code, and that was not possible with Key User Extensibility”: with ‘In-App Extensions’. Before Embedded Steampunk, “there was no single stepping through the code” when debugging BAdIs, we are reminded. Interestingly, Karl makes no mention whatsoever of ‘Side-by-Side Extensions’ when discussing “the biggest difference by far” with Embedded Steampunk, as these must always be built – and debugged – on entirely separate platforms: debugging of these extensions has therefore been possible since the very beginning. In other words, if you had built ‘Side-by-Side Extensions’ in the past rather than ‘In-App Extensions’, then debugging was never an issue that you ever would have confronted. Add to this another comment by Harald Kuck from the earlier video that was already mentioned, and you may even wonder why we’re talking about ‘Embedded Steampunk’ at all: “Most of our customers – or almost all of them – are still sitting On-Prem”.
I believe that ‘Embedded Steampunk’ should be called out for what it is: the abandonment by SAP of its declared embrace of ‘Event-Driven Architecture’ – EDA’s jettison by an ERP empire that has grown uncomfortable with their customers using any platform of their choosing to implement extensions to their Core ERP. Having said that, I do not believe that those of us backing the EDA revolution have much to worry about. As Harald himself writes, “there are two risks for SAP. Number one, we can be too conservative and stick for too long with outdated concepts that are no longer required”. Indeed, the Monolithic ERP is already being eclipsed by the ‘Distributed Planning System’ (see my earlier Blog: The ERP is Dead. Long live the ‘Distributed Planning System) – by Distributed Applications built using ‘Event-Driven Architecture’.
SOURCES:
Embedded Steampunk
https://community.sap.com/media/hands-on-sap-dev/embedded-steampunk
Steampunk is going all-in
https://blogs.sap.com/2021/09/30/steampunk-is-going-all-in/
Delve Into the Latest on ABAP | SAP TechEd in 2021
https://www.youtube.com/watch?v=pLrcjra4Svs
- SAP Managed Tags:
3 Comments
