Having only recently watched the TechEd Keynote Speech of December 2020, I was surprised to finally have confirmed what I have long suspected: SAP doesn’t sell an ERP today. The good news, we are told, is that SAP is working hard to resurrect the same sort of ERP that brought it to global fame in the 1980’s. We hear from SAP’s Chief Technology Officer, Jürgen Müller, that “SAP-to-SAP integration … has become even easier. And the best is that default SAP-to-SAP integration flows actually even come for free”.
As someone that started their career in the 1990’s with SAP R/2, at a time when SAP was selling an ERP, the concept of “SAP-to-SAP integration” makes little-to-no sense. The idea that “SAP-to-SAP integration flows actually even come for free” makes even less sense. The very reason that customers purchased an ERP licence from SAP between 1980 and 2010, was not because “SAP-to-SAP integration” between its distinct ‘Modules’ was a useful product offering: it was the product. Those very same customers had typically been badly burnt by the messy and costly integration of heterogeneous systems; exactly what those implementing an ERP wanted to eliminate. With the ERP, the new era of the ‘Golden Record’ was ushered in.
Jürgen informs us in the 2020 Keynote that “With the SAP One Domain Model, and SAP Cloud Platform ‘Master Data Integration’ services, integration happens holistically and out-of-the-box”; just like it did in the 1980’s (without SAP Cloud Platform ‘Master Data Integration’ services, and without any need for the SAP ‘One Domain Model’ which was referred to at the time, quite simply, as the SAP ‘ERP’).
The SAP Chief Product Expert, Rui Nogueira, reassures us of the same: “the news is that the integration between the solutions of the Intelligent Suite comes now out-of-the-box for the first business objects like the ‘Workforce Person’… Once configured, the newly available SAP Cloud Platform ‘Master Data Integration’ service provides out-of-the-box synchronization for those objects between all solutions of the Intelligent Suite”. As such, it would appear that there is an important caveat to the latest news: “integration … of the Intelligent Suite comes now out-of-the-box for the first business objects” only. And what if you’re using different business objects? You’ll probably need to wait a little longer for the full renaissance of the ERP; and longer again should SAP ever acquire an additional software vendor (which seems reasonably likely).
Given all of this, it would appear that after paying for your standard S/4HANA licence today, you ought to then buy an SAP Cloud Platform (SCP) licence should you wish to have a landscape that resembles an ERP – “for the first business objects” – even if you are an ‘On-Prem’ S/4HANA customer. Then, as Rui demonstrates, you should probably also purchase an SAP Cloud Platform Integration (SCI) licence in order to correctly integrate with your existing third-party systems, via SAP Enterprise Messaging. In Rui’s demo, we’re shown how “SAP Enterprise Messaging subscribes to the Event in SuccessFactors for the newly created employee. Next, you create a ‘Process Flow’ in SAP Cloud Platform Integration for … third-party HR integration”. The good news is that “connectivity to the third-party systems is backed by the SAP Open Connectors”: by SAP-maintained APIs.
From these words alone, it becomes clear that SAP is quite unsure of what Events, and in particular Event-Driven Architectures, actually are. If “connectivity to the third-party systems is backed by the SAP Open Connectors” – by APIs – then connectivity is not Event-Driven, but API-based (i.e. SOA). In a true Event-Driven Architecture (EDA), Events are or course raised, but the Event source has no idea as to who is, or even if there is a target. That’s why EDA enables the most pure form of ‘Distributed Application’ that exists. The minute that APIs – used to connect known endpoints via canonical signatures – become the basis of an architecture, it is no longer Event-Driven. This is something that I expound upon in my earlier Blog, APIs: our flawed legacy from 1960’s thinking.
Cecilia Huergo, a Senior Product Specialist at SAP, likewise demonstrates in the Keynote a new Side-by-Side Extension for an ECC system, hosted on SCP. Somewhat astonishingly, we’re told that “To ensure close integration between the existing system and my extension, I’ll be using Event-Driven Architecture”. Yet “close integration” is the very antithesis of Event-Driven Architectures. As true EDAs – which can only ever be used to build ‘Distributed Applications’ – are wholly asynchronous, they consequently represent the exact opposite of “close integration”. For more details on this, consider my Blog, From SOA to Macroservices.
In her demo, Cecilia uses the new SAP NetWeaver Add-On ‘Event Enablement’ to send Events from an ECC system to the Enterprise Messaging Bus on SCP. However, we are told that “Since those Messages only contain identifiers, we’ll need to set up OData services to fetch the other required fields” of the relevant Entities. So, not only does the new SAP-flavour of EDAs completely miss the point of ‘Event-Driven Architectures’, it even fails to hit the mark on what an ‘Event’ is. Let’s imagine that two ‘SAP Events’ are received by the same target system in the same hour for a changed Purchase Order, but that system only processes those events hourly owing to resource constraints. In fact, the first ‘SAP Event’ is completely lost. We can guess that something happened to “the other required fields” owing to one of the two users that made changes in the last hour, but have no idea exactly what was changed, or by whom. And what if the same ‘SAP Event’ is sent to three distinct target systems – as can be expected in an EDA – and each of those systems perform their OData Callback to the source system at different times? Each target system could potentially see the same Purchase Order in three different States, upon the basis of the same ‘SAP Event’! Such a notion of an ‘Event’ – completely decoupled from the change in State that the Event affected – deviates so thoroughly from standard usage of the term that it needs a completely new name.
Later in the Keynote Take Aways we are reminded by Jürgen that: “We talked about Event-Driven Architectures, now not just for S/4HANA and SuccessFactors and others, but also for ECC”. At this point in the Keynote, SAP’s EDA-stewardship failure became complete. EDAs – a modern Architecture for enabling the Distributed Application – don’t have any notion of distinct ‘applications’ – they deliver a singular ‘Distributed Application’. To say that EDAs are now available “not just for S/4HANA and SuccessFactors and others, but also for ECC”, completely misses the point of what a Distributed Application actually is: a holistic Application, Distributed across multiple software components. No-one cares what those software components are called, and they certainly do not refer to them as distinct Applications (e.g. SuccessFactors), which they can no longer be in a true ‘Distributed Application’.
I would like to go one step further and declare that we absolutely do not care what programming language those individual software components are written in, and yet strangely we are told: “You want to keep your core applications clean, you want to have SAP S/4HANA and you don’t want to modify it. So therefore, we encourage you to do Side-by-Side Extensions. One popular way to do that is actually the SAP Cloud Platform ABAP Environment… Because ABAP is still at the heart of the Intelligent Enterprise”. In a ‘Distributed Application’, there is no ‘heart’, and no standard language. This is a good thing for SAP given that SuccessFactors, Ariba, Concur, FieldGlass, etc. are most certainly not written in ABAP (or even the same language).
Today’s businesses no longer only “want to have SAP S/4HANA”; the era of the ERP is behind us. Businesses want to have a Distributed Planning System (DPS) that fully enables CI/CD, whose software components are separately upgradeable, and which replies perfectly to their ever-evolving needs; something an ERP can no longer provide. For sure, they might design a DPS that builds heavily upon S/4HANA, but they might not. Should that stop them from integrating other SAP offerings, such as SuccessFactors, Ariba, FieldGlass, etc. into their DPS if they instead choose to use Odoo as the major brick? Of course not. Should those businesses be forced to purchase a licence for SCP Integration because they wish to integrate Ariba into the framework of their non-SAP-based Distributed Application? Of course not, such a practice could even be judged ‘anti-competitive’ (especially given that it only takes a few days to develop custom – licence-free – Event-Driven integration between ECC and Azure, for example). The only interface between software components in a well-designed distributed system is the Event, and SAP’s new ‘One Domain Model’ appears to provide SAP with the perfect platform to document those Events that are triggered by the business Entities hosted upon its diverse planning systems.
The ERP is Dead. Long live the DPS!
Cameron HUNT
(The article is published by SAP Blog)
