As a developer that has spent far-too-many days in the past few weeks alone – manually – applying SAP Notes to an On-Premise S/4H system – only – for SAP’s ‘Document and Reporting Compliance’ (DRC) solution, I am now entirely convinced: SAP’s patch-delivery framework is at best obsolete; at worst broken. Most traditional ERP modules have no need for any more than quarterly updates, but in the case of SAP’s DRC solution – amongst other modern equivalents – we now see new SAP Notes appearing on an almost daily basis (not including security patches). Is this sustainable, even if we leave aside such bothersome notions as how such constant patching can be efficiently tested and deployed using today's practices?
It goes without saying that SAP’s response will be that everyone simply needs to move across to ‘S/4HANA Public Cloud’ to ‘solve’ this problem, but it also goes without saying that this transition is absolutely not going to be finished in the next 10 years; even if it occurs in part. In any case, whilst moving to ‘S/4HANA Public Cloud’ would indeed ensure the regular application of SAP Notes – with no client-specific non-regression testing possible – this is only because SAP’s customers would now be paying SAP employees to apply those Notes, instead of paying their own resources to apply the same: hardly a revolutionary solution, and not even an approach that is sure to save them any money once they consider the budget needed to completely re-develop ALL of their legacy ABAP developments using the new (#EDA) ‘Side-by-Side Extension’ approach (at which point in time they might even ask why they would bother to re-develop anything using ABAP at all).
What is instead needed from SAP today is a revolutionary approach, a paradigm shift towards ‘Cloud Compute’. Offerings such as SAP’s Document and Reporting Compliance (DRC) can absolutely NOT be updated or patched in the traditional manner – on a sustainable basis – by SAP’s On-Premise (or even Private Cloud) customers: the vast majority of its customers today, and therefore for many years to come. Whilst those customers absolutely must be able to remain – and will very often choose to remain – On-Premise/Private Cloud, any such SAP offerings demanding high-frequency updates must – of necessity – themselves be moved to a shared, Public Cloud model: but how to do so?
Although SAP clearly has no answer to this problematic today – other than insisting upon the complete surrender of client-specific non-regression testing, along with almost all pre-existing custom developments – as someone that has worked reasonably often in the field of Serverless technologies – and by that I am referring primarily to the original ‘Function-as-a-Service’ (FaaS) idea – I am fortunately well placed to suggest to SAP just such a revolution: ‘Cloud Compute’.
Unlike SAP’s S/4HANA Public Cloud offering (which represents in my own personal opinion, little more than moving your On-Prem SAP servers to new ‘Green Field’ S/4H servers hosted and patched by someone else -> but where you also lose most of your prior development investments), what we see in the above diagram is that SAP could start provisioning – certain – offerings ‘as-a-Service’. For example, all your DRC compute work could be run on a Public Cloud – ERP – application server that is patched regularly by SAP (once, for all clients), to where all compute workloads could be sent by your On-Premise/Private Cloud application servers – for certain offerings. It is clearly impossible to imagine SAP ever completely rewriting any of their current offerings in another ‘Cloud-native’ programming language, so it goes without saying that their existing solutions will need to remain fully developed and maintained in ABAP: but these offerings should now be provisioned via a Public Cloud model => 'ERP-as-a-Service' ('ERP-FaaS' more specifically).
Such an approach would in no way hurt SAP’s desire to see all of its existing customers move to a ‘Clean-Core’ approach – running upon its S/4HANA Public Cloud infrastructure – but quite the opposite. Such an architecture would enable its customers to transition to a ‘Clean-Core’ future – one SAP offering at a time – keeping only their heavily customized modules On-Premise in the initial years. This would enable them to migrate in a painless fashion over a 5-15 year timeframe, in a manner that would be 100% under their own control.
A fairly important bonus for them – which far exceeds anything that S/4HANA Public Cloud proposes today – would be the possibility of ‘Blue/Green Deployments’ whereby a limited number of their available ‘Cloud Compute’ servers would be updated to the highest patch level by SAP – becoming their ‘Green Servers’ – but whereby in the case of any defects or regressions being detected by the customer, they could very easily and quickly demand SAP to switch back to the previous patch level: the alternative ‘Blue Servers’ that had just been suspended.
What’s more, is that such an approach would be 100 % compatible with a ‘Canary Deployment’ approach, where Blue and Green servers would be running simultaneously, but where all Key Users (and any other volunteers) would be consistently logged – only – onto the ‘Green’ server(s). In this scenario, SAP could even automate the full switch from Blue to Green once a certain percentage of pre-identified key businesses processes had been successfully executed on the Green server(s); or even quite simply after a certain number of days.
It is important to make the point that SAP’s ‘Core Data Services’ (CDS) Views should also be hosted by the Cloud ‘Compute Servers’ rather than the ‘Persistence Server’: SAP ERP ‘Business Logic’ today is indeed the sum of ABAP Code + CDS Views. These are no more than read-only views on the underlying ERP Tables, and if they serve any purpose at all, it is clearly to act as a ‘Data-Access Layer’ sitting between external systems and the underlying DB Tables. Such an approach would likewise enable the Canary Deployment of CDS Views in order to minimize operational risks, and it’s worth making the point that the underlying DB Tables almost never change.
On this subject, one of the most recent Notes that I was required to apply was SAP DRC Note 3386817 of 06/11/2023: “the Customer/Supplier Balance amounts are incorrect in the file”. Hopefully all DRC Romania customers have already noticed and applied this Note in the past 2 weeks, as it strikes me as reasonably important (leaving aside the other ‘High Priority’ Notes that have appeared regularly in my Inbox over the past few weeks). It makes changes to several CDS Views to correct “Customer/Supplier Balance amounts”; but no changes whatsoever to the underlying DB Tables… What this proves is that ‘Bugs’ can exist not only in (ABAP) Code, but also within CDS Views – although obviously not within DB tables themselves – for which reason CDS Views are also important candidates for Canary Deployment.
It was with great pleasure that I noticed in the past few days that SAP has stated to implement the ‘Requested’ (R7D) Event Pattern that I first wrote about in April 2021: https://camhunt.medium.com/requested-event-pattern-cf354deff906. Hopefully it wont take another 2.5 years for SAP to provide their customers with the Canary (and/or Blue/Green) Deployments that have come to be expected from other software editors of standing, including even modest in-house development teams.
It goes without saying that SAP’s response will be that everyone simply needs to move across to ‘S/4HANA Public Cloud’ to ‘solve’ this problem, but it also goes without saying that this transition is absolutely not going to be finished in the next 10 years; even if it occurs in part. In any case, whilst moving to ‘S/4HANA Public Cloud’ would indeed ensure the regular application of SAP Notes – with no client-specific non-regression testing possible – this is only because SAP’s customers would now be paying SAP employees to apply those Notes, instead of paying their own resources to apply the same: hardly a revolutionary solution, and not even an approach that is sure to save them any money once they consider the budget needed to completely re-develop ALL of their legacy ABAP developments using the new (#EDA) ‘Side-by-Side Extension’ approach (at which point in time they might even ask why they would bother to re-develop anything using ABAP at all).
What is instead needed from SAP today is a revolutionary approach, a paradigm shift towards ‘Cloud Compute’. Offerings such as SAP’s Document and Reporting Compliance (DRC) can absolutely NOT be updated or patched in the traditional manner – on a sustainable basis – by SAP’s On-Premise (or even Private Cloud) customers: the vast majority of its customers today, and therefore for many years to come. Whilst those customers absolutely must be able to remain – and will very often choose to remain – On-Premise/Private Cloud, any such SAP offerings demanding high-frequency updates must – of necessity – themselves be moved to a shared, Public Cloud model: but how to do so?
Although SAP clearly has no answer to this problematic today – other than insisting upon the complete surrender of client-specific non-regression testing, along with almost all pre-existing custom developments – as someone that has worked reasonably often in the field of Serverless technologies – and by that I am referring primarily to the original ‘Function-as-a-Service’ (FaaS) idea – I am fortunately well placed to suggest to SAP just such a revolution: ‘Cloud Compute’.
Unlike SAP’s S/4HANA Public Cloud offering (which represents in my own personal opinion, little more than moving your On-Prem SAP servers to new ‘Green Field’ S/4H servers hosted and patched by someone else -> but where you also lose most of your prior development investments), what we see in the above diagram is that SAP could start provisioning – certain – offerings ‘as-a-Service’. For example, all your DRC compute work could be run on a Public Cloud – ERP – application server that is patched regularly by SAP (once, for all clients), to where all compute workloads could be sent by your On-Premise/Private Cloud application servers – for certain offerings. It is clearly impossible to imagine SAP ever completely rewriting any of their current offerings in another ‘Cloud-native’ programming language, so it goes without saying that their existing solutions will need to remain fully developed and maintained in ABAP: but these offerings should now be provisioned via a Public Cloud model => 'ERP-as-a-Service' ('ERP-FaaS' more specifically).
Such an approach would in no way hurt SAP’s desire to see all of its existing customers move to a ‘Clean-Core’ approach – running upon its S/4HANA Public Cloud infrastructure – but quite the opposite. Such an architecture would enable its customers to transition to a ‘Clean-Core’ future – one SAP offering at a time – keeping only their heavily customized modules On-Premise in the initial years. This would enable them to migrate in a painless fashion over a 5-15 year timeframe, in a manner that would be 100% under their own control.
A fairly important bonus for them – which far exceeds anything that S/4HANA Public Cloud proposes today – would be the possibility of ‘Blue/Green Deployments’ whereby a limited number of their available ‘Cloud Compute’ servers would be updated to the highest patch level by SAP – becoming their ‘Green Servers’ – but whereby in the case of any defects or regressions being detected by the customer, they could very easily and quickly demand SAP to switch back to the previous patch level: the alternative ‘Blue Servers’ that had just been suspended.
What’s more, is that such an approach would be 100 % compatible with a ‘Canary Deployment’ approach, where Blue and Green servers would be running simultaneously, but where all Key Users (and any other volunteers) would be consistently logged – only – onto the ‘Green’ server(s). In this scenario, SAP could even automate the full switch from Blue to Green once a certain percentage of pre-identified key businesses processes had been successfully executed on the Green server(s); or even quite simply after a certain number of days.
It is important to make the point that SAP’s ‘Core Data Services’ (CDS) Views should also be hosted by the Cloud ‘Compute Servers’ rather than the ‘Persistence Server’: SAP ERP ‘Business Logic’ today is indeed the sum of ABAP Code + CDS Views. These are no more than read-only views on the underlying ERP Tables, and if they serve any purpose at all, it is clearly to act as a ‘Data-Access Layer’ sitting between external systems and the underlying DB Tables. Such an approach would likewise enable the Canary Deployment of CDS Views in order to minimize operational risks, and it’s worth making the point that the underlying DB Tables almost never change.
On this subject, one of the most recent Notes that I was required to apply was SAP DRC Note 3386817 of 06/11/2023: “the Customer/Supplier Balance amounts are incorrect in the file”. Hopefully all DRC Romania customers have already noticed and applied this Note in the past 2 weeks, as it strikes me as reasonably important (leaving aside the other ‘High Priority’ Notes that have appeared regularly in my Inbox over the past few weeks). It makes changes to several CDS Views to correct “Customer/Supplier Balance amounts”; but no changes whatsoever to the underlying DB Tables… What this proves is that ‘Bugs’ can exist not only in (ABAP) Code, but also within CDS Views – although obviously not within DB tables themselves – for which reason CDS Views are also important candidates for Canary Deployment.
It was with great pleasure that I noticed in the past few days that SAP has stated to implement the ‘Requested’ (R7D) Event Pattern that I first wrote about in April 2021: https://camhunt.medium.com/requested-event-pattern-cf354deff906. Hopefully it wont take another 2.5 years for SAP to provide their customers with the Canary (and/or Blue/Green) Deployments that have come to be expected from other software editors of standing, including even modest in-house development teams.
- SAP Managed Tags:
